EUDIW ARFのアップデートを追ってみる (v2.6 ~ v2.7.3)

Decentralized Identity

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

前回の記事ではv2.4.0からv2.6.0への更新内容を整理しました。今回はその続編としてv2.6.0からv2.7.3（2025/11/13リリース）へのアップデートを追っていきたいと思います。

2026年5月に開催されたEuropean Identity Conferenceにおいても、（あくまで個人的に注目したセッションの範囲内ではありますが）Agentic AIとIdentityに関するセッションはおおよそ15件、一方EUDI WalletやVerifiable Credentialsに関するセッションはおおよそ25件と、年末のリリースを間近に控えていることもあり、これらを取り巻く盛り上がりはさらに加速しているように感じました。それゆえ、引き続きアップデートを追いかけておくことは今後に向けて非常に有益だと感じており、少しずつでも理解を深めていきたいと考えています。

もし誤った理解や違和感のある表現があれば、ぜひご指摘ください。

目次

v2.6.0からv2.7.3への主要なアップデート

Change Logを見ると、Discussion Topic F, P, R, SがARF本体およびAnnex 2へ統合されたことが大きな変更点です。

それぞれを詳しく見ていきます。

Topic F: Digital Credentials API

大枠での大きな変更はありません。 引き続き、Digital Credentials API（DC API）がW3C勧告（Recommendation）となり実装が普及次第、そのサポートが必須になるという方針です。現状、まだDC APIの仕様はDraft状態であるため必須ではなく、引き続きカスタムURIを使うことが許容されていると理解しています。

細かな変更点としては、以下のようなものが挙げられます。

  • DC APIの実装が満たすべき、機能性、中立性、プライバシー、およびガバナンスに関する重要な期待事項がARF本体に追記されています。その中では、ユーザーによるウォレット選択において、Attestaionの提示時だけではなく、発行時においてもDC APIを使うことが必須になることが明示されています。
  • Cross DeviceフローにおけるUser AgentとWallet Instanceの間のCTAPプロトコルにて、以下の特定の要求事項が追記されています。
    • 短距離トランスポート（BLE, NFC, USB）を優先するが、Hybridトランスポート方式（BLEによる近距離に存在することの証明に加えて、データ通信ではインターネット上のリレーサーバを介する方式）もサポートしなければならないとされています。
    • Hybrid方式において、ブラウザおよびOSはEUの監視配下にあるトンネルエンドポイントをサポートしなければならず、またユーザーはトンネルエンドポイントを選択できることが望ましいとされています。（これは、例えばGoogleなど特定のサービスプロバイダに依存しないことを目的とするためにあると理解しています。）

Topic P: Wallet Instance – WSCA間のインターフェース

Topic Pでは、Wallet InstanceとWallet Secure Cryptographic Application（WSCA）の間のインターフェースについて、調和（harmonization）の必要性が議論されています。ここでの”harmonization”とは、間のインターフェース仕様を統一すべきかどうかという論点を指していると解釈しています。

議論の背景として、WSCAを誰が提供するのかによって状況が異なる点が挙げられています。具体的には、Wallet Providerが提供する場合と、WSCAの背後に位置するWallet Secure Cryptographic Device（WSCD）のProviderが提供する場合では、責任分界点や実装形態が異なることが指摘されています。前者では、WSCAとして例えばJava Cardアプレットが挙げられると思いますが、WalletもWSCAも自社提供であるため、インターフェースは自由に設計できる一方、後者ではWallet ProviderはWSCD Providerが定めたAPI（例: OS標準のAPI）に合わせるしかないといったことが考えられます。

検討にあたっては、既存のHLR（High-Level Requirements）の各項目の整理、および既存技術の整理がまずされています。WSCAの候補としては、Android Keystore API、Apple Keychain Services/CryptoKit、JavaCardアプレット、PKCS#11モジュール、KMIPクライアントなどが挙げられています。WSCDとしては、eSIM、eSE、リモートHSMが明示されているほか、Android環境ではStrongBoxやTEE、Apple環境ではSecure Enclaveについて言及されています。

このように、多様な実装方式を踏まえて検討が行われた模様ですが、最終的にARF Annex 2への新たなHLRの追加や既存要件の変更は提案されていません。 (これは、WSCDのアーキテクチャごとにWSCAが異なるのは自然であり、それを無理に統一する必要はないという結論だと解釈しています。)

その代わりとして、WSCAとWSCDは必ずしも密結合されたコンポーネントではないことが明確化され、反映されています。これにより、WSCAはWSCDの種類に応じて様々な形態で実装され得ること、また両者の関係は必ずしも一対一ではないことが、より明確化された形になったと理解しています。

