要約

  • VCAP改訂02は9月4日に個人Internet-Draftとして公開された。IETFの承認、正式な標準化上の地位、RFCストリーム、担当Area Directorはない。
  • 新設された検証者説明責任の節は、検証者を選ぶ市場が決済結果を実質的に支配すると認め、鍵、能力、紛争経路、変更履歴を求める。
  • それでも提供者が発する service_delivery には auto_approve があり、提供者の自己証明によって自動検証を省く値と説明される。
  • 誰が免除を受け入れるか、どの合意が根拠か、誰がcallbackを署名するか、残る検査や期限は何かという処理規則がない。
  • 決済前に、提案者、受諾権限、契約根拠、範囲、上限、失効、署名者、反証、紛争経路、資金の終状態を結ぶ検証免除レシートが必要だ。

通常の検証経路では権力が見えるようになった

IETFの告知が示す出来事は限定的だ。Ben Stoneによる30ページのInternet-Draftが9月4日に公開された。Datatrackerは、これを有効な個人提出文書としている。誰でも提出でき、この文書はIETFに支持されておらず、標準化手続き上の正式な地位もない。RFCストリームも担当Area Directorもない。見出しのInformationalは著者の意図であり、獲得した地位ではない。

その範囲内で、改訂02は金銭に届く状態機械を提案する。依頼者と提供者が作業と価格を合意し、市場が資金を留保する。提供者が成果を送り、検証者が verification_callback を返す。passed=true はVERIFIEDからRELEASEDへ、falseはFAILEDからREFUNDEDへ進む。草案自身が、このcallbackを決済を引き起こす最重要メッセージと呼ぶ。

改訂01からの公式差分には、前版になかった「検証者の説明責任」が加わった。市場が検証者を選ぶと決済結果を事実上支配する、と明記する。結果を受け入れる前に、Ed25519公開鍵または検証方法を登録して信頼し、申告された能力を記録し、争われたときのエスカレーション経路を定めなければならない。登録、鍵更新、登録解除は時刻とともに決済記録の近くへ残す。

市場運営者が検証者も支配する場合、依頼者と提供者が相互に合意した第三者を使えるようにすべきだとも書く。サービスごとの検証者種別、利益相反の扱い、異議申立て経路の公開も推奨する。第三者の共同選択と政策公開は SHOULD、鍵や紛争記録は MUST である。単一の審判を世界へ強制せず、選択権の位置を示す改善だ。

しかし、通常経路の選任を説明したことで、検証者がいなくなる例外の空白がかえって目立つ。

省略を申し出るのは支払いを受ける側である

作業を終えたと主張する提供者は service_delivery を送る。成果物と説明に加え、URL、セレクター、期待する文字列、指紋の変化などの検証ヒントを載せられる。同じオブジェクトに auto_approve がある。trueなら自動検証を省き、提供者が自己証明するという定義だ。

リンクされたservice-delivery JSON Schemaは、提供者のヒントが依頼者側のヒントを「上書きまたは補完」できると説明する。初期値はfalseである。だが初期値は権限ではない。項目がないときの解釈は決まっても、受益者がtrueを送ったとき、誰の同意によって有効になるかは決まらない。

固定された -00、-01、-02 の各文書で、auto_approve は二度ずつしか現れない。メッセージ例とフィールド表である。誰が提案できるか、誰が受諾するか、どの契約条項が根拠になるか、金額やリスクの上限、残す検査、有効期限、取消し、矛盾時の扱い、監査記録は定義されていない。

未承認のtrueを受け取った市場は、無視するのか、拒否するのか、HELDのままにするのか、依頼者へ確認するのか、人間へ回すのか。現在の文章から一つの答えは出ない。異なる実装がそれぞれ安全策を選んでも、同じ取引を同じ意味で処理できる保証がない。

ここから事故を推測してはならない。どの実装がこの値を処理するか、実際に誤払いがあったか、提供者が支払いを強制できるかを示す資料はない。観測できるのは、仕様だけを読む独立実装者が完全な処理規則を得られないという点までだ。

callbackへつながる役割が欠けている

