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

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

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 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 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つのみである。

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 とは別のクレデンシャルの発行にも採用できる。

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

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 1.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 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保持者以外の者がアクティビティログにアクセスできないようにする必要があります。

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

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

ついにこの日が来ました。

去年の正月休みに某猫とのチキンレースが始まってしまったので収まりがつかなくなって惰性で描き続けていましたが気がついたら本当に1年経ってしまいました。

↓某猫のポスト

ふじえさん、やっぱりやっとるな！
毎日記事を書く366チャレンジや！
これ絶対やっとるぞ！

— 👹秋田の猫🐱 (@ritou) January 4, 2024

最初のうちは割と実装してみよう！的なポストが多かったのですが、中盤〜後半は忙しくなりすぎたこともあり読んでみようシリーズが大半を占めてしまったのは反省です。

ということで振り返ってみましょう。

1月のポストはこんな感じです。

あとは1月はOpenID Summit Tokyoもありましたね。2024年の後半にかけて現在も活動が続いているSIDI Hubを日本で開催する調整も実はこの時期から始まっていました。

次に2月です。この辺りでそういえば今年は366日やん、と思って他の年よりも1日不利！！！ということに気がついた感じです。

3月です。

4月です。

5月です。

色々と読むものが多かった気がします。

6月です。

他にも色々なドキュメントが公開されたので読み込む系のポストが増えてきていますね。

7月です。

折り返し地点です。

8月です。

この時期はトラスト、とか本人確認や身元確認へのデジタルクレデンシャルの利用について割と真剣に考え始めている時期だったのでそういうニュアンスのポストもしていますね。まだまだ適当な実装が多いこの世の中なので、みんな真剣に考えていけるといいですね。

9月です。

10月です。

国際イベントのハンドリングや準備は何度やっても良い経験になりますね。しんどいけど。

11月です。

12月です。ついに終わります。

ということであっという間に1年が経ってしまいました。

で、来年はどうするの？という話ですが、まぁ習慣化してしまったところなので今後も無理しない程度に書いていこうとは思いますが、適度に休む必要性も同時に感じているので毎日は描かないかなぁ、と思います。クォリティも落ちますしね。

ということでみなさん、良いお年を！

Intention Economyで検索すると結構ヤバ目の結果が返ってくるようになっているとのこと。

The near future could see AI assistants that forecast and influence our decision-making at an early stage, and sell these developing “intentions” in real-time to companies that can meet the need – even before we have made up our minds.

近い将来、AI アシスタントが早い段階で私たちの意思決定を予測して影響を与え、私たちが決断を下す前であっても、その発展中の「意図」をニーズを満たすことができる企業にリアルタイムで販売するようになるかもしれません。

The rapid proliferation of large language models (LLMs) invites the possibility of a new marketplace for behavioral and psychological data that signals intent.

大規模言語モデル (LLM) の急速な普及により、意図を示す行動および心理データの新しい市場が生まれる可能性が生まれています。

もともと顧客の関心（Attention）を商品として販売するというモデルに対するアンチテーゼの文脈としての意図（Intention）を中心とした経済としてIntention Economyだったはずですが、その意図自体を商品として販売する、という市場が形成されてきつつあるということですね。

人間の欲望は果てしないわけですが、私たちは思想の源流をきちんと見据え、意図を理解した上で社会実装を進めたいものです。 

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

AAMVAのモバイル運転免許証のガイドラインでも触れましたが、mdocやSD-JWTのリンク可能性へ対応するためには今後ゼロ知識証明が大切になります。

年末にGoogleの研究者が

Anonymous credentials from ECDSA

というタイトルでペーパーを出しています。

https://eprint.iacr.org/2024/2010

アブストラクトの中からポイントを抜粋すると、従来のBBS+では暗号スイートへの対応に関する要件が厳しかったのでレガシーで対応できるようにECDSAでもできるようにしたよ、ということのようですね。

Part of the difficulty arises because schemes in the literature, such as BBS+, use new cryptographic assumptions that require system-wide changes to existing issuer infrastructure.  In addition,  issuers often require digital identity credentials to be *device-bound* by incorporating the device’s secure element into the presentation flow.  As a result, schemes like BBS+ require updates to the hardware secure elements and OS on every user's device.

その難しさの一部は、BBS+などの文献に記載されているスキームが、既存の発行者インフラストラクチャにシステム全体にわたる変更を必要とする新しい暗号化前提条件を使用していることに起因しています。さらに、発行者は、デバイスのセキュアエレメントを提示フローに組み込むことで、デジタルID認証をデバイスに紐づけることを求めることがよくあります。その結果、BBS+のようなスキームでは、すべてのユーザーのデバイスのハードウェアセキュアエレメントとOSのアップデートが必要になります。

In this paper, we propose a new anonymous credential scheme for the popular and legacy-deployed Elliptic Curve Digital Signature Algorithm (ECDSA) signature scheme.  By adding efficient zk arguments for statements about SHA256 and document parsing for ISO-standardized identity formats, our anonymous credential scheme is that first one that can be deployed *without* changing any issuer processes, *without* requiring changes to mobile devices, and *without* requiring non-standard cryptographic assumptions.

本稿では、広く普及し、レガシーシステムにも導入されている楕円曲線デジタル署名アルゴリズム（ECDSA）署名スキームのための新しい匿名クレデンシャルスキームを提案する。 SHA256に関する効率的なzk引数と、ISO標準化されたIDフォーマットの文書解析を追加することで、この匿名クレデンシャルスキームは、発行者側のプロセスを変更することなく、モバイルデバイスの変更を必要とすることなく、また、非標準の暗号化前提条件を必要とすることなく実装できる初めてのスキームです。

 なかなか期待できますね。生成速度に関してもこのような記載があります。

Our proofs for ECDSA can be generated in 60ms.  When incorporated into a fully standardized identity protocol such as the ISO MDOC standard, we can generate a zero-knowledge proof for the MDOC presentation flow in 1.2 seconds on mobile devices depending on the credential size. These advantages make our scheme a promising candidate for privacy-preserving digital identity applications.

当社のECDSAの証明書は60ミリ秒で生成できます。ISO MDOC標準のような完全に標準化されたアイデンティティプロトコルに組み込まれた場合、クレデンシャルのサイズにもよりますが、モバイルデバイス上でMDOCプレゼンテーションフロー用のゼロ知識証明書を1.2秒で生成できます。これらの利点により、当社の方式はプライバシー保護型デジタルアイデンティティアプリケーションの有望な候補となっています。

mdocのプレゼンテーション時にゼロ知識証明を1.2秒で生成、このくらいなら実用性がありそうですね。

論文の本文もPDFで閲覧できるようになっているので、おいおい見ていこうと思います。