要約

  • CyberCash 0.8では、顧客側ソフトがカード情報を署名・暗号化し、加盟店経由でサーバーに送り、加盟店契約銀行が承認を処理した。
  • 銀行は加盟店への応答を番号の一部だけにするか、全桁を渡すか選べた。異議処理には、別のパスワードと記録を伴う照会経路もあった。

レジを通る封書

客がオンラインの購入ボタンを押す。店は代金を受け取るための返事を待つ。1996年2月のRFC 1898は、その間に何が起きるかを細かく記した。顧客ソフトは登録カードの情報と請求内容の要約に署名し、暗号化する。店は自分の承認情報を加えてサーバーへ回す。CyberCashのサーバーは両側の署名を調べ、必要な情報を加盟店契約銀行へ送り、銀行の答えを戻す。店を経由することと、店が番号を読むことは別だった。

この仕様の最初の公開草案は1995年7月8日、RFCの刊行は翌年2月である。0.8版が扱うのは、文書が稼働中と述べたクレジットカード決済。電子現金は将来の計画だった。銀行の承認網を新しいネットの画面につなぐことが、当時の実装上の仕事だった。

ただし、番号を隠す規則には管理者がいる。CM6という加盟店向け応答では、先頭2桁と末尾4桁を示す card-prefix と、全桁の card-number が選択肢になる。どちらを返すかは加盟店の銀行の裁量だ。同じカードによる取引をまとめるため、番号を見せずに使えるソルト付きハッシュも用意された。取引の追跡とカード資格情報の所持を分ける設計である。

苦情が出れば別の扉を叩けた

決済を争う場合、店は保存した顧客の元のメッセージを添えて、CD1というカード情報請求をサーバーへ送れた。通常とは別のパスワードが要り、成功すればCD2が情報を返す。仕様は請求が記録され、過剰な請求は検知対象になり得ると説明する。一方、実際に何件の請求を監視し、何件を止めたかを示す運用記録はそこにない。その記録があれば、保護の実効性を判断できる。

暗号化は店の目を日常の決済経路から遠ざけた。番号を再び店へ見せる権限は、銀行の応答設定とサーバーの例外処理に残った。客の画面では一度のクリックでも、裏側には二つの開示判断が走っていた。

出典