AAMVAのMobile Drivers License Implementation Guidelinesを読む⑧

 こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

まだまだプライバシーの章が続きます。

4.5. DELETING MDL INFORMATION FROM A DEVICE

An mDL holder must have the capability to delete the mDL holder’s mDL from the mDL holder’s device. Such deletion:

1. Must delete all mDL information, log information, and any metadata (e.g. settings) that could impart information about the deleted mDL or its use. 
2. Must not require approval by the Issuing Authority.
3. Must be an option available to an mDL holder on the mDL device
4. Must be possible when the mDL device is offline.
5. Should be available to an mDL holder via a request to the Issuing Authority (see below).

mDL保持者は、mDL保持者のデバイスからmDL保持者のmDLを削除する機能を持たなければならない。

1. すべてのmDL情報、ログ情報、および削除されたmDLまたはその使用に関する情報を与える可能性のあるメタデータ（設定など）を削除すること
2. 発行機関の承認を必要としないこと。
3. mDLデバイス上でmDL保持者が利用可能なオプションであること。
4. mDLデバイスがオフラインのときに可能であること。
5. 発行機関（下記参照）へのリクエストにより、mDL保持者が利用可能であること。

 デバイスからmDL情報を削除する際の話です。基本的に利用者が自身で削除をすることができること（その際に発行者の承認や接続が不要であること）が求められています。難しいところですね。この章の中で発行したmDL関連情報が適切に扱われていること発行機関が責任をもって確認することが求められる一方で利用者の権利も守らないといけないわけです。まぁ、最低限ウォレット開発者が悪意を持って利用者のデータを扱えないように、というところまでは守りましょう、ってところですね。

Should an mDL device (i.e. a device containing an mDL) be lost or get stolen, it could be beneficial for the mDL holder to have the mDL remotely deleted (or temporarily suspended) by the Issuing Authority. Besides the obvious advantage to the mDL holder, other considerations apply too:

1. The mDL holder’s request must be authenticated. It must not be possible for someone other than the mDL holder or the Issuing Authority to delete (or suspend) an mDL.
2. A “push” capability (from the Issuing Authority to the mDL device) is needed for immediate deletion (or suspension) (see section 6).
3. Successful deletion (or suspension) depends on network connectivity to the mDL device
4. The mDL will automatically become unusable (although potentially not inaccessible) when the MSO expires (see section 6). 

mDLデバイス（mDLを含むデバイス）が紛失または盗難に遭った場合、発行機関によってmDLがリモートで削除（または一時的に停止）されることは、mDL保有者にとって有益です。mDL保有者にとっての明らかな利点の他に、他の考慮事項も適用されます：

1. mDL保有者の要求は認証されなければならない。mDL保持者の要求は認証されなければならない。mDL保持者または発行機関以外の者がmDLを削除（または一時停止）することはできない。
2. 即時削除（または一時停止）には、（発行局からmDLデバイスへの）「プッシュ」機能が必要である（セクション6参照）
3. 削除（または一時停止）の成功は、mDLデバイスへのネットワーク接続に依存します。
4. MSOの有効期限が切れると、mDLは自動的に使用できなくなる（アクセスできなくなる可能性はないが）（セクション6参照）。

やはりスマートフォンベースの話なので当然紛失や盗難に関する考慮は十分に必要です。

mDLを利用するときはちゃんと認証するのは当たり前として、発行者から発行済みのクレデンシャルをプッシュ等を使って削除できるようにする、また有効期限切れたらウォレット側で自動的に使えなくする、などもちゃんと気を使う必要があります。

In addition, mDL deletion may be needed when an mDL holder wants to transfer an mDL to a new device, when a person moves to another jurisdiction, or when a person dies. 

Issuing Authorities should weigh the benefits and challenges associated with a remote delete (or suspension) capability when considering its implementation (see Appendix A).

An mDL holder must have the capability to delete activity log information (as defined in section 4.4) the mDL holder may previously have elected to maintain. It is recommended that this capability allows selective deletion (i.e. specific log entries, rather than only an “all or nothing” option).

さらに、mDLの削除は、mDL保持者が新しいデバイスにmDLを移したい場合、別の管轄区域に移動する場合、またはmDL保持者が死亡した場合に必要となる可能性がある。

発行局は、リモート削除（または一時停止）機能の導入を検討する際、その利点と課題を比較検討する必要がある（付録A参照）。

mDL保持者は、mDL保持者が以前に保持することを選択した活動ログ情報（第4.4項に定義）を削除する機能を持たなければならない。この機能により、選択的な削除（すなわち、「全削除」オプションのみではなく、特定のログエントリーの削除）を可能にすることが推奨される。

mDLを含めデジタルデータを持ち主だけが制御できるようにするのは大切な一方で死亡した場合などの考慮は非常に重要です。マイナンバーカードと保険証の統合をした結果、意識のない救急患者の保険者資格の確認ができない、なんて話も聞きますが、この辺りは例外処理も含めてちゃんとプロセス設計をしておくのが大切です。

また、ログの削除に関しても選択的に削除することができるようにすべきである、などかなり細かくガイドされている感じがあります。

4.6. NO TRACKING

“Tracking” is the act of compiling information about an mDL holder and/or an mDL holder’s activity. Any stakeholder (including Issuing Authorities, technology providers, service providers and mDL verifiers) must not track mDL holders or the usage of any mDL except as required by law (e.g. when a drug store dispenses products containing ephedrine). 

「トラッキング」とは、mDL保持者および/またはmDL保持者の活動に関する情報を収集する行為を指します。いかなるステークホルダー（発行局、テクノロジープロバイダー、サービスプロバイダー、mDLベリファイアーを含む）も、法律で義務付けられている場合（ドラッグストアがエフェドリンを含む製品を調剤する場合など）を除き、mDL保持者やmDLの使用状況を追跡してはなりません。

トラッキングの禁止に関する条項ですね。法的根拠なくトラッキングしてはならない、と。 

Tracking by an mDL verifier can be performed as soon as two different mDL transactions can be linked to each other. This can be countered by designing the solution to maximize anonymity (“characteristic of information that does not permit a personally identifiable information principal to be identified directly or indirectly”, from ISO/IEC 29100) and to maximize unlinkability. Anonymity can be hampered by metadata that may be associated with multiple mDL transactions, e.g. hardware or network addresses, long-term public keys, or session tokens. Consequently, Issuing Authorities must minimize the sharing of static or long-lived metadata. 

mDL検証者による追跡は、2つの異なるmDLトランザクションが互いにリンクされるとすぐに実行できる。これは、匿名性（「個人を特定できる情報主体が直接的または間接的に特定されない情報の特性」、ISO/IEC 29100より）を最大化し、リンク不能性を最大化するようにソリューションを設計することで対抗できる。匿名性は、複数のmDLトランザクションに関連するメタデータ（ハードウェアやネットワークアドレス、長期公開鍵、セッショントークンなど）によって妨げられる可能性がある。そのため、発行局は静的または長期的なメタデータの共有を最小限に抑える必要がある。

これはSD-JWT-VCでも同じ議論がなされていますが、Verifierの結託によるリンク可能性の話ですね。mdocにおける選択的開示については基本的にSD-JWTと類似の考え方なので単体ではリンク可能性に対する対応はできなかったはずです。そのため匿名性を担保するソリューションを別途検討することが必要とされています。 

Although pre-matched transactions hold the promise of maximizing anonymity at a user data level, anonymity in post-matched transactions is limited since the portrait image is always shared. For these transactions it is recommended that Issuing Authorities pursue regulatory protection against tracking by mDL verifiers.

事前照合取引は、ユーザー・データ・レベルでの匿名性を最大化することが期待できるが、事 後照合取引では肖像画像が常に共有されるため、匿名性は制限される。このような取引の場合、発行機関はmDL検証者による追跡を防ぐため、規制による保護を追求することが推奨されます。

Solutions using the server retrieval method also pose challenges in preventing tracking. As per design, the Issuing Authority is involved in real time each time an mDL is used by the mDL holder. The Issuing Authority would technically be able to keep track of when an mDL holder uses his/her mDL and keep track of what data is shared. Based on IP address analysis the Issuing Authority would also be able to track an mDL holder’s physical location to some extent. This can be mitigated by placing regulatory limitations on the Issuing Authority11, and will be of value to the extent an mDL holder trusts the Issuing Authority’s adherence to the regulatory limitations. Consequently, Issuing Authorities considering a server retrieval solution should carefully weigh the advantages of this approach against its privacy implications. 

