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

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