OpenID4VCI v1.0 vs TS3 v1.5
TS3 v1.5 is the EUDI profile of how OpenID4VCI v1.0 carries a Key Attestation and a proof of possession. They agree on the big picture (the proof carries the KA in its key_attestation header) but diverge on the details. The table below is the rule-by-rule view.
| Aspect | OpenID4VCI v1.0 | TS3 v1.5 |
|---|---|---|
| How the KA reaches the Issuer | Inside the JWT proof's key_attestation header: the PoP proof carries the KA. (A standalone attestation proof type also exists, without PoP.) | |
| KA media type (`typ`) | key-attestation+jwt (hyphenated; registered in Appendix G). | keyattestation+jwt (no hyphen). A known divergence from OpenID4VCI. |
| Which key signs the proof | Any attested key; identified by the proof header (kid / jwk). No fixed position. | MUST be attested_keys index 0; the kid requirement was removed (v1.5 changelog). |
| Issuer identity on the KA | iss present (the Wallet Provider). | iss removed; identity is taken from the x5c signing certificate. |
| Multiple keys / batch | A single JWT proof carries the KA; the Issuer SHOULD issue one credential per key in attested_keys (Appendix F.1, §14.6). The N-element proofs array is the batch path without a key attestation. | A single proof signed by attested_keys[0]; the batch likewise comes from attested_keys. |
| Per-key proof of possession | One PoP: the proof PoPs one attested key; the remaining keys are bound on the KA. (Per-key PoPs, N proofs, are the no-attestation path.) | One PoP (key 0); the KA attests the remaining keys (no per-key PoP). |
| Key security level | key_storage / user_authentication on the ISO 18045 AVA_VAN scale, matched against key_attestations_required. | iso_18045_high required for a WSCD (e.g. for PID). |
| Certification | certification is an OPTIONAL URL. | Mandatory; a URL to the WSCD certification (e.g. a GlobalPlatform certificate page). |
| Revocation / maintenance | Optional status reference (Token Status List). | Adds key_storage_status (status + an exp maintenance commitment, at least 31 days ahead). |
| How many credentials | Copies of the same credential type, one per bound key, capped by the Issuer batch_size (ETSI TS 119 472-3 credential_reuse_policy.options.batch_size). Unused attested keys are wasted because the KA is single-use. | |
See it in the payloads
The Playground puts the two side by side. Set the number of keys and the batch_size, then click a proof in each column to compare the headers (OpenID4VCI carries a kid; TS3 does not). Click a Credential Request to see that, with a Key Attestation, each carries a single proof and the batch comes from attested_keys. Open the KA and tick "Show the TS3 profile" to diff the two key attestations directly.
The one to watch
The KA media type differs by a single hyphen: OpenID4VCI registers key-attestation+jwt, while TS3 v1.5 types it keyattestation+jwt. A verifier that matches typ exactly will reject the other form, so this is a real interoperability snag, not a cosmetic one.
Generated and signed client-side for teaching. Validate any detail against the linked specifications on the References page.