サーバーリトリーバルを使用するソリューションは、追跡を防ぐという課題もある。設計の通り、発行局はmDL保有者がmDLを使用するたびにリアルタイムで関与します。発行局は技術的に、mDL保有者がいつmDLを使用し、どのようなデータが共有されたかを追跡することができます。IPアドレスの分析に基づき、発行局はmDL保持者の物理的な所在地をある程度追跡することもできます。この問題は、発行局に規制上の制限を設けることで緩和することができます11 。そのため、発行局はサーバー検索ソリューションを検討する際、このアプローチの利点とプライバシーへの影響を慎重に比較検討する必要があります。

サーバーリトリーバルは基本的に従来のフェデレーションモデルと同様に発行者への問い合わせが発生するため、トラッキング耐性は低いとされます。この辺りはエコシステムのサイズや参加しているエンティティの関係性などを踏まえて設計していかないといけないポイントですね。 

Since the activity log (see section 4.4) contains a full record of when and potentially where an mDL was used, it is reiterated that access to the activity log must not be possible by anyone other than the mDL holder. 

アクティビティログ（4.4項参照）には、mDLがいつ、どこで使用されたかについての完全な記録が含まれるため、mDL保持者以外の者がアクティビティログにアクセスできないようにする必要があります。

 

今日もこの辺りにしておきましょう。

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑦

こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

引き続き4章のプライバシーの部分を読んでいきます。

4.3. PROTECTING DATA

It is up to Issuing Authorities to ensure that all mDL data stored on the mDL holder’s device is adequately protected. As standards in this respect are still under development, each Issuing Authority should take great care to ensure that the design of its solution supports this requirement. At minimum, Issuing Authorities must adhere to the following:

発行局は、mDL保持者のデバイスに保存されたすべてのmDLデータが適切に保護されていることを確認する必要があります。この点に関する標準はまだ開発中であるため、各発行局はソリューションの設計がこの要件を確実にサポートするよう、細心の注意を払う必要があります。発行局は、最低限以下の事項を遵守しなければなりません：

 原文でも太字で強調されているとおり、mDL App（ウォレット）に保持されているmDLデータが保護されていることを発行者が確認することが求められています。この責任分解の考え方は非常に重要ですね。欧州でもそうですが発行者となる国が認定したウォレットが必要になるのはこのような背景からきていると思います。しかしこうなるとApple WalletやGoogle Walletに格納されたクレデンシャルが適切に管理されていることをどこまで国は確認できるんだろうか、、、と気になってきますね。

具体的な要件が続きます。

• mDL information must be stored in encrypted form
• Private key material must be protected in a security module designed for the safekeeping of key material.
• The mDL holder must be authenticated when any mDL data is accessed or released, at a point in time that is sufficiently close (as determined by the Issuing Authority) to the time of the access or release. Issuing Authorities that want to leverage device unlocking to protect mDL data must include measures to ensure that this feature has not been disabled by the mDL holder (also see section 7).
• Example: If an app authenticates the mDL holder when the mDL app is accessed, an Issuing Authority should set a time limit after which authentication of the mDL holder is again required before the release of mDL data. 
• mDL data must be released to an mDL verifier only via the following:
• an ISO/IEC 18013-5 compliant interface.
• an ISO/IEC 18013-7 compliant interface.
• As an alternative to ISO/IEC 18013-7, an over-the-Internet interface as envisioned in Appendix C that:
• Complies with Appendix C items 2.b and 2.f, and 
• Has been approved by the AAMVA Identity Management Committee.
• For sharing mDL data between apps on a phone via an interface other than those listed above, an interface compliant with Appendix C items 2.b and 2.f and that has been approved by the AAMVA Identity Management Committee 
• mDL情報は暗号化された形で保存されなければならない。
• 秘密鍵は、鍵の保管のために設計されたセキュリティ・モジュールで保護されなければならない。
• mDL データがアクセスまたは公開される際には、アクセスまたは公開の時点に（発行局が決定する）十分 に近い時点で、mDL 所持者が認証されなければならない。デバイスのロック解除を活用してmDLデータを保護したい発行局は、この機能がmDL保持者によって無効化されていないことを保証する手段を含める必要があります（セクション7も参照）。
• 例 アプリがmDLアプリにアクセスしたときにmDLの所有者を認証する場合、発行局は、mDLデータの公開前にmDLの所有者の認証が再度必要となる制限時間を設定する必要があります。
• mDLデータは、以下を経由してのみmDL検証者に公開されなければならない：
• ISO/IEC 18013-5に準拠したインターフェース。
• ISO/IEC 18013-7準拠のインターフェース。
• ISO/IEC 18013-7 に代わるものとして、付録 C で想定されているインターネット上のインター フェース：
• 付録Cの項目2.bおよび2.fに準拠し、かつ
• AAMVA アイデンティティ管理委員会によって承認されている。
• 上記以外のインタフェースを介して携帯電話のアプリ間で mDL データを共有する場合は、付 録 C 項目 2.b および 2.f に準拠し、AAMVA アイデンティティ管理委員会によって承 認されたインタフェース。

かなり細かく要件が決まってますね。EUでも鍵をどこに置くかは色々と議論がありましたが、AAMVAではセキュリティ・モジュールになってますね。クラウドベースのHSMとかは選択肢に入らないのかな？あと、Holderのプレゼンスや認証のタイミング、ウォレットのアンロックが無効化されていないことの確認など色々とガイドがありますがどうやって確認するんだ？？って気もしますが。こうなってきるとやはり専用ウォレットみたいな話になってきそうですねぇ。。

Note 1: This requirement prohibits the sharing of mDL data using the mDL as a “flash pass” (i.e. by showing an image of a credential to a verifier); also see section 8.

注 1：この要件は、mDL を「フラッシュ・パス」（すなわち、検証者にクレデンシャルの画像を見せること）として使用して mDLデータを共有することを禁止している。

これも重要ですね。以前紹介したパートにも書いてありましたが基本的にmDLは目視で確認するためのものではない、ということですね。

4.4. ACTIVITY LOG

The mDL app must be capable of maintaining an activity log. The mDL app must allow the mDL holder to decide if an activity log must be maintained or not. It is recommended that the mDL app requires the mDL holder to explicitly choose for or against keeping an activity log upon setup (i.e. no defaults, and in addition to being able to change this subsequently). The activity log and related settings must be accessible only to the mDL holder (also see section 4.6). The activity log must allow for the recording of all mDL transactions. In this context, an mDL transaction is the sharing of information by an mDL holder with an mDL verifier, as well as any provisioning, update, or communication action between the mDL and the Issuing Authority. At minimum, the following must be recordable for any transaction: Transaction timestamp; type of transaction (e.g. update or data sharing); in case of a data sharing transaction the data that was shared, and to the extent that it can be gathered, information about the identity of the mDL verifier. It is recommended that the mDL app provides the mDL holder the capability to select what types of activities are recorded in the activity log (i.e. rather than only an “all or nothing” option). It is also recommended that the mDL app includes functionality to help the mDL holder monitor and manage the size of the activity log within the capabilities of the mDL holder’s device. The mDL app must provide an option to the mDL holder to export the activity log.

mDLアプリは、アクティビティログを維持できなければならない。mDLアプリは、アクティビティログを保持するかどうかをmDL保持者が決定できなければならない。mDLアプリは、セットアップ時に、mDL保有者がアクティビティログの保持の可否を明示的に選択することを推奨します（すなわち、デフォルトではなく、さらにその後変更できるようにします）。アクティビティログおよび関連する設定は、mDL保持者のみがアクセス可能でなければなりません（4.6項も参照）。アクティビティログは、すべてのmDLトランザクションの記録を可能にしなければならない。ここでいう mDL トランザクションとは、mDL 保持者が mDL 検証者と情報を共有すること、および mDL と発行局との間でプロビジョニング、更新、または通信を行うことである。どのようなトランザクションでも、最低限、以下の情報は記録可能でなければならない： トランザクションのタイムスタンプ、トランザクションのタイプ（更新またはデータ共有など）、データ 共有トランザクションの場合は共有されたデータ、および収集可能な範囲で mDL 検証者の身元に関する情報。mDLアプリは、活動ログに記録される活動の種類を選択する機能をmDL保持者に提供することが推奨される（すなわち、「all or nothing」オプションのみではなく）。また、mDLアプリには、mDL保持者がmDL保持者のデバイスの能力の範囲内でアクティビティログのサイズを監視および管理するのに役立つ機能が含まれることが推奨されます。mDLアプリは、mDL保持者がアクティビティログをエクスポートできるオプションを提供する必要があります。

