EUDIW ARF v2.0やEIC2025に関するキャッチアップ

AI

こんにちは。GMOグローバルサイン・ホールディングスでVerifiable Credentialsの研究をしている開発者の神沼@t_kanumaです。

本稿は、以下の記事の続編として執筆したものです。

2024年の分散型アイデンティティ領域の潮流の考察とKERIについて

当時は「EUDI Wallet – Architecture and Reference Framework(以下、ARF)」のバージョンが1.4でしたが、2025年6月現在、ARFはv2.0にアップデートされています。本記事では、前回の記事で深掘りしたいと述べていたポイントを中心に、最新のARF v2.0やEIC2025で得た情報を整理しつつ、自身の理解や注目点について記録しておきたいと思います。

もし誤った理解や違和感のある表現等があれば、ぜひコメント等でご指摘いただければ幸いです。

目次

インプットした情報

前回の記事以降、以下のような新たな情報をキャッチアップしました。

  • EIC 2025(European Identity and Cloud Conference 2025)
  • ISO mDL/mdoc関連
    • ISO 18013-7:2024
    • AAMVA Trusted List
  • EUDIW ARF v2.0.0

1. EIC 2025

1.1 AIdentity

昨年に引き続き、EIC2025を聴講しました。分散型アイデンティティに関するセッションも引き続き活発でしたが、今年の最大のテーマは「AIとアイデンティティ(AIdentity)」でした。

AIdentityに関する自身が聴講したセッション数を比較すると、昨年は18件だったのに対し、今年は32件と大きく増えており、注目度の高さが伺えます。

AIdentityには大きく2つの側面があると理解しています。

  1. AI for Identity: IAM(Identity and Access Management)やIGA(Identity Governance and Administration)といった既存の枠組みに生成AIを組み込み、効率化やセキュリティ強化を図る取り組み。
  2. Identity for AI: AIエージェントそのものを対象とし、アイデンティティをどのように付与・管理するかという側面。

特に後者のIdentity for AIについて、以下のような議論やトピックが挙げられていました。

  • AIエージェントが人間の代理として自律的に行動する時代において、「誰が所有者で」「誰のために行動しているのか」といった情報の明確化が求められている。
  • AIエージェントをIAM上の主体として扱い、人間と同様に認証・認可・監査の対象とするという考え方が広まりつつある。
  • 認証・認可の基盤として、OAuth 2.xやMCP等、AIエージェント向けのフローの標準化が進められている。
  • AIエージェントによるデータおよびサービスへのアクセスが増加する中、アクセス制御ポリシーの高度化や行動ログの監査性がますます重要になっている。
  • AIによるなりすましや不正利用に対する対策として、「Proof of Personhood」への注目が高まっており、プライバシー保護と両立させた信頼性のあるエコシステムの構築が模索されている。

これらの動きは、将来的にはVerifiable CredentialsやDigital Identity Walletとも結びついてくる可能性があると考えられ、今後も注視していきたい分野です。

1.2 ユースケースの一部としての電子署名

まずEUDIWにおける主要機能は以下の3つだと理解しています。

  • PIDやQEAAなどのAttestation(いわゆるVerifiable Credentials)
  • Qualified Electronic Signature(QES)
  • Pseudonyms: 各Relying Partyに対して異なる公開鍵ペアを用いた認証手法(標準としてFIDO2、実装としてPasskeyが該当)

今年のEICでは、複数のセッションにおいてEUDIWのユースケースにおける電子署名の存在が強調されている点が印象的でした。ARFではAttestationが主要なトピックとして扱われていますが、例えば以下のような一連のプロセスにおいて、電子署名との組み合わせがユースケースの中で意識されていると感じました。

  1. PIDの提示による身元確認
  2. Attestationの提示によるアクセス権や認可の取得
  3. その結果として契約や規約への同意を電子署名で実施

1.3 Business Wallet / Organization Wallet

今年のEICにおいて、分散型アイデンティティ関連のセッションの中で目立っていたトレンドの1つがBusiness Wallet(組織向けウォレット)の話題でした。

ARFでも、法人によるPID/Wallet運用の可能性が記述されていますが、とあるセッションでは、これまでのEUDIWのユースケースでは、個人向けの身元確認・当人認証が主題であり、企業・組織のユースケースが軽視されているという課題意識が共有されていました。

提示された具体的なユースケースは以下の通りです。

  • 新たなビジネスパートナーのオンボーディング(Know your Supplier / Know your Business)
  • 法人名義での銀行口座開設(KYC)
  • 他国での支社開設
  • 会社代表者が法人を代表して行動する場合の証明

重要な動きの一つとして捉えられるのが、2025年9月に終了予定のパイロットプロジェクトであるEWCの後を継ぐ形で、WE BUILDというコンソーシアムが新たに立ち上がり、Business Walletに特化したパイロットプロジェクトを実施するという取り組みです。

