Summary

  • 10月31日付の個人提出 Internet-Draft「Selo」は、法人に属する代理システム同士が接続契約を交渉する構想を示した。IETFが採択した規格ではない。
  • 契約に署名するのは法人側で、所有者が署名した権限を独立した決定的な検査器が確認する。双方の接続試験が済むまで本番用資格情報は出ない。
  • 支払先情報の変更には契約の新版、財務権限を持つ人の承認、両代理を通さない直接通知、取消可能な待機期間、そして新口座への初回支払前の支払側の人的確認が必要とされる。

署名済み契約でも、口座は勝手に動かせない

草案に出てくる顧客と供給者の例では、代理システムが注文や請求の接続条件をまとめる。後日、供給者の銀行口座が変わったらどうなるか。接続先の変更なら再試験で扱える。振込先の変更は、支払側の現金が別の場所へ出ていく決定だ。

そこで Selo は支払情報を保護対象の商業条件とする。代理に与えた権限だけでは変更できない。財務職の人が新版契約を承認し、支払側の人々には両方の代理を迂回する経路で知らせる。待機中は旧口座が有効で、どちらの当事者も変更を取り消せる。新しい口座へ最初に払う前には、支払側の人が確認する。

草案は待機期間の例として72時間を挙げる。全ての取引に72時間を義務づける数字ではない。ここを取り違えると、提案の肝心な判断権限より時計だけが一人歩きする。

構想の他の部分も責任の所在を固定しようとしている。代理は交渉できるが、所有者が署名した上限を決定的な検査器が判定してから署名に進む。契約当事者は代理ではなく法人だ。双方が署名してもすぐ本番運用には入れず、両社の実行環境が端から端まで試験して確認する。稼働後は提供側のゲートウェイが、契約の版、許可された操作や項目、鍵に結び付いた短期トークンを呼び出しごとに調べる。

ゲートウェイは不正な API 呼び出しを止められる。しかし、受取口座の正当性を担当者の代わりに保証するわけではない。Selo 自体に送金機能もない。今回の文書は標準化作業を議論するための個人草案で、実際の不正送金や導入結果を報告してはいない。

一次資料