Wallet Attestation: The Missing Trust Layer in Credential Issuance

A credential issuer must decide both whether someone is entitled to receive a credential and what it can establish about the wallet and key that will protect it after issuance. The first is authorization. The second is the job of wallet attestation.

Attestation describes the wallet and its keys at issuance. Holder binding proves control of a credential-bound key at presentation.

Why an issuer needs more than a credential request

OID4VCI gives a wallet a standard way to obtain a credential. The wallet discovers issuer capabilities, obtains authorization where needed, and makes a credential request with cryptographic proof. In high-assurance cases, an issuer may also need evidence that the wallet application is authentic, that the credential key meets its protection policy, and that later security events can be acted upon.

Two attestations, two questions

In EUDI terminology, Wallet Unit Attestation is the umbrella term for Wallet Instance Attestation (WIA) and Key Attestation (KA). WIA asks whether this is an authentic, integrity-checked wallet application. KA asks what security properties apply to the key material and its storage. A genuine wallet app does not automatically establish how a particular credential key is protected, and a key statement does not establish the integrity state of the requesting app.

Wallet Instance Attestation: evidence about the app

A WIA is a signed JWT from a Wallet Provider. Before issuing it, the provider checks wallet integrity and creates a portable wallet-attestation statement. In an OID4VCI flow, the WIA is used for client authentication in the pushed authorization request and token request, accompanied by a proof of possession. It is not merely a bearer label: the wallet must prove control of the associated key.

Key Attestation: evidence about the credential key

A KA is also a signed JWT from the Wallet Provider, but it describes the public key or keys that an issuer may bind to a credential, plus assertions about key storage and user-authentication properties. It appears in the credential-request proof material. The issuer checks that the request proof is connected to an attested key and evaluates whether the stated properties meet policy. For an EUDI PID, the source material describes iso_18045_high storage as a strict example.

Attestation is a policy input, not authorization

A successful attestation check is not permission to issue. Authorization determines eligibility; attestation informs whether the issuer is willing to place a credential in the presented wallet and bind it to the supplied key. A sound design separately evaluates eligibility, wallet authenticity, key protection, proof binding, and the credential lifecycle.

Privacy: avoid turning assurance into tracking

A stable per-instance wallet identifier could become a cross-service tracking handle. The OID4VCI wallet-attestation model therefore uses a subject that identifies a wallet type rather than a unique wallet installation. Attestation reuse choices can also affect linkability. Those choices should be part of an explicit privacy review, not an unnoticed implementation default.

Lifecycle and revocation are security properties

Attestation evidence is time-sensitive. The EUDI material describes a short technical lifetime for WIA and a more flexible one for KA. Both can reference status information so that a Wallet Provider can signal a later compromise. Key-attestation status can be shared by a storage type, useful for a class-wide vulnerability, or scoped per attestation, useful for a particular key or instance. The right choice follows the failure model, operational needs, and privacy policy.

Issuance-time assurance is not presentation-time proof

A verifier normally does not evaluate the same wallet attestation for every presentation. It validates the issuer-signed credential and a fresh holder-binding proof. For SD-JWT credentials, a Key Binding JWT can bind the response to the verifier nonce and client identifier. At issuance, attestation helps the issuer assess the wallet and key environment; at presentation, holder binding establishes a live, request-specific proof of key control. A verifier can request a Wallet Instance Attestation as an additional credential in a higher-assurance scenario, but that is not the baseline for every presentation.

What builders should take away

Wallet attestation is a narrow assurance layer around issuance. Use it where the credential requires evidence about the wallet application and the key environment, while keeping authorization, proof validation, privacy, revocation, and later holder binding distinct. Review which credential types need it, which properties are actual policy requirements, whether proof of possession is validated, how linkability is limited, and how status events are handled over the credential lifetime.