要約

  • RFC 3505 は電子商取引のフィールドを共通の階層で名付ける要件を定め、ウォレット、フォーム、バックエンド間の推測と変換を減らそうとした。
  • それは TLS、SET、EMV、XML、IOTP の代替ではない。名前が分かっても、加盟店の身元、利用者の同意、課金承認、資金決済、商品の引き渡しは証明されない。

初期のオンライン購入には、地味だが繰り返し発生する障害があった。同じ姓を、ある店は「surname」、別の店は last_name と呼び、さらに別の店は独自の階層へ埋め込んだ。人間なら画面のラベルを読んで再入力できる。ソフトウェアのウォレットは、各入力欄の意味を安定して推測できなかった。

2003年3月に Informational 文書として公表された RFC 3505 は、この摩擦を相互運用性の問題として扱った。ECML バージョン2は、消費者と加盟店だけでなく企業間取引にも使える Payment Processing Object を階層的に整理し、従来の HTML フォームから XML、追加の支払い方式、バックエンド処理へ範囲を広げる構想だった。

対象は、価格、領収、通貨、カード、銀行・通信事業者の支払い情報から、電子小切手、ACH、携帯端末、購買カードまで広い。同時に要求は抑制的だった。既存の ECML 1.1 をできるだけ保ち、新しい項目を必要最小限にし、URI、層分け、拡張性という Web の仕組みを利用する。

ここで作られたのは語彙の契約である。配送先都市の構造化された名前をウォレットが認識できれば、人間向けラベルの言語から意味を推測せず値を提示できる。バックエンドが同じ階層を理解すれば、自分の処理系へ対応付けられる。共通名は翻訳コストを下げるが、独立したシステムを同じ信頼領域にはしない。

RFC 3505 はその境界を明記した。ECML v2 は TLS、SET、EMV、XML、IOTP の代案ではない。それらは通信の機密性、否認防止、方式選択、スマートカード、取引フローなど別の能力を担う。ECML が行うのはデータの命名であり、周囲の制御を一つに吸収することではない。

自動入力されるデータが機微であるため、この区別は重要になる。氏名、住所、口座識別子、カード情報、認証情報をウォレットが機械的に理解すれば、便利さと同じ速度で漏えいも拡大し得る。RFC は保護を伝送基盤と、保存・開示を行うアプリケーションに依存させた。語彙が暗号方式を発明する必要はないが、認識可能であることを開示可能であることと混同してはならない。

整形式であることも限定的な証拠にすぎない。DTD や schema、検証済み XML 例、既存語彙との比較は、名前と構造が文法に従うことを示す。カード番号が本人のものか、価格が正しいか、ページが本物の加盟店に属するか、処理業者が課金を承認したかは示さない。

隠し変換フィールドの提案は、移行時の境界をよく表す。標準項目を既存の加盟店項目へ対応付ければ、古いコードを書き換えず ECML を導入できる。採用コストは下がる一方、利用者から見えない対応表を通って機微データが移動する。互換性は届け方を解決しても、届けてよいかは決めない。

2005年の RFC 4112 は ECML v2 の具体的な仕様を与えた。フィールド階層を定義し、XML を例示的な構文として採用しつつ、他の符号化や伝送方式も認めた。適合性が拘束するのは通信上の名前と階層であり、画面表示のラベルではない。加盟店は現地語を表示したまま、機械向けには共通の意味を使える。

表の MIN は、フォームが受け入れられる最低限の容量であって、内容の妥当性を判定する最小長ではない。短い氏名や長い住所も現実にはあり得る。容量要件を本人確認へ転用すれば、相互運用の床を誤った現実規則に変えてしまう。

query と assert のモードも、メッセージの意図を記述するだけである。前者は値を求め、後者は値を提示する。フィールド名は何を尋ね、何を述べたかを示すが、質問者を認証せず、提示値を真実にしない。ウォレットが応答する前に、相手、目的、時点に照らした開示判断が別途必要となる。

Web では Ecom_SchemaVersion が語彙の版を識別し、ソフトウェアが解釈を選べるようにした。すべての ECML Web 取引で必要でも、加盟店の身元証明にはならない。版の識別は、ページ検証でも通信路保護でもない。

複数ページのフォームでは、商取引が実質的に終わった後も自動入力が個人情報を流し続ける危険がある。Ecom_TransactionComplete は、再承認まで入力を止めるためのヒントである。開示範囲を区切るもので、支払いの受領証ではない。承認、捕捉、決済、履行、顧客受領のどれも証明しない。

セキュリティ節は依存先を語彙の外に保った。機微情報には機密性と不正変更への保護が必要で、真正性には XML 署名や CMS のようなオブジェクト保護、あるいは TLS や IPsec のようなチャネル保護を使い得る。仕様は選択肢を挙げるが、万能な保護方式は定義しない。

情報開示には利用者の制御が残る。共用端末では個人情報を記憶しない設定が必要で、保存データにも保護手段がいる。隠し値や初期値は返送前に悪意を持って変更され得る。標準構造は処理を予測可能にするが、周囲のアプリケーションを善良にはしない。

したがって、誠実な証拠の階段は「項目名を認識した」から始まる。構造の妥当性、相手の認証、利用者による開示許可、保護された伝送、アプリケーション受理、支払い承認、清算・決済、そして引き渡しを別々に記録すべきだ。最初の二段だけで「支払い済み」と表示すれば、機械可読性を商業上の事実にすり替える。

RFC の公表は導入実績でもない。RFC 3505 は要件を記録し、RFC 4112 は後に Standards Track 仕様となった。しかし、ブラウザやウォレットへの採用、加盟店間の相互運用、プライバシー上の効果、実取引の成功には、実装と運用の証拠が別に要る。

ECML の貢献は狭いからこそ意味がある。一種類の摩擦を減らし、すべての層を解決したとは主張しなかった。共通名は能力である。その能力が許可され、保護され、経済的な結果まで完了したかは、別の主体と別の証拠が答える。

出典