EUDIW ARF v2におけるWallet Unit Attestationの整理

Decentralized Identity

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

本稿は、以下の記事において、分量が多くなるため別途公開するとしていたWallet Unit Attestationについて整理したものです。

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

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

目次

1. インプットした文書

1.1 その他の文書

  • ARF Discussion Topic C – Wallet Unit Attestation (WUA) and Key Attestation
    • この議論は 2025年4月で終了し、結果は Annex2 に統合済みのため、本稿では対象外とします。
  • ARF Technical Specification – TS3: Specification of Wallet Unit Attestations (WUA) used in issuance of PID and Attestations
    • Technical SpecificationはHLR (High Level Requirements)に準拠しつつ、エコシステムの相互運用性を確保することを目的としています。HLR だけでは不足する詳細な技術仕様を補完し、HLR を具体的に実現するための技術文書という理解です。
    • 現時点のTS3はWUAの「発行」のみをスコープとしており、「提示」については将来的な対象とされています。
    • まだドラフト段階にあり、HLR内にもNOTE: Technical Specification 3 is not finalised yet. Discussions on the WUA are ongoing.と記載があります。そのため、本記事ではTS3の内容は扱わず、ARF本体とHLRのみにフォーカスして整理します。

2. v1.4との一番の違い: WTEとWIAの統合

まず大きなポイントとして挙げられるのは、v1.4ではWalletの信頼性を担保するAttestationとしてWallet Trusted Evidence(WTE)とWallet Instance Attestation(WIA)の2つが存在していたことです。いずれもWallet ProviderからWallet Instance(アプリ)に発行されるものですが、それぞれ目的が異なります。

端的に述べれば、前者のWTEはWalletからPID/Attestation Provider(Issuer)にのみ提示され、そのWalletが信頼できるWallet Providerにより提供されていること、Issuerが要求する機能を備えていること(例えばProximity PresentationにおいてNFCをサポートしているかどうか)、さらに秘密鍵を管理するWSCA/WSCDが必要なセキュリティレベルを満たしていることを確認するためのものです。

一方、後者のWIAは、ユーザー(Holder)ごとのWallet Instance(アプリ)が直近で有効であることを、PID/Attestation ProviderやRelying Party(Verifier)に示すためのものです。

ここで「有効であること」について補足します。たとえば自分のスマートフォンを紛失し、Wallet Instanceを失効させるケースを考えてみましょう。スマートフォンを紛失した場合、第三者に悪用されないようWallet Providerに連絡し、自分のWallet Instanceを失効してもらいます。そうすると、そのInstanceにはWIAが発行されなくなり、結果的に悪用者による新たな発行や提示のプロセス進行を防ぐことができます。

v1.4(2024/5リリース)の時点では、このようにWTEとWIAが別々のAttestationとして存在していました。しかし、ARFのGitHub Issue: C – Wallet Unit Attestation (WUA) and key attestationを読む限り、v1.5(2025/2リリース)からは両者が概念的に統合され、Wallet Unit Attestation(WUA)として整理されたと理解しています。

Wallet Unitとは、4.3.2 Components of a Wallet Unitに記載されているとおり、簡潔に言えば「デバイス + Instance(アプリ) + WSCA/WSCD + Wallet Provider Backend」を指します。したがって、「Wallet Unit Attestation」という名前は、WIA(Instance部分)とWTE(WSCA/WSCD部分)の統合を体現していると言えるでしょう。

ここから先は、「WUA = WTE + WIA」という前提に立ち、以下の6つの観点ごとに整理を進めていきたいと思います。

  1. 提示先
  2. 発行タイミング
  3. 失効状態の確認手法
  4. Proof of Association
  5. Linkability

3. 整理

3.1 提示先

まず、6.6 Trust throughout a PID or an attestation lifecycleにおいて、VC(PID/Attestation)のライフサイクルが説明されています。VC発行時にWUAをIssuer(PID/Attestation Provider)へ提示するのは自明です。

次に、Relying Party(RP)への提示についてです。WUAがWTEとWIAの統合であると考えると、WIAの性質からRPにも提示されるのではと推測しました。しかし、ARFには以下のように明記されており、WUAはRPには提示しない設計になっています。その理由は「ビジネス上の合理性がなく、ユーザープライバシーを保護するため」とされています。これは、WUAがRP間の結託によるCorrelationのポイントになってしまう可能性があるためだと理解できます。

