要約

  • RFC 3354 は、構想中の IOTP v2 で任意の取引ステップを動的に提案できることを必須としたが、その提案自体は支払同意でも実行証明でもなかった。
  • 将来購入への上限付き同意、出荷通知、外部決済の承認、実際の課金、決済、顧客対応に示す署名付き受領書は、それぞれ別の制御面に残された。

倉庫から「出荷済み」という通知が届く。その直後に決済処理が置かれている。自動化された流れでは、二つを結ぶ矢印が命令のように見えやすい。しかし、その矢印は顧客が同意した金額も、通知者の権限も、カード発行者の承認も、資金の決済も証明しない。順序は次に何を調べるかを示すが、何を実行してよいかまでは決めない。

2002 年 8 月の RFC 3354 は Informational 文書であり、Internet Open Trading Protocol の第 2 版に向けた要件を記した。IOTP v1 は役割、取引ブロック、メッセージによって電子取引を構成していた。次の設計では既存機能を維持しながら、「一回の支払いの後に一回の配送」という固定形を越え、当事者が任意の取引ステップ列を提案できることが求められた。

重要なのは「提案」という語である。オファー要求を先に置くことも、IOTP の途中で外部決済プロトコルを使うことも、出荷を待ってから支払要求へ進むこともできる。だが、候補となる依存関係を記述することは、各ステップの実行権限をあらかじめ付与することではない。

RFC 3354 は完成した IOTP v2 仕様でもなかった。将来仕様に必須の機能、追加し得る機能、範囲外の問題を分けている。IETF TRADE ワーキンググループの履歴には v2 要件のマイルストーン完了が記録される。それは要件文書の完成を示すが、v2 プロトコル、実装、普及の完成を示さない。

必須項目には動的な取引列、Offer Request Block、問題解決の改善、Customer Care の役割明確化、IOTP 内にトンネルしない外部決済プロトコル、サーバーベースのウォレットが含まれた。問題時に署名付き受領書を顧客窓口へ提示できることは証拠を増やす。しかし受領書は返金を強制せず、窓口担当者が救済権限を持つことも証明しない。

サーバーウォレットも委任機能の置き場所であって、現在の利用者を自動的に認証する装置ではない。以前の同意を広げるものでもない。外部決済対応は、取引の編成と支払実行が別領域であることを認めていた。IOTP は支払処理を呼び出せても、そのシステム固有の承認、拒否、決済記録を代行できない。

反復・継続支払いは「含めてもよい」機能にとどまった。例は無制限の包括同意ではない。将来購入の回数を限定し、総額または一回当たりの上限を設ける承認だった。運用可能な許可には対象、目的、通貨、残り回数、金額上限、期限、取消状態が必要になる。ワークフローの形からそれらを推測してはならない。

後続の支払要求は毎回その許可に照らして判定される。回数内でも一回の上限を超えることがある。金額内でも期限後かもしれない。別の商店や用途から来た要求かもしれない。シーケンスは判定を呼び出せるが、支払ブロックが同意ブロックの後にあるという理由で成功を宣言できない。

出荷通知の例では、イベントと権限の差がさらに明確だ。Delivery Handler が Payment Handler に商品出荷を通知し、それをカード請求の前提条件にできる、と RFC 3354 は述べた。前提条件は請求命令ではない。認証された範囲で、特定の処理者がある状態を主張したという証拠にすぎない。

通知は物理的な到着、購入者の受領、発行者の承認、キャプチャー、決済を証明しない。監査可能な実装は、出荷主張、どの支払要求にどの条件として使ったかというルール評価、決済システムの応答を分離する。課金後にはキャプチャーと決済の記録も増える。「出荷が支払いを起動した」という一行表示は運用要約であり、証拠鎖ではない。

隣接仕様も層を分ける。RFC 2801 は IOTP v1 の役割、識別子、冪等な処理を定義した。重複メッセージへの強さは、新しい取引列への包括権限ではない。RFC 2802 では manifest が署名対象を選択した。正しい署名は選択された内容を認証するが、欠けた同意を補わない。

RFC 2935 は HTTP 上の IOTP 搬送を定め、RFC 3106 は電子商取引のフィールド名を共通化した。搬送成功も共通語彙も、内容の権威を決めない。RFC 3275 は XML Signature の構文と処理を、RFC 2246 は TLS のチャネル保護を提供した。

RFC 3354 は IOTP 自体に機密性の仕組みがなく、TLS または IPsec に頼ること、支払保護は選択した決済システムに頼ることを明記した。暗号化された通信路、署名されたメッセージ、顧客同意、決済承認は関連していても別の事実である。安全なチャネルを通ったからといって、そのメッセージに請求権限が生じるわけではない。

既存ブロックへフィールドや属性を足す案も任意機能だった。拡張性が増やすのは表現能力であり、権限ではない。「承認済み」という属性でさえ、作成者、署名範囲、判断根拠、対象、現在の有効性が分からなければ単なる主張である。

法的・規制上の問題は範囲外とされた。したがってプロトコル準拠は、契約の執行可能性、消費者法への適合、特定法域での請求権を証明しない。この境界は欠陥ではない。地域ごとの制度的権限を一つの普遍的メッセージ文法に埋め込まないための節度だった。

RFC 3538 は IOTP v1 と SET の補足であり、RFC 3867 は後に IOTP アプリケーション中核と決済モジュールの API を定めた。後者は取引調整と決済実行が異なる状態とエラーを持つことを具体化した。どちらも v2 要件の実装・配備を証明するものではない。

RFC 3354 の歴史的意義は、柔軟性と権限を混ぜなかったことにある。シーケンスは計画、将来購入の同意は限定許可、出荷通知はイベント証拠、署名は限定内容の認証、TLS は経路保護、決済システムは承認・実行・清算の主体である。顧客救済はさらに別の制度判断になる。

現代でも、配送状況に応じた資金解放、購読周期の引き落とし、使用量による請求で同じ問題が起きる。組み替え可能な自動化ほど、「次のステップ」と「次を行う権限」を厳密に分けなければならない。手順は自由でよい。不可逆な処理だけは、その時点で固有の根拠を示す必要がある。

Sources