警察、レンタルデスク、雇用主、保険会社：なぜ同じデータを見せてはならないのか

将来の国際運転免許証（IDP）における最大の設計上の過ちは、すべての検証者を同一の検証者として扱うことだ。警察官、レンタカーのデスク、雇用主、保険会社はそれぞれ異なる問いを持っている——だから、それぞれに異なる答えを提供すべきである。

一人のドライバー。一つの運転する権利。一つのウォレット。しかし、検証者は四者に分かれる：

• 路上の警察官
• 車両受け取り時のレンタカーデスク
• フリート適格性を確認する雇用主
• クレームを審査する保険会社

将来のIDPが四者全員に同じデータを提示するなら、システムはすでに失敗している。資格情報が安全でないからではなく、開示モデルが単純すぎるからだ。

標準化コミュニティはすでにそのシンプルなモデルから脱却しつつある。W3Cの検証可能なクレデンシャルに関する取り組みは、発行者、保有者、検証者を中心としたエコシステムを記述しており、検証者の例として雇用主やウェブサイトを挙げている。EUのモバイル運転免許証（mDL）に関する取り組みでは、路上確認とレンタカー利用をすでに別々の検証シナリオとして扱い、レンタルには遠隔事前共有、警察には対面確認といった形式を採用している。アーキテクチャはすでに複数の検証者タイプを想定して設計されている。誤りは、あたかも一種類しか存在しないかのようにユーザー体験を設計することだ。

物理的なカードが私たちに誤った思考を植え付けた理由

物理的な免許証は「すべてを見せる」アプローチを私たちに刷り込んだ。カードを手渡す。相手はカードに書かれている内容を見る。それがすべてのやり取りだ。

紙の世界ではそのアプローチも許容できる。なぜなら代替手段がないからだ。しかしデジタルの世界では許容できない。

W3C VCデータモデル2.0は明確に述べている：運転免許証にはID番号、身長、体重、生年月日、自宅住所が含まれる場合があるが、それでも特定の取引に必要な情報をはるかに超えている可能性があると。現行の標準における重要なポイントは以下の通りだ：

• W3Cのベストプラクティス：選択的開示をサポートし、厳密に必要なものだけを要求する
• EUのデータ保護ガイダンス：処理は指定された目的に限定され、処理されるデータは必要かつ比例したものでなければならない
• 将来のIDPの第一原則：同じクレデンシャルであっても、検査する権利が同じであることを意味しない

正しいモデルはポリシーベースの開示である

真剣なアーキテクチャを求めるなら、正しいモデルはデジタルカードの提示よりも、属性ベースのアクセス制御に近いものだ。

NIST SP 800-205は、アクセス制御の決定を、主体、オブジェクト、要求された操作、環境条件に関連する属性をポリシーに照らして評価するものと定義している。これは将来のIDPにとってまさに正しい構造だ：

• 主体：ドライバー
• オブジェクト：要求されたデータフィールド
• アクション：抽象的な「免許証を見る」ではなく、「路上でカテゴリーBの運転資格を確認する」や「予約に対するレンタル適格性を確認する」といった具体的なもの
• 環境：路上、レンタルデスク、遠隔事前確認、フリートオンボーディング、損害後のクレーム審査はそれぞれ異なる環境であり、異なる決定につながるべきである

NISTはさらに、属性システムには粒度、ガバナンス、そして属性の削減・グループ化・最小化のメカニズムが必要だとも指摘している。

したがって将来のIDPが問うべきは、「この検証者は免許証を読めるか？」ではない。「この検証者は、どの意図された用途のために、この環境で、どの保持ルールのもとに、どのクレームを受け取ることができるか？」であるべきだ。

検証者は何かを要求する前に自身を証明すべきである

将来のIDPはウォレットがデータを提示することから始まるべきではない。検証者が自身が誰であるかを証明することから始まるべきだ。

EUDIアーキテクチャはこの点について明確だ。依拠当事者は以下を行わなければならない：

• 要求しようとしている属性とその目的を登録する
• アクセス証明書を受け取る
• 開示の前にウォレットに対して認証する
• 登録情報が利用可能な場合は、登録されたスコープに照らして確認を受ける

