要約

  • RFC 3506 はバウチャーを <発行者, 約束, 保有者> として有効バウチャー集合 VVS に置き、物理的な保存方式から論理的な排他性を切り離した。
  • XML コンポーネント、署名、API は説明や操作の一部を担うが、現在の所有、未消費、現実の給付を単独では証明しない。

交通券をスマートカードに置く設計は、ギフト券を事業者のサーバーに置く設計と同じではない。通信条件も障害も信頼先も異なる。RFC 3506 は、その差を消そうとせず、どの実装でも崩してはならない関係だけを先に取り出した。

2003 年 3 月のこの情報提供 RFC は、ポイント、クーポン、商品券、イベント券、電話カード、引換券を一つの問題として扱った。それらは通貨ではない。発行者が商品、サービス、値引きなどを提供するという権利の表現である。

形式化は三項だった。発行者を I、約束を P、保有者を H とし、バウチャーを <I,P,H> と定義する。P は指定席、割引、一定期間の利用権などを示す。自然言語でも XML の属性でも表せる。しかし、約束の記述だけから現在の保有者は導けない。

役割も分けられた。発行者は作成して内容を保証する。保有者は所有し、移転または償還を開始する。回収者は検査して約束を実行する。VTS 提供者は、同じバウチャーが同時に複数の保有者へ割り当てられたり、許された回数を超えて利用されたりしないようにする。

この分担を支えるのが Valid Voucher Set、VVS である。VVS は有効な <I,P,H> の論理集合で、初期状態は空だ。論理集合である以上、一台の中央機器を意味しない。各保有者の耐タンパーカードでも、複数の発行者サーバーでもよい。RFC が共通化したのは保存場所ではなく、有効性の不変条件だった。

発行は発行者の意思により新しい三項を VVS に加える。移転は元の保有者の意思により H を H' へ書き換える。送信前のファイルが残っていても、そこに権利が残るわけではない。権利の移動は削除のお願いではなく、有効状態の更新である。

償還は二つに分かれる。提示は三項を見せても所有を残す。何度も示す免許やパスに向く。消費は三項を削除し、無効化し、または残回数を減らす。一回限りの券に向く。同じ「使った」という表示では、権利が存続するかどうかを監査できない。

安全要件はこの差に対応する。発行者以外は有効な新規発行を起こせない。現在の保有者だけが移転や償還を開始できる。流通中の変更は認可された保有者変更に限る。消費済みの券は再利用できず、原則として一時点に有効な保有者は一人である。

発行者の署名は必要な場合があるが、万能ではない。譲渡不能な券なら I、P、H 全体への署名が使える。だが移転で H が変われば署名は破れる。二重償還を防ぐには、オンライン状態照会か耐タンパー装置も要る。真正な記述と最新の排他的状態は別の証拠である。

履歴を持つほどプライバシー問題も生じる。RFC は、後に券を得た人から現在および過去の保有者を隠すことを勧めた。同時に、発行者やバウチャーを信頼できるか判断する機能も求めた。重複を拒否する証拠を持つことは、全所有履歴を公開する権限ではない。

中央の万能ブローカーも前提にしなかった。一つの組織の故障が全体停止を招くためだ。ただし、特定の分散技術も強制しなかった。高速な改札で使うオフライン方式と、証券に近いオンライン方式では要件が違う。単一の移転プロトコルを決めるのは時期尚早とされた。

その代わり、将来の作業を転送プロトコル、VTS API、Generic Voucher Language に分けた。最小限の意味を先に共有し、実装の選択は運用証拠に開いておく。これは仕様不足ではなく、早すぎる集中を避ける設計だった。

2005 年の RFC 4153 は XML Voucher Component を定義した。価値、商品、期間、参加者制限などの約束を記述する。しかし同文書は、コンポーネント自体はバウチャーではなく、複数のインスタンスが同じコンポーネントを使えると明記した。説明書を複製しても権利は増えない。

コンポーネントは信頼の根なので、改ざんされれば偽の約束が正当に見える。安全な通信や XML 署名には意味がある。それでもインスタンスの所有、複製防止、二重償還防止は通常その外側にある。記述の完全性は VVS の現状証明ではない。

RFC 4154 は異なる VTS に共通 API を与えた。発行は追加、移転は送り手から受け手への更新、消費は削除、提示は維持という意味が保存された。アプリケーションは同じ呼び方を得たが、呼び出しが状態そのものになったわけではない。

IESG 注記は、VTS プラグインを信頼する前提に対し、アプリケーション認証方法が規定されていないと警告した。追加認証なしに使うべきではない。正しいメソッド名は利用者の権限を証明せず、正常応答は現実の給付を証明しない。

証拠は段階ごとに読む必要がある。約束の記述、発行者と提供者への信頼、VVS 内の有効インスタンス、保有者認証、操作認可、確定した状態遷移、回収者の受理、商品やサービスの提供である。下段を上段の名前で呼べば、監視は安心を表示して事実を失う。

後年の機器参加用プロトコルも voucher と呼ばれるが、RFC 3506 の商取引権利とは別系統だ。語の一致は状態機械の一致ではない。また、情報提供 RFC の刊行は普及や相互運用を証明しない。それには実装と運用の記録が必要だ。

RFC 3506 の価値は、コピーできる情報とコピーさせてはならない権利を混同しなかった点にある。XML は約束を説明し、署名は文書を保護し、API は遷移を依頼する。権利が有効なのは、VVS が一つの現在関係を保ち、最後に回収者が約束を果たす場合だけである。

Sources