コールホーム認証なし：未来のデジタル国際運転免許証が毎回の使用で発行機関に問い合わせてはならない理由

失効処理は、将来のデジタル国際運転免許証（IDP）における最も困難な課題です。これを解決する最も簡単な方法は、同時に最も危険でもあります——毎回の提示において発行機関を参加者として関与させることです。現代の国境をまたぐ運転資格情報は、このような近道をデフォルトで拒否すべきです。

デジタルアイデンティティに関するほぼすべての提案には、同じ安心させる一文が含まれています：

「資格情報は即座に検証できます。」

その一文が真の進歩を表す場合もあります。より使いやすいユーザーインターフェースを持つ監視行為を表す場合もあります。

現在公開されている標準規格は、検証者が資格情報を提示するたびに発行機関に連絡する必要はないことを明確に示しています：

• NISTの現行mDLアーキテクチャでは、検証者は発行機関の署名と公開鍵を信頼することで、発行機関への直接連絡なしに真正性と完全性を検証できると明記されています。
• AAMVAは、ISO/IEC 18013-5がデバイス取得のサポートを必須とし、サーバー取得は任意でのみ許可されていることを確認しています。
• AAMVAはまた警告しています、サーバー取得においては、発行機関がすべての使用においてリアルタイムで関与するため、資格情報がいつ使用されたか、どのデータが共有されたか、さらにはIPアドレス分析から位置情報を推定することさえ技術的に可能であると。

これは些細な注釈ではありません。次世代の国境をまたぐ運転資格情報における中心的な設計上の問題です。

危険な近道：4つの問いを1回のネットワーク呼び出しに集約すること

欠陥のあるアーキテクチャは、非常に異なる4つの問いを発行機関への単一のライブ呼び出しにまとめてしまいます：

1. この資格情報は本物か？
2. 提示している人物は正当な保有者か？
3. 資格情報そのものはまだ有効か？
4. 基礎となる国内運転資格はまだ有効か？

設計の悪いシステムは、リアルタイムのコールホームによって4つすべてに答えようとします。設計の良いシステムはこれらを分離します——なぜなら、これらは同じ問題ではなく、同じ仕組みを共有すべきでないからです。

真正性はネットワークではなくローカルで検証すべきである

資格情報は、発行機関がトランザクションを一切観察することなく、暗号学的に真正であることを証明できます。

• NISTのmDL信頼モデルによれば、真正性と完全性は発行機関の署名と公開鍵から検証されます——ライブでの発行機関への連絡は不要です。
• AAMVAのデジタルトラストサービスは、トランザクションごとのコールバックなしに、検証者が有効な発行機関の公開鍵にアクセスできるようにするために存在します。

設計原則1： 署名がすでに解決している問題に、ライブ接続を使用しないこと。

検証者が信頼された発行機関の鍵を保有し、標準に準拠した提示を受け取った場合、真正性の確認はローカルな暗号チェックであり、ネットワーク依存ではありません。

保有者バインディングはグローバルに報告するのではなくローカルで証明すべきである

2番目の問い——これは正当な保有者か？——にもネットワーク不要の答えがあります。

現行のEUDIアーキテクチャは、PIDおよびISO/IEC 18013-5の証明書に対してデバイスバインディングを義務付けています。検証者はウォレットに対し、資格情報に埋め込まれた公開鍵に対応する秘密鍵を使用して新しいチャレンジに署名するよう求めます：

• ISO/IEC 18013-5ではこれをmdoc認証と呼びます。
• SD-JWT VCではこれを鍵バインディングと呼びます。

いずれの場合も、所有はローカルかつ暗号学的に証明されます。個人データが発行機関に届く必要はありません。

設計原則2： 所有をローカルで証明すること。アイデンティティをグローバルに証明しないこと。

将来のIDPは、発行機関側の仕組みを検討する前に、デバイスバインディング、ローカルな保有者認証、および検証者のチャレンジ・レスポンスを徹底的に活用すべきです。

資格情報のステータスと運転資格のステータスは別物である

多くのデジタルアイデンティティの設計はこの区別を曖昧にしており、それが誤りの原因となっています。