ユーザーはその後、誰が何を要求しており、その要求が登録されたスコープ内にあるかどうかを確認できる。

ETSIの現在のウォレット依拠当事者証明書に関する取り組みはこれをより具体化している。ウォレット依拠当事者登録証明書は、依拠当事者の意図された用途と登録された要求属性を記述できる。関連するアクセス証明書は、要求が正当かつ承認された当事者から来ていることを確保するために存在する。ETSIはさらに依拠当事者のメタデータも含む。たとえば：

• 商号
• サポートURI
• 意図された用途
• 権限
• レジストリURI
• 監督機関情報

将来のIDPの第二原則：検証者の身元確認なくして、開示なし。

同意画面だけでは不十分な理由

もう一つの過ちがある：ユーザーの承認を法的な正当性と同一視することだ。

EUDIアーキテクチャは明示的に述べている：属性提示に対するユーザーの承認は、依拠当事者による個人データ処理の適法な根拠として扱われてはならないと。依拠当事者は依然として独自の適法な根拠を持たなければならない。EUDIはさらに、依拠当事者が法執行機関やその他の政府機関の一部である場合を含む、すべてのユースケースでユーザーの承認を必要としている。

優れたウォレットインターフェースは助けになるが、それ単独では検証者による過剰要求を解決できない。ルールはインターフェースより先に存在しなければならない。

将来のIDPにはしたがって、以下の両方が必要だ：

• 暗号による検証者認証——誰が要求しているかを確認するため
• ポリシー上の制約——その検証者カテゴリが要求できる内容を制限するため

両方がなければ、「ユーザーの選択」はポリシーの失敗を個人に転嫁する手段になってしまう。

1. 警察：人物全体ではなく、運転する権利を確認する

路上での警察のシナリオは最も焦点が絞られたものだ。

EUのmDLマニュアルはこれを直接的に記述している：警察やその他の当局は必要に応じて免許証を確認し、免許の有効性と車両カテゴリの資格を含む。ユーザージャーニーにおいて、警察官はQRコードによるフロー、Bluetooth、Wi-Fi Aware、またはNFCを通じて免許証を確認する。これは焦点を絞った確認タスクだ：

• この人物は免許証の保有者か？
• クレデンシャルは有効か？
• どの車両カテゴリの資格と制限が適用されるか？

デフォルトで許可される情報：

• 氏名
• 顔写真
• 免許の有効状態
• 交付日と有効期限
• 車両カテゴリ
• 運転に関連する制限事項
• 発行機関と管轄
• 有効性・ステータスの確認結果

デフォルトで許可されない情報：

• 自宅住所
• 路上での使用に不要な内部識別子
• 他の証明書からの無関係な属性
• 過去の提示ログ
• 商業的なメタデータ

AAMVAの実装ガイダンスは顔写真の点を補強している：顔写真が要求され、他の要素が提供される場合、検証者がデータを提示者本人と結びつけられるよう顔写真も共有されるべきだ。同じガイダンスはさらに、関係者は法律で義務付けられている場合を除き、mDL保有者またはmDLの使用を追跡してはならないとも述べている。

警察のケースは、国家がすべてを受け取ることではない。路上での取り締まりに必要な運転に特化したデータを受け取ることだ。これは重要な違いである。

2. レンタルデスク：適格性、本人確認、そして不必要なものは一切不要

レンタルのケースはより詳細だ。実際には二つの瞬間が存在するからだ：到着前の遠隔事前確認と、担当者またはキオスクが鍵を渡す受け取り時だ。

EUのmDLマニュアルはすでに両方をモデル化している。カーレンタルサービスは予約時にmDLと本人確認書類を要求し、証明書類を検証し、後に車両を引き渡す前に受け取り時に対面で顧客を確認することができる。ユーザーは対面または遠隔で事前にカーレンタル会社とmDLを共有できる。

レンタルデスクが主に求めるのは事案の調査ではない。必要なのは判断だ：この予約と条件のもとで、この顧客にこの車両を貸し出せるか？

遠隔事前確認に含めるべき情報：

• 本人との紐付け
• 顔写真または同等の本人確認要素
• 関連する車両カテゴリ
• 交付日と有効期限
• 現在の有効性
• 必要に応じて年齢の閾値または年齢帯