次はログの話題です。アクティビティログはプライバシーの観点からも非常に重要なものですので、Holderが完全に制御できるものである必要があることが強調されています。この辺りもウォレットソフトウェアを開発する際は留意したいポイントですね。

If an Issuing Authority allows an mDL holder to hold the same mDL on more than one device, the activity log settings on each device should be independent of each other. It is recommended that there be no synchronization of the activity log or activity log settings between the two devices. Any synchronization features that are provided must adhere to the following:

1. Synchronization must be an option that can be enabled or disabled by the mDL holder. The process to enable synchronization must require the mDL holder to prove access to both devices. 
2. Synchronization must occur directly between the devices in question. A synchronization action must not give visibility of any of the following to anyone other than the mDL holder, or to anyone other than entities that already know that the mDL holder has an mDL on more than one device:

• Activity log information.
• Activity log settings.
• The fact that a synchronization action/selection took place
• Any information that may convey that the mDL holder has an mDL on more than one device. 

発行局がmDL保持者に複数のデバイスで同じmDLを保持することを許可する場合、各デバイスのアクティビティログ設定は互いに独立しているべきである。2つのデバイス間でアクティビティログまたはアクティビティログ設定の同期は行わないことが推奨される。提供される同期機能は、以下に従わなければならない：

1. 同期は、mDL保持者が有効または無効にできるオプションでなければならない。同期を有効にするプロセスでは、mDL保持者が両方のデバイスへのアクセスを証明する必要があること。
2. 同期化は、当該デバイス間で直接行われなければならない。同期化アクションは、mDL保持者以外、またはmDL保持者が複数のデバイスにmDLを持つことを既に知っているエンティティ以外の者に、以下のいずれかを可視化してはならない：

• アクティビティログ情報。
• アクティビティログの設定。
• 同期アクション/選択が行われた事実。
• mDL保持者が複数のデバイスでmDLを使用していることを伝える可能性のあるあらゆる情報。

 複数デバイスをHolderが使っている場合のログの同期の話です。これもせっかくコンテキストによってデバイスを分けているにも関わらずログが同期されてしまうとコンテキスト違反が起きてしまうことになるのでちゃんと分けましょう、という話ですね。

今日はこのあたりで。

 

 

 

 

 

 

 

 

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑥

こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

ようやく4章の「PRIVACY AND SECURITY」に入ります。4章も結構長いんですよね。。。ただ、結構重要な章なので細かくみていきたいと思います。

4.1. INTRODUCTION

The privacy of an mDL holder has been paramount in the mDL design process from the start. Care was and is being taken in all the work to ensure that methods and means are available to protect mDL holder privacy. The subsections that follow elaborate in more detail on different aspects of privacy protection and security.

mDLの設計プロセスでは、当初からmDL保持者のプライバシーが最優先されてきました。すべての作業において、mDL保持者のプライバシーを保護する方法と手段が利用できるよう、細心の注意が払われています。以下のサブセクションでは、プライバシー保護とセキュリティのさまざまな側面について詳しく説明します。

4.2. DATA MINIMIZATION AND SELECTIVE DATA RELEASE

A primary component of privacy involves the ability of an mDL holder to only share some information. This is achieved by two related but distinct measures:

1. Data minimization: A decision by an Issuing Authority to record fractional information about an attribute in an mDL, thus empowering an mDL holder to share less information than would otherwise have been the case. For example, an Issuing Authority can decide to include9 the optional age_birth_year field in an mDL in addition to the (mandatory) date of birth. This will allow the mDL holder to share only a birth year as opposed to a date of birth. Another example would be to include the resident city in addition to a full address. 
2. Selective data release: Allowing an mDL holder to decide which of the data fields requested by an mDL verifier will be released to the Verifier.

As noted in section 2, it is important for Issuing Authorities to understand that ISO/IEC 18013-5 primarily specifies interfaces. The interfaces support both data minimization and selective data release. It is recommended that Issuing Authorities implement and provision as many of the optional minimized data elements, defined in ISO/IEC 18013-5 and in this document, as possible.

プライバシーの主要な構成要素は、mDL保持者が一部の情報のみを共有する能力である。これは、2つの関連するが異なる手段によって達成される：

1. データの最小化：データの最小化：発行局が、mDLに属性情報の一部を記録することを決定すること。例えば、発行局はmDLに、（必須である）生年月日に加え、オプションのage_birth_yearフィールドを含める9 ことができます。これにより、mDLの所持者は、生年月日ではなく、生年のみを共有することができます。他の例としては、完全な住所に加えて、居住地の市町村を含めることができる。
2. 選択的データ公開：mDL保有者が、mDLベリファイアから要求されたデータフィールドのうち、どのフィールドをベリファイアに開示するかを決定できるようにすること。

セクション2で述べたように、発行局はISO/IEC 18013-5が主にインタフェースを規定していることを理解することが重要である。インターフェースはデータの最小化と選択的なデータ公開の両方をサポートする。発行局は、ISO/IEC 18013-5 および本文書で定義されているオプションの最小化データエレメントを可能な限り実装し、提供することが推奨される。

Privacy by designということです。ISO/IEC 18013-5ではデータの最小化と選択的情報開示の両方をサポートしているので、本書の原則を踏まえてちゃんと実装しなさいよ、と。

 

In addition, Issuing Authorities must ensure that mDL apps to which they provision data support at least the following: 

• In case the request was received electronically, the mDL app must clearly convey what data was requested, and whether the mDL verifier intends to retain the information. If the request is presented in summarized form in the user interface (e.g. “Identity and driving privilege data” as opposed to “First Name, Last Name, DOB, Driving privileges”), means must be available to give the mDL holder visibility of the details of such a summarized form, both before and during a transaction.
• The mDL app must provide the mDL holder full control over which data elements to share with the mDL verifier. 
• ISO/IEC 18013-5 requires the portrait image to be shared if the portrait was requested and if any other data element is released (to enable the mDL verifier to tie the mDL information to the person presenting the information). The app must support a graceful and informed exit from the request if the holder opts not to share the portrait image when requested.
• If blanket sharing options are used, measures must be implemented to ensure that the mDL holder remains aware of what is being released when such an option is in effect. An mDL holder must also be able to opt out of or cancel any blanket sharing function.

Issuing Authorities (and their app providers) are encouraged to devise solutions that will minimize transaction friction without compromising the above requirements.

さらに、発行局はデータを提供するmDLアプリが少なくとも以下をサポートしていることを確認する必要があります：

• 要求が電子的に受信された場合、mDLアプリは、どのようなデータが要求されたのか、またmDLベリファイアがその情報を保持する意図があるかどうかを明確に伝えなければならない。要求がユーザーインターフェースに要約された形で提示される場合（例えば、「姓名、DOB、運転権限」ではなく「身分証明書および運転権限データ」）、取引の前および取引中の両方において、mDL保有者がそのような要約された形の詳細を可視化できる手段を利用できなければなりません。
• mDLアプリは、どのデータ要素をmDLベリファイアと共有するかについて、mDL保持者に完全なコントロールを提供しなければならない。
• ISO/IEC 18013-5では、肖像画が要求された場合、およびその他のデータ要素が公開された場合、肖像画を共有することが要求されています（mDLベリファイアがmDL情報を提示者に紐付けることを可能にするため）。アプリは、所持者が要求されたときに肖像画を共有しないことを選択した場合、その要求から 潔く、かつ通知された形で抜けることをサポートしなければならない。
• 包括的共有オプションが使用される場合、そのようなオプションが有効であるとき に、mDL保有者が何が公表されるかを確実に認識し続けるための措置が講じられなけれ ばならない。また、mDLの保有者は、包括的共有機能をオプトアウトまたはキャンセルできなければならない。

発行局（およびそのアプリプロバイダ）は、上記の要件を損なうことなく、取引の摩擦を最小化するソリューショ ンを考案することが推奨される。 

データを要求・共有する目的・意図を明確に伝える、そして提供しないことをユーザが選択できるようにする、オプトアウトできるようにもする、と。どれも基本的なことではありますが実装者にとってはどのようなUXを提供するかが腕の見せ所になると重要なポイントの一つでもあります。この辺りは日本でもウォレット開発をする方々も参考にすべき点だと思います。

細かくみていこうと思うので少し細切れにしていきます。

ということで今日はここまで。

 

 

 

 

AAMVAのMobile Drivers License Implementation Guidelinesを読む⑤

こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

まだ３章が続きますが今回で３章は終わりです。

3.6. IACA ROOT CERTIFICATE

In Table B.1 of ISO/IEC 18013-5, on the table row for the “ISSUER” certificate component, replace:

stateOrProvinceName is optional. If this element is present, the element shall also be present in the end-entity certificates and hold the same value. 

with the following:

stateOrProvinceName is mandatory. The element shall also be present in the end-entity certificates and hold the same value.  

ISO/IEC 18013-5 の Table B.1 の 「ISSUER 」証明書コンポーネントの表行で、以下を置き換える：

stateOrProvinceName はオプションである。この要素が存在する場合、この要素はエンドエンティティ証明書にも存在し、同じ値を保持するものとする。

を以下のように置き換える：

stateOrProvinceName は必須である。この要素は、エンド・エンティ ティティの証明書にも存在し、同じ値を保持するものとする。

やはりモバイル運転免許証にISO/IEC 18013-5を当てはめるとき、ちょいちょい書き換えするところがありますね。

3.7. VERSIONING

The data structure for the 2D barcode in the AAMVA Card Design Specification contains a version number. This enables readers to always know which version of the data structure is present on a credential since the full data string is always read. This is not true for an mDL. An mDL reader has to explicitly request individual data elements, and does not know in advance which data elements are present or what version of a data set is supported.

AAMVA カード設計仕様の 2D バーコードのデータ構造には、バージョン番号が含まれている。これにより、完全なデータ文字列が常に読み取られるため、読み手はデータ構造のどのバージョンがクレデンシャルに存在するかを常に知ることができる。これは mDL には当てはまらない。mDL リーダは個々のデータ要素を明示的に要求する必要があり、どのデータ要素が存在する か、またはデータ・セットのどのバージョンがサポートされているかを事前に知ることはできない。

One approach to address this is to add a “version” data element to the AAMVA namespace. To be useful an mDL reader would have to obtain this data element before making a subsequent request for additional data. Allowing the release of this data element without mDL holder approval is possible; requiring approval may confuse an mDL holder and increase transaction friction. Regardless, the 2-step process would add complexity (an mDL reader would still have to allow for not receiving a response to such a request) and add time to the transaction. Such an approach would also be unique to mDL in North America.

これに対処する1つの方法は、AAMVA名前空間に「バージョン」データ要素を追加することである。mDLの読者は、追加データを要求する前にこのデータ要素を取得しなければならない。mDL保持者の承認なしにこのデータ要素の公開を許可することは可能です。承認を必要とすると、mDL保持者を混乱させ、取引の摩擦を増大させる可能性があります。いずれにせよ、2段階のプロセスは複雑さを増し（mDLリーダーは、そのような要求に対する返答を受け取らないことを許容しなければならない）、取引に時間を要する。また、このようなアプローチは北米のmDLに特有のものである。

Instead, versioning of the AAMVA mDL data element set is achieved as follows:

1. If needed, create a new identifier. This applies if there is a change to an existing data element, or if a completely new data element is added. Set a date by which mDL apps and mDL readers must support the new identifier (Dayx in Figure 2). “Support” as used here means that an mDL app must allow an Issuing Authority to provision the identifier into the app, and that an mDL reader must be able to read the new identifier. 
2. For the old identifier, set a date by which mDL apps and mDL readers do not need to support the old identifier anymore (Dayy in Figure 2). This is also the date by which Issuing Authorities must be provisioning the new identifier.

代わりに、AAMVA mDLデータ要素セットのバージョニングは、以下のように行われる：

1. 必要に応じて、新しい識別子を作成する。これは、既存のデータ要素に変更がある場合、またはまったく新しいデータ要素が追加される場合に適用されます。mDLアプリとmDLリーダーが新しい識別子をサポートしなければならない期日を設定します（図2のDay x）。ここでいう「サポート」とは、mDLアプリが発行機関に識別子をアプリにプロビジョニングできるようにすること、およびmDLリーダーが新しい識別子を読み取れるようにすることを意味します。
2. 旧識別子については、mDLアプリとmDLリーダーが旧識別子をサポートする必要がなくなる日付を設定します（図2のDay y）。これは、発行局が新しい識別子をプロビジョニングする期日でもあります。 

Figure 2 also reflects other requirements on both the mDL reader and the mDL app. The main advantage of the approach illustrated in Figure 2 is that, in case of changing an existing identifier, the Issuing Authority will have the time between the two dates to provision the new identifier (and deprecate the old identifier) to all its mDLs with the knowledge that mDL readers should be able to accommodate either identifier (the highlighted option in Figure 2). In the case where a new identifier is added (i.e. when there is no change to an existing identifier), the two dates may be on the same day.

図2には、mDLリーダーとmDLアプリの両方に対するその他の要件も反映されています。図2に示されたアプローチの主な利点は、既存の識別子を変更する場合、発行局は2つの日付の間に、mDLリーダーがどちらの識別子にも対応できることを前提に、すべてのmDLに新しい識別子を提供する（古い識別子を廃止する）時間を持つことができることです（図2のハイライトされたオプション）。新しい識別子が追加される場合（既存の識別子に変更がない場合）、2つの日付は同じ日になる可能性があります。

Ideally mDL readers would ask for the old identifier up to Dayy and for the new identifier thereafter. However, it is likely that readers would, at least around the change date, ask for both. It is also likely that an mDL would, especially around Dayy, include both identifiers. How the request is presented to the mDL holder, and how approval to share is administered, is left to implementers. Nevertheless, a simple approach could be for the mDL to present only one request, for the new identifier, to the mDL holder.

理想的には、mDLの読者はDay yまでは旧識別子を、それ以降は新識別子を要求するだろう。しかし、少なくとも変更日前後には、読者は両方の識別子を要求すると思われる。また、mDLは、特にDayyの前後には、両方の識別子を含むと思われる。どのようにリクエストをmDL保持者に提示し、どのように共有の承認を行うかは、実装者に委ねられている。とはいえ、単純なアプローチとしては、mDLがmDL保持者に提示する要求は、新しい識別子のための1つのみである。

バージョニングに関するコンセプトがちゃんとしていますね。リードタイムをうまく作ってスムーズに移行できる様にすることができる様にしています。

3.8. ISSUING AUTHORITY SPECIFIC DATA

ISO/IEC 18013-5 allows for the creation of additional namespaces, in like manner as the AAMVA namespace defined in this document (see clause 7.2.8 in ISO/IEC 18013-5). Issuing Authorities can use this mechanism to add additional fields to an mDL. The Issuing Authority would be responsible for communicating such an additional namespace to mDL verifiers that need to be able to read the Issuing Authority-specific data.

Note: ISO/IEC 18013-5 also lends itself to being adopted for the issuing of credentials separate from an mDL, for example fishing licenses, health credentials, or watercraft licenses. 

ISO/IEC 18013-5では、本文書で定義されているAAMVA名前空間と同様に、追加の名前空間を 作成することができる（ISO/IEC 18013-5の7.2.8項参照）。発行局はこのメカニズムを使用して、mDLにフィールドを追加できる。発行局は、発行局固有のデータを読み取る必要のあるmDL検証者に、このような追加名前空間を伝達する責任を負う。

注：ISO/IEC 18013-5 は、漁業免許証、健康証明書、水上バイク免許証など、mDL とは別のクレデンシャルの発行にも採用できる。

今回はここまでです。次は４章です。

AAMVAのMobile Drivers License Implementation Guidelinesを読む④

こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

引き続き３章を読んでいきます。

3-3. PORTRAIT IMAGE

The portrait image is the primary means by which an mDL is matched to the person presenting the mDL in an attended transaction. The portrait image therefore needs to be of suitable quality for this purpose. ISO/IEC 18013-5 requires the portrait to comply with Annex D of ISO/IEC 18013-2:2020, which in turn requires the portrait image to be at least 192 pixels wide and 240 pixels high. In addition, ISO/IEC 18013-2 requires portrait images intended for automated face recognition to comply with ISO/IEC 19794-5, which among other requirements requires 90 pixels between the centers of the eyes. However, it should be noted that these requirements were created in the context of storage on a physical card and in machine-readable formats with limited storage capacity compared to an mDL. 