W3Cのビットストリングステータスリスト仕様はこの点を明確にしています：検証可能な資格情報に付与されたステータス情報は、その検証可能な資格情報自体に適用されるものであり、必ずしも現実世界の権利に適用されるわけではありません。デジタル資格情報は、その署名メカニズムが侵害されたために失効することがある一方で、基礎となる運転資格は完全に有効なままである場合があります。

したがって、将来のIDPには2つの独立したステータス層が必要です：

• 資格情報ステータス層——デジタル資格情報または提示チャネル自体のため。
• 運転資格層——基礎となる国内の運転権利のため。

両者が同時に変化することもあります。多くの場合はそうではありません。これらを混同するシステムは過剰反応したり、必要以上のデータを公開したり、あるいはその両方を引き起こします。

ウォレットの侵害はステータスを通じて伝播すべきであり、検証者のコールバックを引き起こすべきではない

将来のIDPには、ウォレットが侵害された場合の明確な対応策も必要です。

EUDIアーキテクチャはその解決策を提供しています：

• ウォレットプロバイダーは失効情報を含むウォレットユニット証明書を発行します。
• ウォレットの完全性は定期的に再検証され、ウォレットが安全でなくなった場合はその証明書が失効します。
• PIDプロバイダーはウォレットが失効しているかどうかを定期的に確認しなければなりません。失効している場合はPIDを失効させます。
• 依拠当事者はPIDのステータスを確認することで、暗黙的にウォレットのステータスも確認します。

これが将来のIDPが採用すべき階層化の方法です。すべての検証者がウォレットプロバイダーを独自に確認するよう求めてはいけません。ウォレットの侵害は既存の資格情報ステータスパイプラインを通じて伝播させ、検証者はそのプライバシーを保護する単一のチャネルを参照できるようにしてください。

実用的な3つの失効パターン（コールバック不要）

EUDIはプロバイダーに対し、3つの失効方式のいずれかを使用することを求めています：

• 短命の証明書——24時間以内の有効期限のため、失効処理が不要になります。
• 証明書ステータスリスト——検証者が参照できる公開リスト。
• 証明書失効リスト——失効した資格情報の明示的なリスト。

24時間を超えて有効な証明書については、EUDIは以下を含む失効情報の埋め込みを義務付けています：

• 依拠当事者がステータスリストを取得できるURL。
• そのリスト内で資格情報を特定する識別子。

信頼できる失効情報が利用できない場合——例えば依拠当事者がオフラインの場合——EUDIは依拠当事者が資格情報を受け入れるか拒否するかを決定する前にリスク分析を実施するよう指示しています。

重要な点：失効処理は単一の仕組みではなく、発行機関への強制コールバックの正当化にはなりません。

デフォルトは短命、長命は必要な場合のみ

スタック全体において最も効果的なプライバシー対策の一つは、同時に最もシンプルなものでもあります：提示するものを短命に保つこと。

• EUDIによれば、24時間以内に有効期限が切れる証明書には失効インフラが不要です——失効が意味を持つ前に期限切れになるからです。
• W3Cによれば、検証可能な提示は通常短命であり、長期保存を目的とした設計ではありません。
• NISTは、日常的な使用において再利用可能な識別子を繰り返し送信することを明示的に警告しています。日常的な認証は、パスキーのようなその目的のために構築された技術に依存すべきであり、アイデンティティ情報が豊富な資格情報の繰り返し提示に依存すべきではありません。
• NISTはまた、プライバシーを保護し運用効率が高いという理由から、サーバー側の生体認証マッチングよりもローカルデバイス認証を選択しました。

設計原則3： 基本資格情報は中程度の有効期間を持つことができますが、提示自体は短命で、検証者固有かつ再利用不可能であるべきです。

ステータスリストが正しいデフォルトの仕組みである

すべてを短命にできない場合は、ステータスインフラが必要です——そしてステータスリストが正しいデフォルトです。

W3Cのビットストリングステータスリストv1.0は、一時停止や失効などのステータスデータを公開するための、プライバシーを保護し、スペース効率が高く、高パフォーマンスな仕組みを説明しています。主な特性は以下の通りです：