受け取り時に確認すべき情報：

• 事前確認を完了した人物と同一人物であること
• 現在の有効性
• 関連する資格

デフォルトで不要な情報：

• 予約プロファイルにすでに連絡先が含まれている場合の完全な自宅住所
• 年齢超過または年齢帯で十分な場合の完全な生年月日
• 無関係な本人確認属性
• 予約証明書がすでに存在する場合の完全なクレデンシャルの再提示

NISTの現在のmDLアーキテクチャでは、依拠当事者がDCQLを使って必要な属性のみを要求することが示されており、これはクレデンシャルを単一のユニットとして扱うのではなく、要求を構造化することでデータの最小化と保有者の同意をサポートすると明示されている。AAMVAはさらに、アプリケーションは要求されたデータと検証者が情報を保持する意図があるかどうかを明確に表示すべきだと付け加えている。

3. 雇用主：検証者カテゴリであり、完全な身元情報への入り口ではない

W3Cの概要では、雇用主のデジタルシステムが大学の学位を確認する例を検証者の例として使用している。これは、雇用主による検証がすでにクレデンシャルエコシステムにおいて認められたパターンであることを示している。

雇用主またはフリート事業者が正当に知る必要がある情報は：

• 従業員が現在特定の車両カテゴリを運転する資格があるかどうか
• 重要な制限が存在するかどうか
• 資格が引き続き有効かどうか

それは実際のビジネス上のニーズだ。しかしそれは自動的に、運転クレデンシャル全体、完全な本人確認データ、または繰り返しの提示の継続的なストリームへの永続的なアクセスを正当化するものではない。

NISTは、再利用可能な識別子を頻繁に送信し、ユーザーに本人確認を含むクレデンシャルを繰り返し提示させることは望ましくないと警告しており、日常的な認証はパスキーなどの認証用に設計された技術に依拠すべきだと述べている。NISTはプライバシーをより良く保護するため、サーバーサイドの生体認証照合よりもローカルデバイス認証を推奨している。

将来のIDPは職場のアクセスバッジになるべきではない。

雇用主とフリートの利用における正しいパターンは通常：

• 業務に関連する資格の確認
• おそらく定期的なコンプライアンス証明
• おそらく保有者が特定のカテゴリについて引き続き有効であるというクレーム
• しかし、従業員がシステムにサインインするたびまたはシフトを開始するたびに、すべての免許データをデフォルトで転送することではない

フリートコンプライアンスは別個の依拠当事者カテゴリであり、別個の意図された用途を持ち、別個の開示プロファイルを持つ。

4. 保険会社：クレームは継続的な可視性の許可ではない

保険のケースはしばしば現実的だ。EUのmDLユースケース資料では、保険会社はレンタルシナリオに間接的に登場している：保険会社はレンタカー会社に対して、車を借りる人が運転する権利を持っているかどうかを確認するよう要求している。保険はすでに運転確認のフローに影響を与えている。

しかしそれは、保険会社が警察と同じデータを受け取るべきだとか、クレデンシャルへの永続的なアクセス権を持つべきだということを意味しない。

将来のIDPは保険会社を、別個の意図された用途を持つ別個の検証者カテゴリとして扱うべきだ：

• 引受
• レンタルリスク検証
• 損害後のクレーム処理
• 不正審査

これらは同じ目的ではない。EUのデータ保護原則のもとでは、個人データは指定された目的のために収集され、その目的に対して必要かつ比例したものに限定されなければならない。W3CのVCガイダンスも技術的に同じ結論に達している：検証者は厳密に必要なものだけを要求すべきだ。

正当なイベント固有の例：

• 当該時点で免許が有効であったことの証明
• 関連する車両カテゴリの資格の証明
• クレームに必要な場合の本人との紐付けの証明
• クレーム固有の開示

デフォルトで許可されない情報：

• 基礎となるクレデンシャルへの永続的なアクセス
• 顧客が保険会社とやり取りするたびに繰り返される汎用的な確認
• 運転クレデンシャルをログイントークンとして使用すること
• 無関係な属性の収集

運転クレデンシャルはモニタリングのサブスクリプションではない。そして静かにそうなるべきでもない。

