Skip to main content

Frequently asked questions

Short, spec-grounded answers about Wallet Unit Attestation. For the underlying sources, see References; to see any of this live, open the playground.

Basics​

What is a Wallet Unit Attestation (WUA)?​

The Wallet Provider's attestation that a wallet instance is genuine and in good standing, and that the keys it will bind a credential to are held in secure hardware. Following EU ARF 2.9.0 (Topic C), a WUA is made of two parts: a Wallet Instance Attestation (WIA) and a Key Attestation (KA). In short, WUA = WIA + KA.

What is the difference between a WIA and a Key Attestation?​

The WIA (oauth-client-attestation+jwt) attests the wallet instance itself. The Key Attestation (key-attestation+jwt) attests the keys held in the WSCD. They answer different questions: "is this a genuine wallet?" and "are these keys in secure hardware?".

What is a WSCD?​

A Wallet Secure Cryptographic Device: the secure element or keystore that holds the wallet's private keys. The KA states its attack resistance as key_storage and user_authentication on the ISO/IEC 18045 AVA_VAN scale (for example iso_18045_high).

Is the WUA shown to the website or shop where I present a credential?​

No. The WUA is used only when a credential is issued, between the wallet and the Issuer. The Verifier you later present a credential to never sees it; they check only the credential itself. Keeping the WUA out of presentation means it cannot become an identifier that follows you between services.

How does a WUA differ from Android Key Attestation or Apple App Attestation?​

Those vendor mechanisms attest a key created on a specific platform, signed against that platform's root rather than a European trust list, so each is platform-specific. The WUA is the layer that turns such a platform fact into a European trust statement: a Wallet Provider certified under eIDAS and listed on an EU trust list vouches for the wallet in terms any Issuer can verify. See Why a WUA?.

Proof and issuance​

How does the Key Attestation reach the Issuer?​

Inside the proof JWT's key_attestation header: the proof of possession carries the KA, so the two travel together. (A standalone attestation proof type also exists, without proof of possession.)

What is proof of possession, and why is it needed?​

An openid4vci-proof+jwt signed by the attested private key. It proves the wallet controls the key the credential will be bound to. Its aud ties it to the Credential Issuer and its nonce (the Issuer's c_nonce) prevents replay.

What is batch_size, and how does batch issuance work?​

One KA can attest many keys (N). The Issuer binds min(N, batch_size) of them, minting one credential per bound key, so the wallet can present a fresh key per transaction for better unlinkability. batch_size comes from ETSI TS 119 472-3 (credential_reuse_policy.options.batch_size). See Batch issuance.

Why are some attested keys "wasted"?​

The KA is single-use, so any attested keys beyond batch_size are not bound and cannot be reused later. Drag the sliders on the playground to watch this happen.

Lifecycle and validity​

How long is a WUA valid, and what is the 24-hour rule?​

The WIA is short-lived: TS3 requires its time-to-live to be under 24 hours (§2.2.1.1), so the wallet obtains a fresh WIA frequently. Separately, a PID Provider must re-check the revocation status of both the WIA and the KA at least once every 24 hours for the credential's validity period (§2.4.3, §2.3.1). The Key Attestation is single-use, so a new, previously unused KA is sent on each re-issuance (§2.4.2).

What happens when I update my phone's operating system, or update or reinstall the Wallet App?​

TS3 does not define triggers specific to an operating-system update or a Wallet App update or reinstall. What it does specify, and what governs change in practice: the WIA's sub-24-hour time-to-live means a fresh WIA is obtained frequently (§2.2.1.1); each re-issuance requires a new, unused KA (§2.4.2); a KA must be revoked if a security vulnerability affecting the WSCD or keystore is identified (§2.5.2); and a Wallet Provider revokes all of a Wallet Unit's client_status.status entries when the unit is revoked (§2.4.2). So whether an update forces re-attestation depends on whether it changes the instance identity or the WSCD keys, which is implementation-specific, not an explicit "on update" rule in TS3.

Why does the WIA expire within a day, but the Key Attestation does not?​

They answer different questions. The WIA says "this wallet app is genuine and healthy right now", which can change quickly, so it is kept short-lived and checked fresh (§2.2.1.1). The KA says "the keys are in this kind of certified secure hardware", a fixed fact that does not change day to day, so it needs no daily refresh; if that hardware type is later found weak, that is handled by revocation (§2.5.2), not by a short expiry.

How can a credential stay trusted for months if the WIA lasts under 24 hours?​

There are two separate clocks. One is the attestation's own lifetime. The other is the Wallet Provider's promise to keep publishing whether the wallet or its keys have been revoked: whenever the wallet presents its attestation, that promise must still have at least a month left (§2.4.3; in TS3, key_storage_status.exp is at least 31 days ahead). That gives the Issuer a guaranteed window to keep checking, and a credential cannot outlast the promise it relies on.

What happens if I do not use my wallet for a while, or my phone is offline?​

Nothing breaks. The wallet simply stops fetching fresh attestations; the next time it is used, it obtains new ones. Credentials already held stay checkable, because the Wallet Provider keeps their status available.

Does the daily refresh create extra work for me?​

No. It happens automatically in the background between the wallet and its provider. You do not see it and do not have to do anything.

What if my wallet is lost, stolen, or found to have a flaw?​

The Wallet Provider can revoke it (§2.4.2, §2.5.2). Because Issuers re-check status at least once a day, everyone relying on credentials from that wallet finds out and can stop trusting them.

OpenID4VCI v1.0 vs TS3 v1.5​

How do OpenID4VCI v1.0 and TS3 v1.5 differ?​

With a Key Attestation, both send a single proof and produce the batch from attested_keys, so it is not "N proofs vs one proof". TS3 v1.5 profiles OpenID4VCI: the proof MUST be signed by attested_keys[0] (OpenID4VCI allows any attested key, identified by kid), kid and iss are removed, x5c MUST chain to the Wallet Provider Trusted List, iso_18045_high is required for a WSCD, certification is mandatory, the KA is typed keyattestation+jwt, and key_storage_status is added. OpenID4VCI's N-element proofs array (one proof per key) is its batch path without a Key Attestation. The full table is on OpenID4VCI vs TS3.

Why are there two KA media types (key-attestation+jwt vs keyattestation+jwt)?​

OpenID4VCI registers the hyphenated key-attestation+jwt; TS3 v1.5 types the same structure as keyattestation+jwt (no hyphen). A verifier that matches typ exactly will reject the other form, so this is a real interoperability divergence to track.

How does an Issuer verify the KA and the proof?​

It verifies the KA signature and that x5c chains to the Wallet Provider Trusted List, matches the proof's signing key against attested_keys, verifies the proof of possession, checks nonce / aud / iat, checks the key-security level and revocation status, then binds and issues. Step through both paths on How the Issuer verifies.

About this playground​

Are the tokens and certificates real?​

The tokens are really signed in your browser with ES256, so they decode and verify against the embedded keys. The certificates are self-signed samples (subject O=iGrant.io) and are not trust anchors. Everything here is illustrative, not normative.

Which credentials and specifications does it use?​

The sample credentials are PID and Photo ID in SD-JWT-VC form. The content is grounded in OpenID4VCI v1.0, TS3 v1.5, EU ARF 2.9.0 (and Topic C), and ETSI TS 119 472-3, all linked on References.