• 各発行機関は、自らが発行した資格情報のリストを管理します。
• ほとんどの資格情報は失効していないため、このフォーマットは圧縮効率が高いです。
• デフォルトのリストサイズは131,072エントリであり、W3Cによれば平均的なケースで十分なグループプライバシーを提供します。
• より強いグループプライバシーが必要な場合は、より大きなリストを使用できます。

これにより、問いかけが次のように変わります：

「今すぐこのユーザーについて発行機関に問い合わせられるか？」

から：

「ローカルで判断できる十分に新しいプライバシー保護ステータスリストをすでに持っているか？」

これは技術的にも政治的にもはるかに優れた問いかけです。

「コールホームなし」はスローガンではなくダウンロードのパターンである

EUDIのプライバシーガイダンスにおける最も重要なルールは、哲学的なものではなく手続き的なものです。

依拠当事者は、資格情報が提示されるたびにステータスリストを要求してはなりません。代わりに、次のことが求められます：

• リストの各新バージョンを一度だけダウンロードする。
• ユーザーの提示とは無関係な時間と場所で行う。
• 依拠当事者の組織内部でリストを配布する。
• 依拠当事者を認証せずにリストを取得する。

これがコールホームなし検証の運用上の核心です：ステータスをユーザーの提示とは別に更新すること——利用者ごとでも、トランザクションごとでもなく。

このたった一つの設計上の選択により、発行機関またはステータスプロバイダーが、どの検証者がどの資格情報をいつ確認したかを知ることができなくなります。

グループプライバシー：多くの設計が忘れている要件

多くのシステムは、提示内の選択的開示を宣伝しながら、ステータス照会のプライバシーをひそかに無視しています。これは重大な欠陥です。

EUDIのプライバシー要件には次のことが規定されています：

• ステータスリスト内のインデックスはランダムに割り当てられなければならず、インデックス自体が追跡シグナルにならないようにする。
• 各リストはグループプライバシーを確保するために十分に多くの資格情報をカバーしなければならない。
• リストが小さすぎる場合、プロバイダーは実際の資格情報数を隠すために未使用エントリを追加すべきである。

将来のIDPは、選択的開示だけをもってプライバシー保護を主張することはできません。失効メカニズムが提示イベントを漏洩させるなら、プライバシー設計は不完全です。

オフライン動作はエッジケースではなく、コア要件である

完全な接続性を前提とした旅行システムは設計が不十分です。

• AAMVAは、デバイス取得はホルダーデバイスとリーダーの両方において外部接続なしで機能することを確認しており、ISO/IEC 18013-5はmDLがデバイス取得をサポートすることを要求していると述べています。
• EUDIは依拠当事者がオフラインでキャッシュされたステータスリストがない場合を想定しており、その場合は決定を下す前にリスク分析を推奨しています。

このトレードオフを早期に受け入れてください：

完全なオフライン動作と完全なリアルタイムの鮮度を同時に持つことはできません。

妥協なく両方を約束するアーキテクチャは、不正確であるか、ひそかに監視機能を再導入しています。正しい対応は、鮮度を普遍的なネットワーク依存ではなくポリシー上の入力値とすることです。

ログはプライバシーが静かに失敗する場所である

優れたステータスアーキテクチャでさえ、不注意なロギングによって台無しになる可能性があります。

• EUDIは、依拠当事者のインスタンスが不要になり次第、一意な要素とタイムスタンプを廃棄し、それらの転送を禁止することを要求しています。
• AAMVAは、法律で要求される場合を除き、利害関係者がmDL保有者またはmDLの使用を追跡することを禁止し、発行機関が静的または長命なメタデータの共有を最小化することを求め、活動ログへのアクセスを保有者に限定しています。
• AAMVAはまた、デバイス上での削除が使用履歴を明らかにする可能性のあるログ情報とメタデータを削除することを要求しており、この削除はオフラインでも可能でなければならないとしています。

これはプロトコルの動作であり、管理上の後処理ではありません。将来のIDPは、長命な識別子、タイムスタンプ、ログを、明示的に反証されない限り潜在的な追跡ツールとして扱わなければなりません。

将来のIDPのための具体的なコールホームなしアーキテクチャ

原則をまとめると、システムが実際に行うべきことは以下の通りです：