中間者は可視化されなければならない理由

実際の市場には中間者が存在する。レンタルプラットフォーム、フリートベンダー、雇用主の人事システム、保険クレーム処理業者はしばしば第三者を通じて行動する。

EUDIアーキテクチャはこれを以下の方法で処理している：

• 中間者を依拠当事者として扱う
• 中間者に登録を義務付ける
• 仲介された依拠当事者のために要求される属性の登録を義務付ける
• 中間者と最終的な依拠当事者の両方をユーザーに表示する
• 中間者がトランザクションの内容に関するデータを保存することを禁止する

将来のIDPは、ユーザーがレンタカー会社に開示していると思っているが、実際には見えない検証ブローカー、分析処理業者、クレームベンダーのチェーンに開示しているというパターンを許容してはならない。

ETSIはここで役立つ。そのウォレット依拠当事者証明書モデルには、サポートURI、意図された用途、レジストリURI、監督機関のメタデータが含まれている。これは、ユーザーが要求の実際の相手が誰であり、削除や修正を求めたい場合にどこに行けばよいかを理解するために必要な、機械可読なインフラストラクチャの種類だ。

保持はアクセス制御の一部である

選択的開示に関する議論のほとんどは早すぎる段階で終わっている。何が開示されるかに焦点を当て、その後どのくらいの期間それが残るかについては十分に焦点を当てていない。

現在のガイダンスはすでに収束しつつある：

• AAMVA：ウォレットは保有者に対して要求されたデータと検証者が情報を保持する意図があるかどうかを明確に伝えなければならない。関係者は法律で義務付けられている場合を除き、保有者またはmDLの使用を追跡してはならない
• W3C：保有者のソフトウェアは検証者と共有された情報のログを提供すべきであり、過剰な要求を特定できるようにする
• EUDI：ユーザーはトランザクションログにアクセスし、不審な要求を報告し、消去を要求できるべきである

保持クラスは開示ポリシー自体の一部であるべきだ：

• 路上での警察：適法な業務記録を超えたデフォルトでの保持なし
• レンタル事前確認：再利用可能な本人確認コピーではなく、予約に紐づいたトランザクション記録
• 雇用主フリートコンプライアンス：生のクレデンシャルデータではなく、コンプライアンス記録または証明結果
• 保険クレーム：永続的なアクセスではなく、クレームに限定されたクレーム記録

保持を無視する将来のIDPは、プライバシーを部分的にしか保護できていない。

ウォレットが実際に決定すべきこと

この記事全体を一つの実装ルールに集約するとすれば、それはこれだ：

ウォレットが答えるべき問いは「このクレデンシャルを提示できるか？」ではない。「この認証された検証者に、この意図された用途のために、このコンテキストで、この保持クラスのもとに、このクレームのセットを提示できるか？」であるべきだ。

その決定は少なくとも以下の入力によって駆動されるべきだ：

• 検証者の身元
• 検証者のカテゴリ
• 意図された用途
• 登録された属性スコープ
• 存在する場合、発行者からの開示ポリシー
• 環境（路上、受け取り、遠隔、フリート、クレーム）
• 保有者の承認
• 適用される保持ポリシー

標準はすでにこのための多くの仕組みを含んでいる：選択的開示、依拠当事者の認証、登録された意図された用途、アクセス証明書、開示ポリシーの評価、目的に紐づいた要求。まだ欠けているのは、これらの要素を一つの一貫した開示アーキテクチャとして扱う規律だ。

核心的な主張

将来のIDPが問うべきは、データを開示できるかどうかではない。問うべきは：

• 誰が要求しているのか？
• 何のために要求しているのか？
• どの権限のもとで？
• どのコンテキストにおいて？
• どのような保持の結果をもたらすのか？

警察、レンタルデスク、雇用主、保険会社は、要求の向こう側にある四つのロゴではない。それらは四つの異なるリスクモデル、四つの異なる法的コンテキスト、問う四つの異なる理由であり——そして四つの異なる開示セットを生み出すべきだ。

これは不必要な複雑さではない。これが、すべての検証者を同じ検証者として扱うことをやめたときの、現代の運転クレデンシャルの姿だ。