🚨アルファアラート 🚨 @tempo数分前にライブ配信が始まったばかりです。メインネットのローンチとともに、Machine Payments Protocolスペックも発表されます。私は仕様の早期アクセス権を得て、いくつかの初期の感想があります。 まず、MPP仕様は402の「支払い請求」httpコードを新たに代替したものです。これはx402と根本的に異なり、ファシリテーターをアーキテクチャから外しています。一方で、流れから仲介者を排除することは通常良い考えです。一方で、ファシリテーターが処理するロジックをマーチャントサーバーに移します。これが良いか悪いかは時間が経てばわかりますが、サーバー側のエージェントが商人のフローを最適化できるという考えがあるので、サードパーティにそれを任せるのは冗長だと思います。あとは様子を見なければならない... MPP仕様は、安定版以外の支払い方法も設計しており、クレジットカード決済による法定通貨のサポートも含まれており、これは大きなメリットだと思います。さらにPSPに依存しないアプローチも挙げられますが、これは二重の勝利だと思います。加盟店は好きな支払い方法を選べ、どの決済サービスプロバイダーでも処理されるべきです。 さて、私の質問に移ります。まず、カード決済に関しては、サーバー(すなわちマーチャント)がクライアントのペイロードの復号を制御する新しい暗号化手法があります。残念ながら、これはPCI準拠に関する疑問を生じさせます。サーバーはクライアント(購買代理人)がカードの委任をどのように管理するかを制御していません。規定されているルートはDPANのようですが、仕様によっては生のPANも適用範囲に含まれます。サーバーがCHDペイロードを制御しないため、生のPANは暗号化されてサーバーに送信され、サーバーのPSPに転送されます。これにより、ペイロードが常にDPANであることを保証できない限り、サーバーはPCI準拠である必要があります。すべてのサーバーがPCI SAQ A、あるいはさらに悪いSAQ D準拠であることを要求するのはスケーラブルではありません。 次に、仕様は複数の支払い方法を可能にしていますが、取引を全体的に解決するわけではありません。これは普通に見えるかもしれませんが、エージェント間の支払いをスケールさせるためには、すべてのエージェントが接続できるグローバル台帳を持つのが最適なアプローチだと思います。 なぜかと聞くのですか?理由はいくつかありますが、特に一つがアイデンティティ確立です。エージェントのアイデンティティは、部分的に取引履歴に基づく統計的モデリングに結びつきます。現代の例としてクレジットリスクプロファイリングがあります。しかし、分割されたトランザクションネットワークはトランザクション履歴に不一致をもたらし、動作の解決時に問題を引き起こします。 VisaやVGSのパートナーを含むすべての関係者の皆様、おめでとうございます。この分野は大きな進歩を遂げています。物事が少しずつまとまり始めており、ピースを整えるのを楽しみにしています。