Topic R: ユーザーのデバイスに対する認証

背景：WSCDの定義の明確化

従来のARFでは、暗号鍵を管理するセキュアなデバイスはWSCDとして定義されており、TEEやSecure Enclaveのように、LoA Highを満たせるか不確定なものもWSCDに含まれていました。LoA Highはあくまで別に課された要件にすぎず、WSCDの定義自体には含まれていなかったと理解しています。

また、あらゆる暗号操作の前にWSCA/WSCDレイヤーでのユーザー認証が求められており、これはOS認証とは概念的に別のレイヤーです。実装によってはユーザーが二重に認証を求められる場合があり、PIDの提示もイベントチケットの提示も同じ厳格さが求められることになっているなどユーザー体験が最適化されていない面があったと理解してます。

Topic Rでは、これらが以下のように整理されました。

WSCDとキーストアの分離

まず、WSCDはLoA Highの評価を満たすデバイスであることが明確化されました。PIDやWUA（Wallet Unit Attestation）など、本人確認の根幹に関わる暗号鍵はここで管理されます。

そして、LoA Highの要件を満たさないものはKeystore（KS）として分離されました。Keystoreはハードウェアに裏付けられた鍵管理の仕組みであり、SE、TPM、TEE、Secure Enclave、リモートHSMなどが例として挙げられています。LoA Highの評価は求められず、高い保証レベルを必要としないアテステーションの鍵を管理する用途が想定されています。

認証におけるユーザ負担の軽減

この分離がユーザー体験に直結します。WSCDで管理される鍵を使う場合、認証は2段階になります：

  1. Wallet InstanceへのOS認証
  2. WSCA/WSCDによる認証（例：SE自体のPIN入力、リモートHSMへのネットワーク認証など）

キーストアで管理される鍵であれば、No.2のWSCA/WSCDによる認証が不要となります。ユーザーから見れば、OS認証1回で暗号操作まで完了します。日常的に頻繁に使うアテステーションほど、この差がユーザー体験に効いてくることになります。

また、付随する情報として、No.1のWallet Instanceへの認証についても見直しがなされました。デバイスのOS認証が基本かつ必須であり、ウォレット固有のPINはOS認証に加えて使うオプションという位置付けに整理されました。

まとめ

全体として、WSCDの定義を明確化し、キーストアを分離することで、PIDやWUAなど高保証が必要な場面ではLoA Highの厳格な認証を維持しつつ、日常的な用途では認証負担を軽減する方向で整理が進められています。

Topic S: Certificate Transparency

Access Certificateとは、以前の記事でも触れましたが、Attestation Provider（Issuer）およびRelying Party（Verifier）に対し発行されるX.509証明書のことです。Attestationの発行および提示の際に、Wallet UnitがそれをTrusted Listを用いて検証することで、Attestation ProviderおよびRelying Partyの信頼性を担保する仕組みになっていると理解しています。

今回のアップデートにより、このAccess Certificateに対し、Web PKIですでに実施されているCertificate Transparency（CT）の導入が必須とされました（ただしCTログが利用可能になった場合）。おおまかな仕組みは以下の通りです。

  1. Access Certificateの発行において、Access Certificate Authority（CA）はCTログに対してそれを登録します。
  2. CTログは登録の証拠として、Signed Certificate Timestamp（SCT）をCAに返却します。
  3. CAはSCTをAccess Certificateに埋め込み、Attestation ProviderおよびRelying Partyに証明書を渡します。
  4. Web PKIにおけるブラウザと同じように、Wallet UnitはこのSCTの有効性を検証することで、CTログに直接問い合わせることなく（プライバシーを保ちつつ）、証明書が正しく記録されていることを確認します。

ここで気になるのが、EUDIWにおけるCTログプロバイダーの存在ですが、結論としては、CTログの提供主体もインフラの構築方針も未定で、「今後議論・決定すべき課題」として残されている状態だと理解しています。

Discussion Paperには、現時点では欧州にCTログプロバイダーは存在せず、この状況への対処はARFの範囲外であるとの記述があります。また、同ペーパーでは以下の2つの選択肢が提示されています。

  • 既存のCTログプロバイダー（Google、Cloudflare等）に、EUDIエコシステムのCAが発行した証明書も受け入れてもらう。
  • 欧州委員会が独自のCTログインフラストラクチャを構築する。

おわりに

次回はv2.7.3からv2.8.0へのアップデートを追っていきたいと思います。

どなたかの参考になれば幸いです。