肖像画像は、立会取引においてmDLを提示する人物とmDLを照合する主要な手段です。したがって、肖像画像はこの目的に適した品質である必要があります。ISO/IEC 18013-5は、肖像画がISO/IEC 18013-2:2020の附属書Dに準拠することを要求しており、この附属書Dは、肖像画が少なくとも幅192ピクセル、高さ240ピクセルであることを要求している。さらに、ISO/IEC 18013-2は、自動顔認識用の肖像画像について、ISO/IEC 19794-5に準拠することを要求しており、この要件では、特に目の中心間が90ピクセルであることが要求されています。ただし、これらの要件は、物理的なカードへの保存や、mDLに比べて保存容量が限られる機械読み取り可能なフォーマットでの保存を想定して作成されたものであることに留意する必要があります。

It would therefore be possible to include a portrait image of much higher resolution in an mDL. Arguments for going this route include higher accuracy when using the portrait image as a probe image in 1:n biometric searching, and making it easier for a human to compare the portrait image with the mDL holder. Arguments against going this route include the following:

従って、mDLにはるかに高解像度の肖像画像を含めることが可能である。この経路をとることへの賛成意見には、1:nの生体認証検索でプローブ画像として肖像画を使用する際の精度が高くなること、人間が肖像画とmDLの所持者を比較しやすくなることなどがあります。このルートに反対する意見には、以下のようなものがあります：

1. A larger portrait image can negatively affect mDL transaction times（より大きなポートレート画像は、mDLのトランザクション時間に悪影響を与える可能性があります）

2. A better-quality portrait image could arguably be less privacy preserving than a smaller portrait image.（より質の高いポートレート画像は、より小さなポートレート画像よりもプライバシーの保護に劣る可能性がある）

3. The primary purpose of the portrait image is a 1:1 match with the mDL holder. If this match is performed biometrically, the smaller portrait size should be sufficient.（肖像画像の主な目的は、mDLの所持者と1対1で照合することです。この照合が生体認証で行われる場合は、肖像画のサイズは小さくても十分です）

Issuing Authorities should carefully consider all these points when deciding on a portrait image size. It is recommended that Issuing Authorities opt for a smaller rather than for a larger portrait image.

発行局は、肖像画のサイズを決定する際、これらの点を慎重に考慮する必要があります。発行局は、大きな縦長画像よりも小さな縦長画像を選ぶことを推奨します。

結構細かいレベルで顔写真の要件が決まっているんですね。

3.4. SIGNATURE IMAGE

ISO/IEC 18013-5 does not prescribe anything other than that the image shall be in JPEG or JPEG2000 format. Building on the requirements for a signature image in ISO/IEC 18013-1 and in the AAMVA Card Design Standard, if present the signature image must be an accurate and recognizable representation of the original signature. Care should be given to image capture, processing, digitization, and compression.

ISO/IEC 18013-5 は、画像が JPEG または JPEG2000 フォーマットであること以外には何も規定していない。ISO/IEC 18013-1およびAAMVAカード設計基準における署名画像の要件に基づき、署名画像が存在す る場合は、元の署名を正確かつ認識可能な形で表現しなければならない。画像のキャプチャ、処理、デジタル化、および圧縮には注意を払う必要がある。

3.5. MDL CRYPTOGRAPHIC PROTOCOLS

In line with recommendations from the US National Institute of Standards and Technology (NIST) and the Canadian Centre for Cyber Security, certain cryptographic constructs must not be supported for mDL solutions built in accordance with this document. At the same time, interoperability needs to be retained so mDL readers can successfully interact with an mDL originating from elsewhere. 

米国国立標準技術研究所（NIST）およびカナダ・サイバーセキュリティセンターの勧告に従い、この文書に従って構築されたmDLソリューションでは、特定の暗号構造をサポートしてはなりません。同時に、mDLリーダーが他の場所から発信されたmDLと正常にやり取りできるよう、相互運用性を維持する必要があります。

To this end, the AAMVA mDL Implementation Guidelines require the following changes to be applied to ISO/IEC 18013-5:

このため、AAMVA mDL実装ガイドラインでは、ISO/IEC 18013-5に以下の変更を適用することを要求している：

ここも量が多いので割愛しますが、Cipher SuiteをNISTの要求に従って変更したりしていますので、他の国が単純にmdocだからISO/IEC 18013-5に従ってリーダーを実装してもAAMVAのmDLは読めないって言う状態になるんだろうなぁ。。。と思います。

ということでここまでです。３章がもう少しだけ続きます。

AAMVAのMobile Drivers License Implementation Guidelinesを読む③

こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

今回は３章のISO/IEC 18013-5 QUALIFICATIONSです。

3.1. INTRODUCTION

Issuing authorities electing to follow the guidance in this document must adhere to ISO/IEC 18013-5, including as qualified in this document.

本文書のガイダンスに従うことを選択した発行局は、本文書で修飾されている場合を含め、ISO/IEC 18013-5 を遵守しなければならない。

3.2. AAMVA MDL DATA ELEMENT SET

This section specifies changes and additions to the ISO/IEC 18013-5 data element set to accommodate the unique needs of the AAMVA community. All the data elements (mandatory and optional) in the ISO/IEC 18013-5 data element set, together with the changes and additions specified in this document, comprise the AAMVA mDL data element set.

このセクションでは、AAMVAコミュニティの固有のニーズに対応するために、ISO/IEC 18013-5データ要素セットの変更と追加を規定する。ISO/IEC 18013-5 データ要素セットのすべてのデータ要素（必須およびオプション）は、本文書で 規定される変更および追加とともに、AAMVA mDL データ要素セットを構成する。

The specific changes to ISO/IEC 18013-5 follow.

ISO/IEC 18013-5に対する具体的な変更点は以下の通り。

Replace the 1st sentence of clause 7.2.1:

The mDL data elements shall be as defined in Table 5 belong to namespace “org.iso.18013.5.1”, see 7.1.

with the following:

The mDL data elements shall be as defined in Table 5. Data elements belong to the namespaces indicated. 

7.2.1 節の第 1 文を置き換える：

mDL データ要素は，表 5 に定義されるとおり，名前空間 「org.iso.18013.5.1 」に属するものとする。

を以下で置き換える

mDL データエレメントは，表 5 に定義されているとおりとする。データ要素は、示された名前空間に属する。

In Table 5, apply the following amendments:

表5において、以下の修正を適用する。

• family_nameの定義
• 変更前：Last name, surname, or primary identifier, of the mDL holder. The value shall only use latin1b characters and shall have a maximum length of 150 characters.（mDL保持者の姓、名、またはプライマリ識別子。値はlatin1b文字のみを使用し、最大150文字とする）

• 変更後： Family name (commonly called surname or last name), or primary identifier, of the individual that has been issued the driver license or identification document. If the individual’s name is not divided into family name and given name(s), that name shall be deemed the family name or primary identifier. The value shall only use latin1b characters and shall have a maximum length of 150 characters.（運転免許証または身分証明書を発行された個人の姓（一般に姓または名と呼ばれる）、または主な識別子。個人の名前が姓と名に分かれていない場合は、その名前を姓または主な識別子とみなす。値はlatin1b文字のみを使用し、最大150文字とする）
• given_nameの定義 

• 変更前：First name(s), other name(s), or secondary identifier, of the mDL holder. The value shall only use latin1b characters and shall have a maximum length of 150 characters（mDL保持者のファーストネーム、その他のネーム、またはセカンダリ識別子。値はlatin1b文字のみを使用し、最大150文字とする。）
• 変更後： Given name or names (includes all of what are commonly referred to as first and middle names), or secondary identifier, of the individual that has been issued the driver license or identification document. The value shall only use latin1b characters and shall have a maximum length of 150 characters.（運転免許証または ID 文書を発行された個人の名前（一般にファーストネームおよびミドル ネームと呼ばれるものをすべて含む）、または二次識別子。値は、latin1b 文字のみを使用し、最大 150 文字の長さを持たなければならない。）
• height、eye_colour、resident_addressのプレゼンスをO（オプション）からM（必須）へ 

• resident_addressの定義
• 変更前：The place where the mDL holder resides and/or may be contacted (street/house number, municipality etc.). The value shall only use latin1b characters and shall have a maximum length of 150 characters.（mDL保持者の居住地および／または連絡可能な場所（番地、市町村など）。値はlatin1b文字のみを使用し、最大150文字とする。）
  