1. デバイスにバインドされた基本資格情報を発行する。ウォレットのセキュアな環境で保護された鍵に資格情報をバインドする——EUDIによりPIDおよびISO/IEC 18013-5証明書について必須。
2. 必要な情報のみを、新鮮なチャレンジとともに要求する。OpenID4VPトランザクションにおいて、DCQLクエリはウォレットが保有者に要求されている属性を表示できるようにし、検証者はリプレイを防ぐためにチャレンジを発行する（NISTの現行mDLアーキテクチャに基づく）。
3. 再利用可能な識別子ではなく、短命の提示を生成する。各提示は、検証者、要求、および時点に固有のものであるべきです。
4. 真正性をローカルで検証する。発行機関の署名と公開鍵をオフラインで検証する；AAMVAのトラストサービスはまさにこの目的のために構築されています。
5. キャッシュされた、別途更新されるリストからステータスを確認する。資格情報が失効を省略できないほど長命の場合、ユーザーの提示とは無関係なスケジュールで更新されるローカルにキャッシュされたステータスリストを使用する。
6. 鮮度が利用できない場合はリスクポリシーを適用する。オフラインでの決定を明示的な検証者ポリシーとし、非体系的な推測ではなくする。
7. 追跡データを積極的に削除する。不要になり次第、トランザクション固有の要素とタイムスタンプを廃棄し、移動履歴を再構築できるログを保持しない。

これが本格的なコールホームなしアーキテクチャの姿です——階層化され、プライバシーを保護し、暗号学的にローカルで、オフラインの現実に対して運用上誠実なもの。

設計上で禁止すべき3つのパターン

成熟した将来のIDPエコシステムは、これらを最適化の選択肢ではなく、アーキテクチャ上の失敗として扱うべきです：

• すべての提示における発行機関への強制コールバック。AAMVAのプライバシーガイダンス自体がこれが有害である理由を説明しています。
• 運転資格情報を日常的なログインとして使用すること。NISTは、日常的な認証のためにアイデンティティを含む資格情報を繰り返し提示することを明示的に警告しています。
• 提示履歴を再構築できる識別子、タイムスタンプ、ログの保持。EUDIとAAMVAの両方がその逆を要求しています。

核心的な主張を一文で

即時検証が発行機関側の監視の許可になってはならない。

将来のIDPは次のことができるべきです：

• 真正性をローカルで証明する。
• 所有をローカルで証明する。
• 鮮度をプライベートに確認する。
• オフラインの現実に対応する。
• 完全な情報が利用できない場合でも適切に機能する。

これらはシステムを弱くするものではありません。大規模に展開する価値があるものにするのです。

運転資格情報が、誰が何を、どこで、いつ提示したかを記録するためのツールになった瞬間、それは紙よりも安全なバージョンではなくなります。観察のためのインフラになってしまいます。

それこそが、将来のIDPがなることを拒否すべきものです。

よくある質問

「コールホーム認証」とは何ですか？
資格情報を検証するために検証者がリアルタイムで発行機関に連絡するあらゆる設計を指します。真正性と失効処理を同時に解決できますが、発行機関がすべての提示イベントを観察できるようにもなります。

ISO/IEC 18013-5はオンラインでの発行機関への接続を必要としますか？
いいえ。AAMVAはISO/IEC 18013-5がデバイス取得のサポートを必須とし、サーバー取得は任意でのみ許可されていることを確認しています。

発行機関に連絡せずに失効処理はどのように機能しますか？
短命の資格情報、証明書ステータスリスト、または証明書失効リストを通じて機能します——理想的には、依拠当事者がユーザーの提示とは別にステータスデータをダウンロードする形で。

ステータスリストにとって「グループプライバシー」が重要な理由は何ですか？
ステータスリストが小さすぎるか、そのインデックスが予測可能であれば、ステータスリクエストがどの特定の資格情報が提示されたかを漏洩させる可能性があります。ランダムなインデックスと大きなリストによってこれを防ぎます。

オフライン検証は実際に実用的ですか？
はい——そして、AAMVAやEUDIを含む標準化団体がそれを明示的に要求しています。トレードオフは、完全なリアルタイムの鮮度と完全なオフライン動作が両立できないということです。そのため、鮮度はハードな依存関係ではなく、ポリシー上の決定事項とならなければなりません。