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

Decentralized Identity

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

前回の記事ではv2.6.0からv2.7.3への更新内容を整理しました。今回はその続編としてv2.7.3からv2.8.0(2026/2/3リリース)へのアップデートを追っていきたいと思います。

v2.8.0のChange Logを見ると、Discussion Topic T, AA, E, Rの最終版がARF本体およびAnnex 2へ統合されたことが大きな変更点です。Topic Rについては前回の記事で取り上げたため、今回はTopic T, AA, Eに絞って見ていきます。

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

目次

Topic T: Wallet Providerによるサポートとメンテナンス

背景

Topic Tでは、Wallet Providerがリリース後のWallet Solutionに対して行うサポートおよびメンテナンスについて、どのような要件を課すべきかが議論されています。

従来のARFでは、Wallet Providerのサポートおよびメンテナンスに関する要件は、WUA（Wallet Unit Attestation）のライフサイクル管理やWallet Unitの失効といった個別のトピックに分散して暗黙的に含まれているだけでした。例えばTopic 9ではWUAのライフサイクル管理、Topic 38ではWallet Unitの失効時のユーザー通知、Topic 40ではWallet Unitのライフサイクル管理が定められていましたが、メンテナンスそのものを体系的に扱うトピックは存在していなかったと理解しています。

今回のTopic Tでは、メンテナンスのためのデータ収集とセキュリティポスチャの監視という2つの観点が整理され、その内容がARF 2.8の新しいTopic 56などへ反映されました。

メンテナンスのためのデータ収集

Discussion Paperでは、Wallet Providerがメンテナンス目的で収集することが想定されるデータの一覧が整理され、その内容はARF本文6.5.3.2に反映されています。ランタイムエラーやクラッシュログ、OSバージョン、Wallet InstanceのバージョンやSDKバージョン、サポートするWSCA/WSCDの情報、デバイス固有識別子（iOSのIDFVやAndroidのAndroidID）などが挙げられています。

これらのデータは、アクティベーション時やセキュリティポスチャの継続的監視時に収集することが想定されています。また、UXテレメトリやロケールデータなどユーザーの行動に関わるものについてはユーザー同意が推奨されるなど、プライバシーへの配慮も明確にされています。

なお、eIDAS規則のArticle 5a(14)に基づき、Wallet Providerはウォレットサービスの提供に不要な情報を収集してはならず、個人データは他のサービスのデータと論理的に分離しなければならないとされている点は変わりません。

セキュリティポスチャの監視

もう1つの重要な追加が、Wallet Instanceのセキュリティポスチャの監視に関する要件です。

セキュリティポスチャ（Security Posture）とは、あるシステムやデバイスがセキュリティ上どのような態勢にあるかを総合的に評価したものという理解でいます。OSが最新のパッチを適用しているか、デバイスがRoot化やJailbreakされていないか、マルウェアに感染していないか、暗号鍵が安全に保護されているかといった複数のチェック項目から判断されます。企業のセキュリティ管理やモバイルデバイス管理（MDM）の文脈でも広く使われる概念だと思いますが、Topic TではこれをEUDI Walletに適用し、Wallet Providerが各Wallet Instanceのセキュリティの構えを継続的に把握し、リスクレベルに応じた対応を取るための枠組みとして導入されています。

この議論がTopic Tで取り上げられた背景には、決済領域との接点があります。EUの決済サービス指令（PSD2）では、銀行などの決済サービスプロバイダーに対し、不正取引を検知するためのトランザクション監視メカニズムの導入が義務付けられています。しかし、EUDI Walletから決済サービスプロバイダーなどのRelying Partyに対してデバイスの不正検知シグナル（位置情報や行動データなど）を直接提供することは、eIDAS規則のプライバシー保護の原則に反するため、ARFでは想定されていません。