• 変更後：The place where the mDL holder resides and/or may be contacted (street/house number, municipality etc.). The value shall only use latin1b characters and shall have a maximum length of 150 characters. The resident_address shall be included in full, regardless of the presence of any minimized address data elements (e.g. resident_city; resident_state; resident_postal_code; resident_country). Dayx for this change: Not applicable. Dayy for this change: 2025-09-01.（mDL保持者の居住地および／または連絡可能な場所（番地、市町村など）。値はlatin1b文字のみを使用し、最大150文字とする。resident_addressは、最小化された住所データ要素（resident_city; resident_state; resident_postal_code;resident_countryなど）の有無にかかわらず、完全な形で含まれるものとする）
• age_in_years、age_over_NN、issuing_jurisdictionのプレゼンスをOからMへ

In Table 5, add a new column titled “Namespace”. For the data elements present in ISO/IEC 18013-5, enter “org.iso.18013.5.1” for each data element

表5に、「Namespace 」というタイトルの新しい列を追加する。ISO/IEC 18013-5に存在するデータ要素については、各データ要素に 「org.iso.18013.5.1 」を入力する。

Append the following to Table 5:

表5に以下を追加する：

• ネームスペース：“org.iso.18013.5.1.aamva”
• Identifier：domestic_driving_privileges 

• 意味合い：Domestic categories of vehicles/restrictions/conditions（国内車両カテゴリー／制限／条件）

• 定義：Vehicle types the license holder is authorized to operate. See 7.2.4.（免許保持者が運転することを許可されている車種。7.2.4を参照のこと）
• プレゼンス：M

• ネームスペース：“org.iso.18013.5.1.aamva”
• Identifier：name_suffix 

• 意味合い：Name suffix 

• 定義：Name suffix of the individual that has been issued the credential. Only the following values are allowed:（クレデンシャルを発行された個人の名前サフィックス。以下の値のみが許可される：）
• JR、SR、1ST、Ⅰ、2ND、Ⅱ〜9TH、Ⅸ 

•  プレゼンス：O 

 

• ネームスペース：“org.iso.18013.5.1.aamva”
• Identifier：organ_donor 

• 意味合い：organ donor
• 定義：An indicator that denotes whether the credential holder is an organ donor. This field is either absent or has the following value:（クレデンシャル保持者が臓器提供者かどうかを示すインジケータ。このフィールドはないか、または以下の値を持つ：）
  
• 1: Donor 

•  プレゼンス：O

こんな感じで意外と多くのISO/IEC 18013-5の属性群については修正を入れています。 この辺りは国によって状況も異なるので当然と言えるでしょう。（ガイドラインには上記に記載したもの以外にも変更されたものが羅列されていますが省略します）

少し面白いところで言うと、ISO/IEC 18013-5ではage_over_NNとなっている属性を

• age_over_18
• age_over_21
• age_over_65

と言う形で米国の事情に合わせていたりするところもあります。

例えば25歳の人は

• age_over_18=TRUE
• age_over_21=TRUE
• age_over_65=FALSE

となるようです。この表現はいいのかどうか・・・

こんな表現をすることを推奨していたりもします。

age_over_16=True

age_over_17=True

age_over_19=True

age_over_20=True

age_over_22=True

…

age_over_25=True

age_over_26=False

…

age_over_64=False

age_over_66=False

…

age_over_85=False 

一旦はここまでとします。

結構この章は長いですが、ISO/IEC 18013-5の扱いに関する話が多いのであまり中身はありませんね。

AAMVAのMobile Drivers License Implementation Guidelinesを読む②

こんにちは、富士榮です。

引き続きAAMVAのMobile Drivers License Implementation Guidelines 1.4を読んでいきます。

今回は２章のmDL Solution Overviewを見ていきます。

An mDL can be described as leveraging a mobile device to transfer (or cause to be transferred) driver’s license information to an mDL verifier, who cryptographically authenticates the information using the Issuing Authority’s public key. A visual rendering of a DL on a mobile device’s display (and which can be misused as a “flash pass”) therefore does not qualify as an mDL (also see section 8).

mDL は、発行局の公開鍵を使用して情報を暗号的に検証する mDL検証者に運転免許証情報を転送する （または転送させる）ために、モバイル機器を活用するものと説明できる。したがって、モバイル機器のディスプレイ上に DL を視覚的に表示するもの（「フラッシュパス」として悪用される可能性があるもの）は、mDL として認められない（セクション 8 も参照）。

スクショやオレオレはダメってことですね。 

An mDL solution can be described in terms of the following three properties:

mDLソリューションは、以下の3つの性質で説明できる：

1. Data retrieval method. The device retrieval method (sometimes referred to as the offline model) works without outside connectivity (for both the mDL holder’s device and the mDL reader) at the time the transaction takes place, thus requiring the mDL data to reside on the mDL holder’s device. Under the server retrieval method (sometimes referred to as the online model, and not to be confused with use of an mDL in an unattended transaction setting such as over the Internet) mDL data is retrieved in real time directly from the Issuing Authority. ISO/IEC 18013-5 requires an mDL to support device retrieval, and allows a device to additionally support server retrieval. 

1. データ検索方式。デバイス検索方式（オフラインモデルと呼ばれることもある）では、取引時に外部（mDL保持者のデバイスとmDLリーダーの両方）に接続することなく動作するため、mDLデータはmDL保持者のデバイスに存在する必要がある。サーバー検索方式（オンラインモデルと呼ばれることもあり、インターネット経由のような無人トランザクションでのmDLの使用と混同されないよう注意）では、mDLのデータは発行機関からリアルタイムで直接取得される。ISO/IEC 18013-5は、mDLがデバイスの検索をサポートすることを要求しており、さらにデバイスがサーバーの検索をサポートすることを認めている。

2. Transaction type. An attended transaction is one where the mDL holder and the mDL verifier are in close proximity to each other. The engagement mechanisms currently reflected in ISO/IEC 18013-5 (QR code, NFC) were selected to support such close proximity. An unattended transaction is one where the mDL holder and the mDL verifier are not in close proximity, e.g. when an mDL holder wants to provide identity or proof of age to an online retailer. ISO/IEC 18013-5 does not currently support unattended transactions. However, work is ongoing to standardize a solution. 

2. トランザクションの種類。対面型トランザクションとは、mDL保有者とmDL検証者が近接しているトランザクションのことである。現在ISO/IEC 18013-5に反映されているエンゲージメントの仕組み（QRコード、NFC）は、このような近接をサポートするために選択された。無人トランザクションとは、mDL 保持者と mDL 検証者が近接していないトランザクショ ンのことであり、たとえば、mDL 保持者がオンライン小売業者に ID または年齢証明を提供する場合などである。ISO/IEC 18013-5 は現在、無人トランザクションをサポートしていない。ただし、ソリューションを標準化する作業が進行中である。 

3. Timing of (and responsibility for) matching. This property is about the responsibility for confirming, at transaction time, that the person presenting the mDL data is the person described by the mDL data. In a post-matched transaction, the link between the mDL Presenter and the mDL data is made after the mDL data is shared and is performed by the mDL verifier. This happens by comparing the portrait image in the mDL with the person presenting the mDL. ISO/IEC 18013-5 supports postmatched transactions. In a pre-matched transaction, the link between the mDL Presenter and the mDL is made right before the mDL data is shared. Although the Issuing Authority should not be involved in real time, the Issuing Authority does take responsibility for certifying the link. The mDL verifier receives only the confirmation that the person presenting the mDL data is the person described by the shared mDL data. ISO/IEC 18013-5 does not currently support pre-matched transactions. However, work is ongoing to standardize a solution (and notably one that does not involve the Issuing Authority at transaction time).

3. 照合のタイミング（および責任）。このプロパティは、mDLデータの提示者がmDLデータに記述された本人であることをトランザクション時に確認する責任に関するものである。マッチング後のトランザクションでは、mDL提示者とmDLデータのリンクは、mDLデータが共有された後に行われ、mDL検証者によって実行される。これは、mDL内の肖像画像とmDL提示者を比較することで行われる。ISO/IEC 18013-5 はポストマッチトランザクションをサポートしている。事前照合トランザクションでは、mDL提示者とmDLのリンクは、mDLデータが共有される直前に行われる。発行局はリアルタイムで関与すべきではないが、発行局はリンクを認証する責任を負う。mDLの検証者は、mDLデータの提示者が共有されたmDLデータに記述された本人であることの確認のみを受ける。ISO/IEC 18013-5は現在、事前照合トランザクションをサポートしていない。しかし、（特にトランザクション時に発行局が関与しない）ソリューションを標準化するための作業が進行中である。

デバイスリトリーバル、サーバーリトリーバルの２方式があること、対面、非対面のシナリオが定義されていること、そして検証者がHolderバインディングを行うことが求められている、ということです。本人確認書類として利用することを考えると当然ですね。 