It describes the capabilities and properties of the Wallet Unit, including a WSCD. This allows a PID Provider or an Attestation Provider to verify that the Wallet Unit complies with the Provider’s requirements and therefore is fit to receive a PID or an attestation from the Provider. To ensure User privacy, the Wallet Unit presents the WUA only to PID Providers and Attestation Providers, but not to Relying Parties. This is because PID Providers and Attestation Providers have a valid business reason to know these properties, whereas Relying Parties do not.

引用元: 6.5.3.4 Wallet Provider issues one or more Wallet Unit Attestations to the Wallet Unit

さらにRPにWUAを提示しないもう1つの理由として、有効なWUAがWallet Unitに存在しない場合、そのWallet Unitは「Valid」ではなく、RPに対してVC(PID/Attestation)を提示できない状態になることが挙げられると理解しています。これは対偶を取れば、RPにVCを提示できる状態であるということは、そのWallet Unitに有効なWUAが存在するということを意味します。

HLRにも同様の趣旨が述べられています。

This implies that if a Relying Party verifies that a PID it obtained from a Wallet Unit is valid (i.e., not revoked), it can trust that the Wallet Unit is also valid. Consequently, there is no need for a separate mechanism that would allow the Relying Party to verify the revocation status of a Wallet Unit directly with the Wallet Provider. Although the CIR requires this mechanism only for PIDs, other Attestation Providers may similarly revoke an attestation if the Wallet Unit on which it resides is revoked. Note that if an Attestation Provider does not support this, a Relying Party obtaining an attestation from a Wallet Unit has no way of knowing whether the Wallet Unit is revoked. Depending on the value of the attestation, this risk may be acceptable for the Relying Party.

引用元: Annex2 HLR: A.2.3.38 Topic 38 – Wallet Unit revocation

3.2 発行タイミング

During the activation of a Wallet Unit, the Wallet Provider issues one or more Wallet Unit Attestations to the Wallet Unit.

引用元: 6.5.3.4 Wallet Provider issues one or more Wallet Unit Attestations to the Wallet Unit

この記述から、ユーザーがWallet UnitのUIを通じてActivationを行う際に、1つ以上のWUAが発行されることが分かります。Activationとは、下記ライフサイクル図においてWallet Unitの状態が「Installed」から「Operational」へと遷移するトリガーとなるアクションです。

では、どのようなときに「Installed」状態へ遷移し、WUA発行準備が整うのかを図から読み解くと、以下の3つの場合が考えられます。

  1. ユーザーがデバイスにWallet Unit(app)をインストールしたとき
  2. Wallet ProviderがWUAを失効したとき
  3. WUAの有効期限が切れたとき

参照元: 4.6.3 Wallet Unit - Figure 7: State diagram of Wallet Unit
参照元: 4.6.3 Wallet Unit – Figure 7: State diagram of Wallet Unit

No.2と3について不明瞭なのは、「全てのWUAが失効または期限切れ」になった場合に「Installed」に戻るのか、それとも「1つでも失効または期限切れ」になった時点で戻るのか、という点です。

これについて、以下の記述から、Wallet Unitが「Valid」状態であるためには少なくとも1つの有効なWUAを保持している必要があることが分かります。したがって「全てのWUAが失効または期限切れ」になったときに「Installed」へ戻り、新しいWUAが再発行されると解釈できます。

The Wallet Provider ensures that a valid Wallet Unit is in possession of at least one Wallet Unit Attestation (WUA), to enable other entities to authenticate the Wallet Unit. The Wallet Provider can revoke the WUAs if needed.

引用元: 6.1 Scope

また、図には明記されていませんが、「Valid」状態であってもWUAの発行は行われると理解しています。以下はWUAのLinkabilityに関する記述です。VC(PID/Attestation)と同様、WUAについてもCorrelationリスクへの配慮が必要とされています（WUAはRPには提示されないため、Issuer間の結託によるCorrelationが想定される）。