その代わりとして、Wallet Provider自身がセキュリティポスチャを定期的にチェックするという方針が取られています。この内容はARF本文に6.5.3.2.3「Data collection for fraud or risk signal monitoring」として新設されたセクションに反映され、Annex 2ではWPSM_03として「Wallet Providerは、Wallet Instanceが動作する環境における重大なセキュリティリスクを検出する目的で、セキュリティポスチャを監視しなければならない（SHALL）」というHLRが追加されました。具体的な監視対象としては、デバイスのRoot化/Jailbreak検出、エミュレータ検出、OSバージョンとヘルスデータ、Wallet SDK・ライブラリのバージョン、Wallet Instanceのバージョン、サポートするWSCA/WSCDとKeystore、センサー識別子とパッチレベルの7項目が挙げられています。一方、行動データ、地理位置情報（IP/GNSS）、VPN検出、通話中検出などは、ユーザーの行動パターンに関わるものであり、プライバシー保護の観点からWallet Providerによる収集は不適切とされています。

4段階のセキュリティポスチャフレームワーク

Discussion Paperでは、Wallet Providerが検出結果に基づいて対応を判断するための4段階のセキュリティポスチャフレームワークも提案されています。この4段階のセキュリティポスチャフレームワークはARF本文6.5.4.2にも反映されています。ただし、ARFでは「Wallet Providerがこのフレームワークを使用できる（can potentially use）」という表現になっており、必須ではなく推奨的な位置付けです。

  • Level 4（Critical）: Root化/Jailbreakの確認、アクティブなデバッガまたはエミュレータの検出、秘密鍵の漏洩、Wallet Instanceの改ざん検出などが該当し、WUAの失効およびクリーンなデバイスへのWallet Instanceの再インストールが求められます。
  • Level 3（High Risk）: パッチ未適用の高リスクOSバージョン検出、WSCDへの接続エラーの繰り返しなどが該当し、Level 4と同様にWUAの失効が行われた上で、step-up認証の要求やWallet Unitの再アクティベーションが求められます。
  • Level 2（Moderate Risk）: 軽微な整合性チェック失敗やPIN入力失敗（低閾値）などが該当し、高い価値を持つトランザクションの制限やアイドル後の再認証強制が想定されます。
  • Level 1（Low Risk）: デバイス認証成功、整合性チェック通過、OSパッチレベルが最新である状態で、すべての機能が利用可能です。

既存HLRであるTopic 38のWURevocation_09のNote部分にも、「ARF本文6.5.4.2のセキュリティポスチャフレームワークにおけるCriticalまたはHigh Riskに該当する場合は、WPSM_03の監視結果に基づいて失効が求められる」という参照が追加されました。

Topic AA: 電子決済におけるSCA(Strong Customer Authentication)のサポート

背景

Topic AAを理解するには、まずEUの決済領域における規制の前提を押さえておく必要があります。

EUでは、オンライン決済のセキュリティを確保するために、PSD2（Payment Services Directive 2）という規制が存在します。PSD2の要件の1つが、SCA（Strong Customer Authentication ）です。これは、ユーザーが電子決済を開始する場合、オンラインで決済口座にアクセスする場合、あるいは不正リスクを伴うリモートチャネルでの操作を行う場合に、銀行などの決済サービスプロバイダーが多要素認証を求めなければならないというものです。

一方、eIDAS規則のArticle 5f(2)では、銀行・金融サービスのプロバイダーがユーザーに対し、EUDI WalletによるSUA(Strong User Authentication)の実行を許可しなければならないとされています。（PSD2ではSCAという用語が使われているのに対し、eIDAS規則ではSUAという用語が使われていますが、ARFでは、このSUAはPSD2で定められたSCAの要件に適合することを意味すると解釈している、という注釈があります。）つまり、EUDI WalletがPSD2の求めるSCAの手段として利用できるようにすることが、規制上求められているわけです。

これらの規制要件を受けて、ARFでは先行するTopic W（トランザクションデータ）の議論においてSUA（Strong User Authentication）アテステーションという概念が導入され、Topic 20のHLR（SUA_01〜SUA_06）として整備されました。