With this as background, Figure 1 provides a high-level overview of the mDL ecosystem described in ISO/IEC 18013-5.

これを背景に、図1はISO/IEC 18013-5で説明されているmDLエコシステムのハイレベルな概要を示している。

Three interactions are involved:

3つの相互作用が関係している： 

1. Interaction between the Issuing Authority and the mDL. This interaction results in getting everything onto an mDL holder’s device that is needed to use the mDL. There is also subsequent interaction between the Issuing Authority and the mDL to keep the mDL information updated. Technical components of this interaction will be standardized in the ISO/IEC 23220 series.

1. 発行局とmDLの間のインタラクション。このやりとりの結果、mDLを使用するために必要なすべての情報がmDLホルダーのデバイスに取り込まれます。また、発行局とmDLの間には、mDLの情報を更新するための相互作用があります。このインタラクションの技術的なコンポーネントは、ISO/IEC 23220シリーズで標準化される予定です。

Issueの時の仕組みですね。OpenID for Verifiable Credential Issuanceでもmdocを扱うことができますので、そちらを非対面のシナリオでは使うケースもありますが、ここではISO 23220が挙げられています。 

2. Interaction between the mDL and the mDL reader infrastructure of the mDL verifier. This interaction comprises the transfer of technical information to set up a secure communication channel between the two parties, and the subsequent exchange of the driver’s license information (or of a point from where it can be retrieved) that the mDL holder agreed to share. ISO/IEC 18013-5 fully standardizes an interface describing this interaction.

2. mDLとmDL検証装置のmDL読み取りインフラ間のインタラクション。このインタラクションは、両者間の安全な通信チャネルを設定するための技術情報の転送と、それに続く mDL 保持者が共有に同意した運転免許証情報（またはそれを取得できるポイント）の交換で構成される。ISO/IEC 18013-5 は、このインタラクションを記述するインタフェースを完全に標準化する。

こちらはPresentationの話ですね。こちらもOpenID for Verifiable Presentationでも対応ができる範囲です。ここではISO 18013-5での対応が挙げられています。 

3. Interaction between the mDL reader infrastructure and the Issuing Authority. This interaction can be used for different purposes, depending on the data retrieval method involved:

• Device retrieval method: The interaction is used by the mDL verifier to obtain the public keys needed to authenticate mDL information. Such interaction can also involve an intermediary entity that aggregates and disseminates certificates. (In North America, AAMVA’s Digital Trust Service performs this function – see section 5.) Regardless, the mDL verifier must trust that the certificate truly comes from a valid Issuing Authority. This interaction does not need to occur at the time of an mDL transaction. ISO/IEC 18013-5 fully standardizes a method supporting this interaction.
• Server retrieval method: The interaction is used by the mDL verifier for two purposes:
• As in the case for the device retrieval method, to obtain the public key of the Issuing Authority
• To pass to the Issuing Authority, in real time, a token that identifies the mDL holder and the mDL, and to receive the actual mDL information back from the Issuing Authority. ISO/IEC 18013-5 fully standardizes an interface describing this interaction

3. mDLリーダーインフラと発行局との間のインタラクション。このインタラクションは、関係するデータ検索方法に応じて、異なる目的で使用することができる：