The responsibilities of the Wallet Provider regarding issuance of a WUA are similar to those of a PID Provider or Attestation Provider regarding the issuance of a PID or an attestation. This means that after the initial issuance of a WUA during activation, the Wallet Provider will manage the WUA and will issue new WUAs to the Wallet Unit as needed, during the lifetime of the Wallet Unit. In particular, the Wallet Provider will ensure that the risk of malicious Attestation Providers linking multiple presentations of the same WUA, with the goal of tracking the User, is minimised. For example, the Wallet Provider may set up the Wallet Unit in such a way that each Wallet Unit Attestation is presented to at most one PID Provider or Attestation Provider. Such a WUA is called a ‘once-only’ attestation, see Section 7.4.3.5.

引用元: 6.5.3.4 Wallet Provider issues one or more Wallet Unit Attestations to the Wallet Unit

HLRでも同様に、VCだけでなくWUAに関してもCorrelationを防ぐためのOnce-OnlyやLimited-TimeといったAttestation方式のサポートが必須とされています。

A Wallet Provider SHALL ensure that its Wallet Solution supports the following methods for limiting the number of times a User can present the same PID or attestation to Relying Parties: Method A (Once-only attestations, as specified in requirement ISSU_43 – ISSU_47) and Method B (Limited-time attestations, as specified in requirement ISSU_48 – ISSU_50). In addition, a Wallet Provider MAY ensure that its Wallet Solution supports Method C (Rotating-batch attestations, as specified in requirement ISSU_51 – ISSU_54) or Method D (Per-Relying Party attestations, as specified in requirement ISSU_55 – ISSU_57). Note: Wallet Solutions, PID Providers, Attestation Providers, and Wallet Providers are free to define and use other methods as well. However, such other methods are out of scope of the ARF.

引用元: Annex2 HLR: D – HLRs for Privacy Risks and Mitigation: ISSU_37

さらに、Once-Only Attestationに関しては、Wallet Unitが保持するWUA数に下限を設定し、その下限を下回らないよう新しいWUAの発行をWallet Providerに要求しなければならないと規定されています。したがって、「Valid」状態であってもWUA発行は継続的に行われると理解できます。

The Wallet Unit SHALL request the PID Provider, Attestation Provider, or Wallet Provider to issue PIDs, attestations, or WUAs in batches to the Wallet Unit. All PIDs, attestations, or WUAs in a batch SHALL have the same attribute values and the same technical validity period.

引用元: Annex 2 HLR: Method A: Once-only attestations: ISSU_43

The Wallet Unit SHALL have a lower limit for the number of unused PIDs, attestations, or WUAs it holds, and SHALL request the issuance of a new batch when this limit is reached. During the first issuance of a new PID, attestation, or WUA, see requirement ISSU_39, the PID Provider, Attestation Provider or Wallet Provider SHALL inform the Wallet Unit about the value of the lower limit and the size of the batch to be requested.

引用元: Annex2 HLR: Method A: Once-only attestations: ISSU_45

3.3 失効状態の確認

以下のとおり、WUAにはIssuerが失効状態を検証できる情報を含める必要があると記載されています。具体的な仕組みについてはドラフト中のTechnical Specification 3に定義される予定とされており、おそらくStatus Listのような仕組みが想定されていると考えています。ここは今後のTechnical Specification 3の確定を待ちたいと思います。

Lastly, a WUA contains information allowing a PID Provider or an Attestation Provider to verify that the Wallet Provider did not revoke the Wallet Unit Attestation, and hence the Wallet Unit itself. The WUA and the revocation mechanisms for Wallet Units are described in Topic 38.

引用元: 6.5.3.4 Wallet Provider issues one or more Wallet Unit Attestations to the Wallet Unit

A PID Provider issuing revocable PIDs SHALL, for each of its valid PIDs, regularly verify whether the Wallet Provider revoked the Wallet Unit on which that PID is residing, using the revocation information in the WUA it received during issuance of that PID. If it turns out that the Wallet Unit is revoked, the PID Provider SHALL immediately revoke the respective PID in accordance with all requirements in [Topic 7]. Notes: – This is a consequence of the legal requirement in [CIR 2024/2977], Article 5, 4.(b). – See Technical Specification 3 for how the PID Provider can do this verification.

引用元: Annex2: A.2.3.38 Topic 38 – Wallet Unit revocation: WURevocation_18