Topic AAは、このSUAアテステーションの仕組みを前提に、Large Scale Pilots（EWCおよびNobid）での実証も踏まえつつ、既存HLRの文言修正やSUA_02a、SUA_07の新規追加を行い、SCAをWallet上で実現するための要件をさらに詰めたものという位置付けになっているものです。

SUAアテステーションの仕組み（Topic Wで導入済み）

Topic AAの具体的なアップデート内容に入る前に、前提となるSUAアテステーションの仕組みを整理しておきます。この仕組み自体はv2.8以前にTopic Wの成果としてすでに導入されていたものであり、ARF本文のSection 2.6.4に概要が、またAnnex 2 Topic 20にHLRが記載されています。

SUAアテステーションとは、EUDI WalletをPSD2が求めるSCA（多要素認証）の手段として機能させるために、サービスプロバイダーがWallet Unitに対して発行する専用のアテステーションです。決済時にはユーザー認証（PINや生体認証）とdevice-boundの秘密鍵の所持により、SCAが求める「知識（PINなど、ユーザーだけが知っているもの）」または「生体（生体認証など、ユーザー自身の特徴）」と「所持（WSCD/Keystoreに格納された秘密鍵を持つデバイス）」の2要素を満たします。さらに、その秘密鍵でトランザクションデータ（金額や受取人など）に署名することで、PSD2が求めるDynamic Linking（ユーザーの同意が特定の取引に紐付いていることの保証も実現します。

その仕組みは、大きく登録フェーズと決済フェーズに分かれます（ARF本文2.6.4参照）。

まず登録フェーズでは、サービスプロバイダーがWallet Unitに対してSUAアテステーションを発行します。Discussion Paperでは、このサービスプロバイダーはASPSP（Account Servicing Payment Service Provider、例えば銀行）に該当するとされています。このアテステーションはdevice-boundであり、公開鍵が含まれていて、対応する秘密鍵はWSCDまたはKeystoreに格納されます。

続く決済フェーズでは、Relying Party（ASPSPや加盟店）がトランザクションデータ（金額や受取人など）を含むプレゼンテーションリクエストをWallet Unitに送ります。Wallet Unitはユーザーにその内容を表示して同意を得た上で、SUAアテステーションをRPに提示すると同時に、そのアテステーションに紐付いた秘密鍵でトランザクションデータに署名します。RPは、SUAアテステーションに含まれる公開鍵を用いてこの署名を検証することで、「このSUAアテステーションの正当な保持者が、この特定の取引内容に同意した」ことを確認できます。この署名がPSD2の求めるDynamic Linking（ユーザーの同意が特定の取引に紐付いていることの保証）の証拠として機能します。

なお、備考として、この決済フローにおいて、ユーザーが買い物をしているUser Agent（PCやスマートフォンのブラウザ、あるいは加盟店のアプリ）とEUDI Walletアプリは別のコンポーネントです。RPからのプレゼンテーションリクエストは、DC APIやカスタムURIスキームを経由してUser AgentからWallet Instanceに渡されます。

2つの利用モデル

Topic AAでは、SUAアテステーションの利用において2つの異なるモデルが明確化されています。

1つ目は2者モデル（issuer-requested flow）です。これは、ユーザーと自身のASPSP（例えば銀行）との間の直接的なやり取りであり、ASPSPがSUAアテステーションの発行者であると同時にRelying Partyでもあるケースです。この場合、3つすべてのSCAユースケース（決済開始、口座アクセス、不正リスクを伴う操作）が許可されます。

2つ目は3者モデル（payee-requested flow）です。これはユーザーと加盟店またはPISP（Payment Initiation Service Provider）との間のやり取りであり、SUAアテステーションの発行者（ASPSP）とRelying Party（加盟店やPISP）が異なるケースです。この場合、決済開始のSCAユースケースのみが許可されます。

このモデルの違いは、Wallet UnitがPresentation Requestを受け取った際に行う検証処理に反映されます。例えば、3者モデルでは「決済開始（Payment Initiation）」のみが許可されます。そのため、Wallet Unitに口座アクセス（Account Access）のためのトランザクションデータを含むPresentation Requestが届いた場合、その要求は3者モデルのSUAアテステーションでは利用できません。このような場合、Wallet Unitは要求を拒否することになります。一方、2者モデルでは「決済開始」「口座アクセス」「不正リスクを伴う操作」のすべてが許可されるため、これらのトランザクションデータを処理できます。

