こんにちは。GMOグローバルサイン・ホールディングスCTO室でVerifiable Credentialsを担当している神沼@t_kanumaです。
前回の記事「EUDIW ARF v2におけるWallet Unit Attestationの整理」からしばらく間が空いてしまいましたが、EUDIWのARFの動向を久々にキャッチアップしています。
以前はv2.4.0をARF本体とAnnex 2を中心に読み込んでいたのですが、最新版はすでにv2.8.0までアップデートされています。EUDIWはVCの世界で最も発展しているエコシステム、プロジェクトの1つと言えると思いますから、1つのモデルとして、また現在自分たちが取り組んでいるプロジェクトとの比較材料としても、アップデートを追いかけておくことは今後に向けて非常に有益だと感じており、少しずつでも理解を深めていきたいと考えています。
そこで、自身の理解を整理する備忘録の意味合いが強くなりますが、Change Logをもとにアップデート内容を数回に分けてアウトプットしていければと思います。本稿ではv2.4.0からv2.6.0へのアップデート内容を追いかけてみます。(v2.5とv2.6のChange Logの内容が全く同じであったため後者を見ていきます。)
もし誤った理解や違和感のある表現等があれば、ぜひコメント等でご指摘いただければ幸いです。
v2.4.0からv2.6.0への主要なアップデート
Change Logを眺めると大きく2つのアップデートがあります。
- PID/(Q)EAAのCatalogue周りの構造変化
- Device Bindingにおける緩和
1. Catalogue周りの構造変化
ARF v2.6.0 – 5.5. Catalogue of Attributes and Catalogue of Attestation Schemes
v2.4の時点では、Catalogueの中に各Attestation(e.g. mDL、PID、卒業証明書…)のRulebookが並んでいるという比較的シンプルな構造のように読み取れていました。Rulebookには、Attributes Schema、Attestation Format、Legal Requirementなどその運用スキームが定義されており、いわば特定のAttestationの設計図、仕様書という位置付けであったと理解しています。
これがv2.6では、Topic Oでの議論を経て運用の効率化と相互運用性を高めるため、AttributesとAttestation Schemeという2つのCatalogueに分離され具体化されています。
1.1 Catalogue of Attributes
このCatalogueは、個別のAttributeを定義するものです。
ここでのAttributeとは、例えば個人においては住所や資格証明書、法人においては企業情報など、さらにその中の細かい項目を持つ抽象化されたコトを指していると理解しています。
Article 45e(2) of Regulation (EU) 2024/1183 empowers the Commission to establish specifications and procedures for: (i) the catalogue of attributes, (ii) the catalogue of attestation schemes, and (iii) verification procedures for qualified electronic attestations of attributes.
引用元: 5.5 Catalogue of attributes and catalogue of attestation schemes
そのことは上記の本文より参照されているRegulation (EU) 2024/1183 of the European Parliament and of the Council of 11 April 2024 amending Regulation (EU) No 910/2014 as regards establishing the European Digital Identity FrameworkのAnnex VI: MINIMUM LIST OF ATTRIBUTESにてAddressやEducational qualifications, titles and licencesなどが列挙されていることから読み取れます。
このカタログの目的は、ARF本文の以下の通り、QTSP(Qualified Trust Service Provider)として認定されていて、QEAAを発行するQEAA Provider向けのモノであり、発行フェーズにおいてUserから提示されたデータの真正性を確認するためのAuthentic Sourceの所在を見つけるためのCatalogueです。
The catalogue of attributes is exclusively intended for use by QTSPs issuing QEAAs, and enables them to find the access point of the Authentication Source responsible for a given attribute, at which the QTSP can verify the value of that attribute for a given User.
引用元: 5.5.2 Catalogue of attributes
以下のARFの全体図においては「QEAA Provider(5) → Authentic Source(9)」の矢印とそのラベルである「Provides Verification Service」部分に該当していると理解しています。
引用元: Figure 1: Overview of the EUDI Wallet ecosystem roles
このCatalogueにはAttribute単位でエントリが存在し、そのデータモデルの中には、nameやidentifier、description、外部のJSON Schema定義への参照に加えて、どのAuthentic Sourceに問い合わせればそのデータを確認できるかというDiscoveryのためのプロパティ情報も含まれています。これにより、Userが卒業証明書のAttestationの発行を望む場合、Issuer(QEAA Provider)はCatalogueを参照することで、その大学のデータソース(Authentic Source)に正しくアクセスでき、またユーザからの入力情報を検証することができる仕組みになっている理解です。
データモデルやインターフェイスの詳細は以下のTechnical Specificationに記載されています。
TS11 – 3. Specification of interfaces and formats for the Catalogue of Attributes
1.2 Catalogue of Attestation
5.5.3 Catalogue of attestation schemes
こちらは以前からあるRulebookが機械向けに新たにカタログとして定義されたものです。前述の通り、Rule Bookは各種Attestation(e.g. mDL、PID、卒業証明書…)ごとに存在し、その運用スキームが人間向けに定められていました。
この機械向けのカタログの新設により、Attestation Provider(Issuer)は何をAttestationに盛り込むべきか、RP(Verifier)はどう読み取るべきかをソフトウェアから静的または動的に判断できる材料になっていると理解しています。
Rulebookが持つおおまかな情報、およびCatalogの正確なデータモデルやインターフェイスの詳細は以下のTechnical Specificationに記載されています。
TS11 – 4. Specification of interfaces and formats for the Catalogue of Attestations
その中には以下の記述があり、Attestationが持つ属性情報の定義において、前述のCatalogue of Attributesへの参照を持てると記述があり、2つのCatalog間の繋がりが見えました。
attribute definitions or pointer(s) to the catalogue of attributes (Ed note: URI to Semantic Repository)
2. Device Binding周り
Discussion Topic Zで議論されていたDevice-Bound AttestationsとNon-Device-Bound Attestationの扱いが整理され、本体に統合されています。
2.1 Topic Zの議論
以前のARFでは、全てのAttestationはWSCDに紐付いていなければならないという前提に立っていたと認識しています。しかし、Topic Zでは「イベントチケットや割引券のような低セキュリティなAttestationまで、ガチガチに紐付ける必要があるのか?」という議論が行われてきました。
結果としてPIDには引き続きDevice Bindingが義務付けられる(SHALL)一方、(Q)EAAについては、原則として実装すべき(SHOULD)としつつ、低保証レベル(LoA)や特定のユースケースに限り、PoP(Proof of Possesion)を必要としないNon Device-Boundな発行も可能という方針に緩和されていると理解しています。
ISSU_17 A PID Provider SHALL implement device binding for all PIDs it issues, meaning it SHALL ensure that a PID is cryptographically bound to a WSCA/WSCD included in the Wallet Unit, as specified in requirements WUA_11 – WUA_11b in [Topic 9]. Note: Device binding is called ‘mdoc authentication’ in [ISO/IEC 18013-5] and ‘key binding’ in [SD-JWT-VC].
引用元: Annex2: B – HLRs for PID issuance
ISSU_27 An Attestation Provider SHOULD implement device binding for all attestations it issues. If an issued attestation is device-bound, the Attestation Provider SHALL ensure that the attestation is cryptographically bound to a WSCA/WSCD included in the Wallet Unit, as specified in requirement WUA_11 – WUA_11b in [Topic 9]. Notes: Device binding is called ‘mdoc authentication’ in [ISO/IEC 18013-5] and ‘key binding’ in [SD-JWT-VC]. – Implementing mdoc authentication is mandatory in [ISO/IEC 18013-5]; therefore, it is mandatory for attestations complying with that standard.
引用元: Annex2: C – HLRs for Attestation Issuance
それに伴いARF本体の要件において、必要な箇所に「PIDもしくはdevice-bound attestationの場合に」、という条件が加えられています。例えば提示フェーズでは、RPがPoPを検証することに対し、PIDもしくはdevice-bound attestationの場合にそれを行うという記述に変わっています。また発行フェーズにおいても、AttestationのSubjectの鍵が、WUA(Wallet Unit Attestation)の鍵と同じWSCA/WSCDに保管されていることを証明するくだりで、同様の条件が追記されています。
3. 備考: Cryptographic Binding
過去のブログ記事でも何度か触れてきた「PIDもしくはdevice-bound attestationのSubjectの鍵がWUAの鍵と同じWSCA/WSCDで保管されていることの証明」についてですが(Change Logに記述がないためその通りなのですが)特にアップデートありませんでした。今後のためにおおまかにここで状況を整理すると、
ARF本体では以下のenvisionedの記述の通り、まだ構想途中であることが読み取れます。
Cryptographic binding between attestations is an envisioned cryptographic mechanism that enables a WSCA/WSCD to prove that it manages the private keys corresponding to two (or more) public keys. Such a mechanisms can be used during attestation issuance, for instance to prove that the public key included in a PID and the public key to be embedded in a newly requested device-bound attestation are both managed by the same WSCD.
引用元: 6.6.3.10.2 Cryptographic binding between attestations
Annex 2においては、ゼロ知識証明を用いることが望ましいこと、またOpenIDVCIにおいて拡張仕様もしくはプロファイルの策定が必要になる可能性について言及されています。
ACP_03 A Cryptographic Binding of Attestations scheme SHOULD be implemented using a Zero-Knowledge Proof mechanism that satisfies the requirements specified in Topic 53.
ACP05 A Cryptographic Binding of Attestations scheme SHALL enable an Attestation Provider, during the issuance of an attestation, to request and obtain proof that the private key for the new attestation is managed by the same WSCA/WSCD as the private key of a PID or another attestation already existing on the Wallet Unit. Note: ACP_05 and ACP_06 may require an addition to the common OpenID4VCI protocol referenced in requirement ISSU_01, or an extension or profile thereof.
引用元: A.2.3.18 Topic 18 – Combined presentations of attributes
おわりに
本稿では、v2.6.0へのアップデートについて述べました。また折りをみてv2.6.0からv2.7.3へのアップデート内容について記事にしたいと思います。