通常のcallbackには、検証ID、passed、証拠ハッシュ、署名、検証者鍵ID、アクションログ、完了時刻がある。決済記録は、そのID、ハッシュ、署名を引き継ぐ。自動検証を省いた場合、誰がこのcallbackを作るのだろうか。

提供者が署名すれば、受益者の自己申告が自身の判定になる。市場が署名すれば、それは成果確認ではなくリスク受諾の署名だ。人間が署名するなら、実態は手動レビューであり、その役割を記録できる。草案はどれも選ばず、実行しなかった検査をアクションログにどう残すかも示さない。

暗号は役割を選べない。VCAP-02は正規化された証拠束をSHA-256で要約し、検証、交渉、エスクロー、passed、ハッシュ、鍵ID、時刻をEd25519で署名する。RFC 8032に従えば公開鍵で署名を検査できる。VCAP自身も、ハッシュは改変の有無、署名は承認された検証者から来たことを示す、と範囲を限定する。依頼者の免除同意や契約条項は、そのどちらにも入らない。

原子的な状態遷移も別の性質だ。compare-and-swapは同じ留保資金が解放と返金の両方へ進むことを防ぐ。冪等性は再送callbackによる二重決済を防ぐ。終状態を一つにするが、そこへ至る例外を誰が承認したかは証明しない。

タイムアウト経路は、例外の設計例として対照的だ。標準1,800秒で検証が終わらなければ資金はHELDに残る。手動レビューを作成すべきで、最終判断は人間が行わなければならない。その人は一行のアクションログを持つ通常のcallbackを作り、ハッシュと署名を付ける。誰がどの経路で決めたかが後から分かる。auto_approve には同じ橋がない。

自己証明を常に禁じる必要はない。長い取引関係や小額の反復作業では、依頼者が検証費用より速度を選ぶことがある。問題は、事前に合意した信頼と、納品時に受益者が送るtrueを同一視することだ。

リンクされた機械可読仕様も追いついていない

実行可能な契約の保管も不安定だ。公開時点のverification-callback Schemaは、16進HMAC-SHA256を要求し、vcap_version 1.0だけを認め、verifier_key_id を持たない。改訂02本文はEd25519、Base64、鍵IDを要求する。リポジトリ履歴では、リンクされたSchema群が9月提出と同時に更新されていない。

これは運用障害の証拠ではない。最新版の文章を読む実装とSchemaに従うバリデータが異なる契約を受け取る、という再現性の警告である。免除の権限も機械可読にしなければ、同じJSONを受理できる実装同士が決済の意味だけを違えてしまう。

改訂02は AP2 との関係も狭く修正した。AP2は委任、役割、支払証拠を扱うが、VCAPはAP2がエスクロー、キャプチャ、返金、決済遷移を定めるとは仮定しない。したがって、不足する auto_approve の権限を上位プロトコルへ暗黙に押しつけることはできない。

資金を動かす前に検証免除レシートを作る

必要なのは中央審査機関ではなく、小さな共通レシートだ。取引、交渉、エスクローID、VCAP本文とSchemaの版・ハッシュ、自己証明を提案した提供者、許可する契約条項、依頼者と市場の受諾主体、置き換えられる検証者選定、免除する基準と残す基準、理由、金額・リスク上限、発効・失効・取消し、callback方式と署名者、反証、異議申立て経路、資金の終状態を記録する。

そのレシートは決済前に存在しなければならない。契約条項や受諾権限を解決できない市場は、値を拒否するか資金をHELDに保つ。交渉全体への同意から、新たな検証免除への同意を推測しない。

各参加者は自分のリスク政策を選び続けられる。共通化するのは、例外を選んだ権限、範囲、期間、結果だけだ。この最小記録があれば、ローカルな選択を中央集権化せず、異なる実装が同じ決済を後から検証できる。

出典

  1. VCAP改訂02のIETF公開告知
  2. IETF Datatrackerの状態
  3. VCAP改訂02
  4. VCAP改訂01
  5. 改訂01–02の公式差分
  6. service_delivery JSON Schema
  7. verification_callback JSON Schema
  8. VCAP仕様リポジトリの履歴
  9. RFC 8032 — EdDSA
  10. Google Agent Payments Protocol仕様
  11. Heng LuのRunning-Code Primacy
  12. Heng Luの最小共通仕様とローカルな選択