3.4 Proof of Association (Proof of Cryptographic Binding)

ここでのProof of Associationとは、前回の記事でも述べたとおり、VC(PID/Attestation)のSubjectとなる公開鍵に対応する秘密鍵が、WUAに署名する秘密鍵と同じWSCDで保護されていることを証明する仕組みです。v1.4ではWhitepaperの公開が予定されていましたが、v2.4時点ではその文言は削除されています。また、名称もProof of AssociationからProof of Cryptographic Bindingへと変更されています。

A Cryptographic Binding of Attestations scheme SHALL enable a PID Provider or Attestation Provider, during the issuance of a PID or attestation, to request and obtain proof that the private key for the new PID or attestation is managed by the same WSCA/WSCD as the private key of the WUA received.

引用元: Annex 2 HLR: A.2.3.18 Topic 18 – Combined presentations of attributes: ACP_06

また、現行のARFでは仕組みがまだ未定義であり、現時点のWSCDで広くサポートされているわけでもないため、Proof of Cryptographic Bindingは必須ではないと明記されています。

Optionally, a fourth purpose of the WUA is the following. During the issuance of a PID or an attestation, the Wallet Unit will send a public key to the PID Provider or Attestation Provider. The Provider will include this public key in the issued PID or attestation. The WSCA/WSCD may be able to prove to the PID Provider or Attestation Provider that it manages both the private key belonging to this new public key and the private key belonging to the WUA public key. In that way, the PID Provider or Attestation Provider can trust that the level of security of this new key is the same as for the WUA key. Note that support for such a ‘proof of cryptographic binding’ between a WUA and a PID or attestation is not mandatory in this version of the ARF, since no such mechanism has been specified yet, let alone that this is widely supported by available WSCA/WSCDs. For more information, please refer to Topic 18.

引用元: 6.5.3.3 Wallet Provider requests User to set up at least one User authentication mechanism

This version of the ARF does not specify or reference a specific cryptographic mechanism to implement cryptographic binding of attestations.

引用元: 6.6.3.10.2 Cryptographic binding of attestations

3.5 Linkability

このトピックについては、上記「3.2 発行タイミング」の内容をご参照ください。

4. 最後に

今回はARF本体とHLRを基に、WUAの包括的な全体像を整理しました。フォーマットやデータモデルといったより細かな仕様については、前述のTechnical Specification 3を参照する必要があります。まだドラフト段階ということで、今後の確定を待ちアップデートを追いかけていきたいと思います。

5. 補足: WalletとWallet Providerによる相互認証

Wallet Unitの初期起動において、Wallet ProviderからWUAを発行してもらう前段階で実施する相互認証の仕組みについてです。これは前編で「深掘りしたい」と触れていた点ですが、v1.4から引き続きARFの範囲外とされています（6.5.3 Wallet Unit activation参照）。

ここでは、Wallet ProviderによるWallet Instanceの認証について述べます。

ARFで範囲外とされていることからも分かるように、この部分はAndroidやiOSのアプリ固有の領域であり、仕組みはGoogleやAppleに依存していると考えられます。

  • Android: Googleが公式に提供する「アプリ信頼性検証API」であるPlay Integrity APIが存在します。これはAndroid SDKの一部であり、アプリは自身のIntegrityを証明するトークン(Nested JWT = JWS in JWE)をAPIから発行してもらい、それをProvider Backendに送信して検証してもらう流れです。トークンにはアプリのパッケージ名やバージョン、Play Storeからインストールされたかどうかなどの情報が含まれます（詳細はPlay Integrity: 完全性判定の結果を参照ください）。

  • iOS: Appleが提供するApp Attestがあり、これはPlay Integrity APIに相当する仕組みだと理解してます。

また、OID4VCIでもこの点に触れられています。

In a typical architecture of a native Wallet App, the Wallet Provider’s backend will use attestations provided by the mobile operating system, like iOS’s DeviceCheck or Android’s Play Integrity, to validate the app’s integrity and authenticity before issuing the Wallet Attestation.

引用元: OID4VCI(draft 17): Appendix E. Wallet Attestations in JWT format

これらのAPIを利用することで、Wallet InstanceからWallet Providerへの認証が行われると理解しています。