他には、Business Walletは単独では存在しえず、自然人のWalletとの連携が不可欠である点が強調されていました。ここに通じると予想している事として、ARFにおいてWallet-to-Wallet Interactionが議論されています。また技術的には、個人向けWalletがモバイルデバイスベースであるのに対し、法人向けは常時稼働するサーバーサイドWalletが前提とされ、業務システムとの統合性が重視されている説明もありました。

取り扱うVerifiable Credentialsの種類についても説明があり、eIDAS 2.0の文脈においては組織用のPIDであるLPID(Legal Person Identification Data)があり、EU Digital Company Law Directiveという枠組みの中では、EU Company Certificate(EUCC)やDigital Power of Attorney(PoA)といった要素も存在している模様です。

私自身、現在の研究テーマがKERIやvLEIであるため、この領域はまさに注視すべき対象です。vLEIはBusiness Walletを前提とした仕組みですが、EU圏内においてはLPID等の標準が整備されつつあり、vLEIはEU内では第一選択肢にはなりにくく、クロスボーダーでの利用に使われる可能性の方が高いのではないかと思っています。

まだ個人向けほど注目されてはいませんが、Relying Partyにおける不正行為やなりすましの防止や検出、コンプライアンス対応、透明性の確保といったビジネス上の観点から、今後確実に重要度が増していくと考えられます。

2. ISO mDL / mdoc

2.1 AAMVA Trusted List の解析

Trusted Listに対する理解を深める上で、実際にその実例を確認することが有効だと考えました。以下の理由から、解析対象としてAAMVAが運用するTrusted List(VICAL)を選びました。

  • EUのeIDAS 2.0のTrusted Listは現時点ではまだ整備中である。(未公開?)
  • 日本のマイナンバーカードmdocではTrusted Listが存在しないと思われる。
  • VICALは実運用されており公開されている、かつISO 18013-5に準拠している。

このTrusted ListはCBOR形式のファイルであり、中にX.509証明書群が含まれています。解析の目的は、ISO 18013-5で定義されているTrust ModelおよびCertificate Profileに対し、実際の実装が一致していることを確認することでした。（実際に抽出し一致することを確認できました。)

VICALの規約により詳細をここで開示することはできませんが、理解を深めるための実践的アプローチの一例として紹介しました。

2.2 ISO 18013-7

こちらも文書の規約上、技術的な内容には具体的に触れられませんが、後述するDigital Credentials APIに関連して、OID4VPにおいてどのようにオプションを絞るかが、1つのポイントになっている印象を受けました。

3. EUDIW ARF v2.0.0

3.1 Digital Credentials API

前回の記事の中で、現在のメインストリームにおいてはWallet Attestationがホットトピックであると述べましたが、それと並行して、リモート提示におけるVerifierからHolderへのCredential提示要求に対し、User AgentとWalletがどう連携するかという点も、非常に重要なテーマになっていると思います。

v1.4では明記されていなかったこの領域について、v2.0ではDigital Credentials APIに関する記述が新たに追加されました。

本トピックに関しては、間接的な事項になりますが別途以下の記事で解説していますので、ご興味があればご覧ください:

OID4VPのSession Fixationについての整理

3.2 Trusted List

Trusted Listにおいて、v1.4では以下の概念レベルの記述にとどまり、PIDやAttestation、Access Certificate等のトラストモデルにおける具体的な実装、特に公開鍵証明書のフォーマットについては各加盟国に委ねるというスタンスでした。

This trust model does not presume a specific implementation. In particular, the use of term ‘certificate’ does not imply a specific format. Depending on implementation, it may be an X.509 certificate or another format specified in the context of any other trust framework. Similarly, a ‘Certificate Authority’ may be implemented as a ‘classical’ X509-based CA according to [RFC5280] and [RFC3647], or as a trusted third party binding public keys to entities in any other trust framework.

引用元：ARF v1.4.0: 6. Trust model

一方、v2.0では次のように記述が変更されており、非QualifiedなEAAを除いて、PKI/X.509証明書を用いることが明示されている模様です。

For Access Certificates, PIDs, qualified EAAs, and PuB-EAAs, interoperability is essential (Section 4.2.2) and is achieved by using a PKI following X.509 certificate standards (RFC5280, RFC3647). Non-qualified EAAs may adopt alternative trust models and verification mechanisms.

引用元：ARF v2.0.0: 6. Trust model

3.3 Wallet Unit Attestation

このトピックは分量が多くなるため、別記事として後日公開する予定です。

最後に

簡潔ではありますが、EIC2025やEUDIW ARFを中心とした最近の動向について、自身の理解を整理しつつキャッチアップを行いました。今後もこの領域の変化を引き続き追っていく所存です。

本記事が、どなたかのお役に立てれば幸いです。