ARFでは、このような判定を行うための要件としてSUA_07が定義されています。SUA_07では、Wallet Unitは「Presentation Requestに含まれるトランザクションデータが、そのSUAアテステーションに対して意図されたものであること」を検証しなければならないとされています。

このように、Discussion Paperで整理された2者と3者モデルの違いは、SUA_07によるトランザクションデータの検証を通じて実現される設計になっていると理解しています。

不正検知シグナルの取り扱い

前述のTopic Tでも触れましたが、PSD2では決済サービスプロバイダーに不正取引の監視が義務付けられており、このTopic AAの議論ではWallet Unitがその監視にどう関わるかが論点となりました。

この詳細はTopic Tに委ねられていますが、結論として、Topic Tで述べた通り、ARFはWallet Unitから決済サービスプロバイダーなどのRelying Partyへ直接不正検知シグナルを提供する仕組みは設けず、Wallet Provider自身がセキュリティポスチャの監視を行うことで、間接的に不正検知を支援するという方針が採られています。

Topic E: 仮名（Pseudonyms）

背景

Topic EのDiscussion Paperでは、仮名に関するeIDAS規則の法的要件が整理されています。eIDAS規則では、EUDI Walletがユーザーの仮名（Pseudonym）を生成・保存できること、そしてRelying Partyが法令上のユーザー識別義務がない場合に仮名の使用を拒否してはならないことが定められています。つまり「本名を明かさずにサービスを使える権利」がユーザーに保障されていると理解しています。

ただし、従来のARFでは仮名に関するHLR（Annex 2 Topic 11）は存在していたものの、どのようなユースケースを想定し、どの技術でカバーできるのかが十分に整理されていませんでした。今回のTopic Eでは、仮名のタイプとユースケースを体系的に整理した上で、ARF本文とHLRの両方に反映が行われました。

仮名の3つのタイプ

Discussion Paperでは、仮名が以下の3つのタイプに分類されました。このタイプの定義はARF本文Section 4.7に反映されています。

Verifiable Pseudonym（検証可能な仮名）

ユーザーが仮名の所有を証明し、その仮名として認証できるもの。代表的な実装としてPasskeysが挙げられています。

Attested Pseudonym（証明付き仮名）

Verifiable Pseudonymのサブタイプであり、Attestation Providerなどの第三者が「この仮名はこのユーザーのものである」と証明したものです。

仕組みとしては、ユーザーが自分で鍵ペアを生成して公開鍵をRPに登録するVerifiable Pseudonymとは異なり、Attestation Providerが仮名を属性として含むアテステーションを(Q)EAAとしてWallet Unitに発行します。

このアテステーションはdevice-boundであるため、ユーザーはVerifiable PresentationとしてRPに提示できます。RPから見ると、Verifiable Pseudonymでは「この秘密鍵を持っている誰か」としか分かりませんが、Attested Pseudonymでは「Trust Framework内の信頼できる第三者が、仮名の裏にいる実際の人物を確認した上で発行している」という信頼が加わると理解できます。

Scope Rate Limited Pseudonym（回数制限つき仮名）

Verifiable Pseudonymのサブタイプであり、特定のスコープ（RPが定める適用範囲、例えば特定の投票や調査）内でユーザーが保持できる仮名の数が制限されるものです。

制限数が1の場合は「Scope Unique Pseudonym」とも呼ばれ、電子投票のような「一人一回」のシナリオに適しています。仕組みとしては、ユーザーが仮名を登録する際に「このスコープ内でまだ上限に達していない」ことを暗号的に証明し、RPがそれを検証するというプロトコルが想定されています。このとき、レートを超過していないという事実を除き、既に登録済みの仮名の数や値はRPに明かされません。