• デバイスの検索方法： このインタラクションは、mDL 検証者が mDL 情報の検証に必要な公開鍵を取得するために使用される。このようなインタラクションには、証明書を集約し普及させる仲介エンティティが関与することもできる。(北米では、AAMVA のデジタル・トラスト・サービスがこの機能を果たす。） いずれにせよ、mDLの検証者は、証明書が本当に有効な発行機関から発行されたものであることを信頼しなけれ ばならない。この相互作用は、mDLのトランザクション時に発生する必要はない。ISO/IEC 18013-5は、この相互作用をサポートする方法を完全に標準化している。
• サーバーの検索方法： このインタラクションは、mDL検証者によって2つの目的で使用される：
• デバイス検索方式と同様に、発行局の公開鍵を取得する。
• mDLの所有者とmDLを識別するトークンをリアルタイムで発行局に渡し、実際のmDL情報を発行局から受け取ること。ISO/IEC 18013-5は、このインタラクションを記述するインタフェースを完全に標準化している。

ここはデバイスリトリーバルなのかサーバーリトリーバルなのかで異なりますが、mDLリーダーがIssuerへの問い合わせを行うケースについて記載されていますね。いわゆるDIDを使ったVCとの大きな違いはIssuing Authorityが完全に中央集権であることかと思います。（免許なので当然ですね）そのため、検証用の公開鍵を取得する場合は堂々とVerifierからIssuerへのインタラクションが発生しています。（ここは若干プライバシーとのトレードオフはありますが） 

Note that ISO/IEC 18013-5 specifies system interfaces and a certificate exchange method, and on purpose does not address the user interface (e.g. the look, feel and functionality of an mDL app residing on an mDL holder’s device). It is left up to Issuing Authorities (and their implementers) to innovate in this area.

ISO/IEC 18013-5は、システム・インターフェースと証明書交換方法を規定するものであり、ユーザ・イン ターフェース（例えば、mDL保有者のデバイスに常駐するmDLアプリのルック、フィール、機能性）については、 意図的に触れていないことに留意されたい。この分野での技術革新は、発行局（およびその実装者）に委ねられている。

ということで、本日はここまで。

AAMVAのMobile Drivers License Implementation Guidelinesを読む①

こんにちは、富士榮です。

先日、用語を見たついでにAAMVAが出しているMobile Drivers License Implementation Guidelines 1.4を読んでいこうと思います。

こちらが原文です。

まずはIntroductionから。

The AAMVA Joint Mobile Driver’s License (mDL) Working Group (WG) has been active around mobile identification since 2012. As the mDL evolves, the mDL WG continues to identify and address topics on which guidance to Issuing Authorities can be helpful. This document represents the bulk of the current guidance, and points to additional resources as needed.

AAMVA 合同モバイル運転免許証（mDL）ワーキンググループ（WG）は、2012 年以来、モバイル ID を中心に活動してきました。mDL の進化に伴い、mDL WG は、発行機関へのガイダンスが役立つトピックを特定し、対処し続けています。この文書は、現在のガイダンスの大部分を示し、必要に応じて追加のリソースを示します。

The goal of this document is to inform and equip Issuing Authorities, and to some extent mDL verifiers, to achieve the following:

この文書の目的は、発行局、そしてある程度mDLの検証者に対し、以下のことを達成するための情報を提供し、装備させることです：

• Technical interoperability between different Issuing Authorities’ mDL programs, i.e., an Issuing Authority being able to read an mDL issued by any other Issuing Authority.
• Trust in different Issuing Authorities’ mDLs.
• Privacy preserving implementations. 
• 異なる発行局のmDLプログラム間の技術的な相互運用性。つまり、発行局は他の発行局が発行したmDLを読むことができる。
• 異なる発行局のmDLに対する信頼性
• プライバシーの保護

まずは目的からですが、アメリカでは州ごとに免許証を発行しているため、相互運用性は非常に重要になってくる、というところだと思います。 

It is up to Issuing Authorities to determine the extent to which the guidance in this document is followed.

Nevertheless, the minimum measures deemed necessary to achieve the above are labeled as mandatory requirements in this document (i.e. “shall” or “must”). A summary of minimum measures can be found in Appendix B.

本文書のガイダンスにどの程度従うかは、発行当局の判断に委ねられます。とはいえ、上記を達成するために必要とみなされる最低限の対策は、本文書では必須要件（すなわち「しなければならない」または「しなければならない」）と表示されています。最小限の措置の要約は付録Bに記載されています。

先にも書いた通り、州ごとに発行しているのでこのガイドラインの強制力も一定程度にとどまる感じなんですね。確かに後半に出てくるリテンション期間の話や複数枚数の発行の可否などはかなり現場に判断を委ねているところもあります。このあたりは念頭に読み進める必要がありそうです。 

The following topics are outside the scope of this document:

以下のトピックは本文書の範囲外です：

1. The identity establishment, management and recordkeeping that precedes the creation of an identity credential.
2. Responsibilities of mDL verifiers. 

1. ID クレデンシャルの作成に先立つ、ID の確立、管理、および記録管理。
2. mDL 検証者の責任。

あくまでmDLの発行と管理に関するところがスコープっぽいですね。

This document leverages and expands on ISO/IEC 18013-51 (also available as INCITS/ISO/IEC 18013-5), an international mDL standard. Although ISO/IEC 18013-5 specifies an mDL solution, it was intentionally designed to support any type of mobile identity credential. ISO/IEC 18013-5, as qualified in this document, will therefore enable Issuing Authorities to issue both mobile driver’s licenses and mobile identification cards.

The term “mDL” as used in this document covers both credential types. Qualifications made in this document also allow for identifying an mDL as being REAL ID compliant or not, and/or as a credential issued under the Enhanced Driver’s License program (“EDL”; see the AAMVA DL/ID Card Design Standard).

本文書は、国際 mDL 標準である ISO/IEC 18013-5（INCITS/ISO/IEC 18013-5 としても利用可能）を活用し拡張したものです。ISO/IEC 18013-5 は mDL ソリューションを規定していますが、意図的にあらゆるタイプのモバイル ID クレデンシャルをサポートするように設計されています。このため、本文書で規定する ISO/IEC 18013-5 により、発行機関はモバイル運転免許証とモバイル ID カードの両方を発行できるようになります。

本文書で使用する「mDL」という用語は、両方のクレデンシャル・タイプをカバーします。この文書で行われる認定は、mDL を REAL ID 準拠かどうか、および／または拡張運転免許証プログラム（「EDL」；AAMVA DL/ID カード設計基準参照）の下で発行されたクレデンシャルとし て識別することも可能にします。

本書はISO/IEC 18013-5がベースであり、モバイル運転免許証とモバイルIDカードの両方を対象に書かれている、というところが肝ですね。そしてやはりリアルID法に関しても視野に入っています。

Additional guidance on mDL administration in the areas of legislation and procurement can be found in two other documents produced by the mDL Working Group. Those are the mDL Model Legislation, and the mDL Procurement Guidance (see the jurisdictional member area on the AAMVA website). AAMVA also conducts regular outreach to stakeholders on the topic of mDL, including town hall meetings, podcasts, and training.

mDLに関する法律や調達に関するガイダンスは、mDLワーキンググループが作成した2つの文書に記載されています。これらは、「mDLモデル法案」と「mDL調達ガイダンス」です（AAMVAウェブサイトの管轄メンバーエリアを参照）。AAMVAはまた、タウンホールミーティング、ポッドキャスト、トレーニングなど、mDLに関するステークホルダーへの定期的な働きかけも行っています。

It should be noted that mDL and related technologies are ever evolving. As a result, this document will continue to be updated to synchronize its content with the latest standards and practices. For this reason, readers of this document are encouraged to periodically check the AAMVA website for new versions.

mDLと関連技術は常に進化しています。そのため、本書は最新の基準や慣行と内容を同期させるために更新され続けます。このため、本書の読者は、定期的にAAMVAのウェブサイトで新バージョンを確認することが推奨されます。

AAMVAのウェブサイトを見ると色々な情報が掲載されていますので、このガイドライン以外にも参照すべき情報は多そうです。 

 

 

 

 

モバイル運転免許証に関する用語を見ていきます

こんにちは、富士榮です。

こちらにも書いた通り、11月にAAMVAからMobile Drivers License Implementation Guidelineの1.4がでました。

https://idmlab.eidentity.jp/2024/12/mobile-drivers-licensemdl.html

読んでいてそういえば一般的じゃない言葉ばっかり使ってるよなぁ、と思うのでまずはTerminologyを見ておきましょう。

そもそも論のAAMVAです。

American Association of Motor Vehicle Administrators

の略ですね。米国自動車管理者協会と訳されるようです。この辺の資料によると。 

EDL。enhanced driver licenseの略ですね。日本語だと強化運転免許証なんて訳されたりしますが、日本にいるとなんじゃそれ、ですがここに解説があります。

Enhanced Drivers Licenses (EDLs) are state-issued enhanced drivers licenses that provide proof of identity and U.S. citizenship when crossing the U.S. border in a vehicle. They are issued in a secure process, and include technology that makes travel easier. EDLs are a low-cost, convenient option for entering the United States from Canada, Mexico or the Caribbean through a land or sea port of entry, in addition to serving as a permit to drive.

強化運転免許証（EDLs）は、自動車で米国国境を越える際に身分証明と米国市民権を証明する州発行の強化運転免許証である。EDLは安全なプロセスで発行され、渡航を容易にする技術も含まれている。EDLは、カナダ、メキシコ、カリブ海諸国から陸路または海路で米国に入国する際に、低コストで便利なオプションであり、運転許可証としての役割も果たす。

使い道としては2025年から施行されるReal ID法（州が発行する運転免許証や身分証明書に対して最低限のセキュリティ基準を定めるもの）に対応したものっぽいです。米国国内で飛行機に乗るときにReal ID法に準拠した身分証明書の提示が必要になる、って話です。（日本人は外国政府発行のパスポートを使うことになると思います）

 

mDL。いわゆるMobile Driver's License、モバイル運転免許証ですね。

こんな解説が書いてあります。

driver’s license or identification card that resides on a mobile device or requires a mobile device as part of the process to gain access to the related information

Note to entry: Adapted from ISO/IEC 18013-5

運転免許証または身分証明書であって、モバイル・デバイス上に存在するもの、または入国時に 関連情報にアクセスするためのプロセスの一部としてモバイル・デバイスを必要とするもの： ISO/IEC 18013-5 からの引用。

まだ18013-7:2024と18013-5:2021の差分をとれていませんが、AAMVAとしては18013-5ベースです。

mDL app。いわゆるWalletに当たるものですね。

software running on an mDL holder’s device; within the context of this document this includes a standalone app as well as a wallet type app

mDL保持者のデバイス上で動作するソフトウェア。本書の文脈では、スタンドアロン型アプリおよびウォレット型アプリを含む。

mdoc。クレデンシャルフォーマットがmdoc、運転免許証として使えばmDLっていう整理でいいのかと思います。

document or application that resides on a mobile device or requires a mobile device as part of the process to gain access to the document or application

モバイル・デバイス上に存在する、または文書やアプリケーションにアクセスするためのプロセスの一部としてモバイル・デバイスを必要とする文書またはアプリケーション

mobile security object。MSOなんて言われたりします。mdocの構造化されたデータセットの話です。中にはデバイスアテステーションなども含まれるのでHolderバインディングの保証をすることが目的とされます。

structured data set that enables an mDL verifier to authenticate (for both accuracy and origin) other mDL data elements received during an mDL transaction

mDLベリファイアが、mDLトランザクション中に受信した他のmDLデータエレメントを（正確さと出所の両方について）認証できるようにする構造化データセット

provisioning。これは特殊用語lじゃないのかな？と思うのはIdentity界隈の人だからなのかもしれません。

initial loading of mDL information into an mDL app

mDLアプリへのmDL情報の初期読み込み

要するにウォレットへのモバイル運転免許証をインストールすることですね。

ということで、まずは用語解説からでした。

概念を理解するためにもこのあたりはちゃんと押さえておきましょう。 

 

 

 

 

 

 

Mobile Driver's License(mDL) Implementation Guidelines 1.4が出たので見ていきます

こんにちは、富士榮です。

この辺りのポストでも書いたAAMVAのMobile Driver's License(mDL) Implementation Guidelines 1.4を読んでいきたいと思います。（先月までは1.3でしたが11月末に1.4が出てました）

https://www.aamva.org/assets/best-practices,-guides,-standards,-manuals,-whitepapers/mobile-driver-s-license-implementation-guidelines-1-2

※相変わらずURLは1.2ですが、開けると1.4です。

目次から見ていきましょう。

本編

1. INTRODUCTION
2. mDL SOLUTION OVERVIEW
3. ISO/IEC 18013-5 QUALIFICATIONS
4. PRIVACY AND SECURITY
5. TRUST MODEL
6. mDL DATA REFRESH
7. MULTIPLE CREDENTIALS AND SHARED DEVICES
8. NO “FLASH PASS” USE
9. REVOCATION IN CASE OF OUT-OF-STATE/PROVINCE/TERRITORY ACTION
10. PROVISIONING
11. MISCELLANEOUS

Applendix

A. MDL UPDATE/DELETE OPTION COMPARISON

B. MANDATORY REQUIREMENT LIST; CERTIFICATION TYPE

C. MDL USE “OVER-THE-INTERNET”

D. CERTIFICATE REQUIREMENTS TO WHICH COMPLIANCE CAN BE SELFCERTIFIED

E. PROVISIONING REASON CODES

F. AUSTROADS REQUEST/RESPONSE PROTOCOL

目次レベルで言うと、1.3と比べてAppendix Fが増えてますね。

次回から順番に見ていこうと思います。