今回のアップデートでは、Topic 11に新しくSection E「HLRs related to scope rate-limited pseudonyms」としてHLRが追加され、使用するアルゴリズムがEUの認定暗号方式に準拠すること、RPがレート超過を検証できること、異なるRP間で仮名を相関付けできないことなど、相互運用性とプライバシーの両立を目指す要件が整備されました。ただし、これらのHLRは今後策定されるプロトコルが満たすべきSHALL要件として定められているものの、そのプロトコル自体はまだ策定されていません。

4つのユースケース

これらのタイプを踏まえ、Discussion Paperでは4つのユースケースが整理されました。各ユースケースの概要はARF本文Section 2.5に反映されています。

ユースケースA: 仮名による認証は、ユーザーが仮名でアカウントを作成し、以後その仮名でログインするという基本的なシナリオです。Verifiable Pseudonymで実現可能であり、ARF本文2.5.6でもサポート必須とされています。

ユースケースB: 属性登録を伴う仮名認証は、ユースケースAに加え、仮名登録と組み合わせて「18歳以上」などの検証可能な属性もRPに提示するシナリオです。仮名の登録と属性の提示それぞれは可能ですが、両者が同一ユーザーに帰属することを暗号的に保証する仕組み（Cryptographic Binding）がないと、例えば18歳未満のユーザーが仮名を登録し、別の18歳以上のユーザーが属性を提示するという共謀によって年齢制限を回避できてしまいます。この共通メカニズムの技術仕様がまだ策定されておらず、今後の課題と理解しています。

ユースケースC: 参加回数の制限は、ユーザーが特定のスコープ内で登録できる仮名の数を制限するシナリオです。オンライン投票やスパムアカウント防止が典型例です。Scope Rate Limited Pseudonymが必要であり、今回のアップデートでHLRが追加されました。ただし具体的なプロトコルの技術仕様は今後の策定が必要です。

ユースケースD: 複数サービス間でのリンク可能な仮名認証は、同一の仮名を複数のRPにまたがって使用するシナリオです。例えば、ECサイトで注文時に登録した仮名を配送業者への当人認証にも使うケースです（ECサイトで注文した人と同一人物であることを仮名で確認するというシナリオです）。Attested Pseudonymとして発行する形でサポート可能ですが、共通仕様は未策定です。また、クロスパーティのリンク可能性はプライバシーリスクを伴うため、ユーザーの明示的な選択がある場合にのみ使用されるべきとされています。

ユースケース・仮名タイプ・WebAuthnサポートの対応関係

ここで、上記までの内容をもとに、各ユースケースに必要な仮名タイプとWebAuthnでのサポート状況を自分なりに整理してみます。

ユースケース必要な仮名タイプWebAuthnでのサポート
A: 仮名による認証Verifiable Pseudonymサポートしている
B: 属性登録を伴う仮名認証Verifiable Pseudonym + Cryptographic Binding部分的にサポートしている。仮名単体は可能だが、属性との同一ユーザー紐付けは実現できない
C: 参加回数の制限Scope Rate Limited Pseudonymサポートしていない。WebAuthnにレート制限の仕組みがない
D: 複数サービス間でのリンク可能な仮名認証Attested Pseudonymサポートしていない。WebAuthnの仕様上、同一のPasskeyを複数RPで使用できない

この表から分かる通り、WebAuthnでカバーできるのは実質的にユースケースAのみです。従来のARFでは、Wallet UnitがWebAuthn Authenticatorとして実装することが必須（SHALL）とされていましたが、Discussion Paperでは、WebAuthnだけではすべてのユースケースをカバーできないことが課題として指摘されており、特にユースケースBとCが挙げられています。

これを受けて、今回のアップデートではAnnex 2 Topic 11のPA_22において、WebAuthnの実装が必須（SHALL）からオプション（MAY）に変更されました。

おわりに

次回はv2.9のアップデート内容として、これまでも記事(EUDIW ARF v2におけるWallet Unit Attestationの整理)にしてきたWallet Unit Attestation周り（Discussion Topic CおよびTechnical Specification 3）を追っていきたいと思います。

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