Credential FormatsSD-JWT VC (dc+sd-jwt), W3C VC as JWT (jwt_vc_json), ISO/IEC 18013-5 mdoc (mso_mdoc), and ISO/IEC 23220. | ✓ | ✓ |
W3C VC JSON-LDLinked-data credentials using ldp_vc. Current Issuer2, Verifier2, and Wallet2 stacks reject this format. | - | - |
ProtocolsOID4VCI 1.0 and OID4VP 1.0, plus ISO-18013-7 for mDL / mdoc remote flows. Deprecated v1 services still cover OID4VCI drafts 11/13 and OID4VP drafts 14/20. | ✓ | ✓ |
Status Credential FormatsTokenStatusList (incl. draft 8), Bitstring Status List v1.0, StatusList2021, RevocationList2020 | ✓ | ✓ |
Digital Credentials APIUnified browser API for credential issuance/verification; abstracts OID4VCI/VP & ISO-18013-7 for 1-click web integrations. | ~Supported in: Verifier | ~Supported in: Verifier |
Same-device remote flowUser stays on one device for issuance or presentation, typically via redirect or in-app handover. | ✓ | ✓ |
Cross-device remote flowQR code or companion-device handover for issuance and remote presentation. | ✓ | ✓ |
Proximity presentationIn-person credential share over BLE or NFC, including ISO/IEC 18013-5 proximity flows. | ~Supported in: Wallet | ~Supported in: Wallet |
Selective disclosureOnly requested claims leave the wallet, using SD-JWT disclosures or mdoc namespaces. | ✓ | ✓ |
Signed request object (JAR)Wallet authenticates the verifier from a signed request object before showing consent. | ✓ | ✓ |
Request by referenceWallet fetches the presentation request from request_uri over HTTPS, including GET and POST retrieval. | ✓ | ✓ |
X.509 verifier identityVerifier identity from certificate-bound client identifiers, including x509_hash and x509_san_dns. | ✓ | ✓ |
Posted / encrypted presentation responsesAuthorization responses posted to response_uri as direct_post or encrypted direct_post.jwt. | ✓ | ✓ |
Pushed Authorization RequestsAuthorization parameters stay off the front channel via PAR during issuance. | ✓ | ✓ |
PKCE (S256)Public wallet clients bind the authorization code with S256 so it cannot be replayed. | ~Supported in: Wallet | ~Supported in: Wallet |
DPoPAccess tokens are bound to the wallet key during issuance. | ✓ | ✓ |
Wallet / client attestationIssuer can accept only attested wallet software; wallets can send attestation headers. | ✓ | ✓ |
Key attestationIssuer can require hardware-backed or attested holder keys on the credential proof. | R | R |
Signed and unsigned issuer metadataWallets consume unsigned HTTPS issuer metadata and can verify signed JWT issuer metadata. | ✓ | ✓ |
Encrypted credential requestWallet encrypts the credential request so the issuer receives it as JWE. | ~Supported in: Issuer | ~Supported in: Issuer |
Encrypted credential responseIssuer encrypts the issued credential; the wallet must request and decrypt the JWE. | ~Supported in: Issuer | ~Supported in: Issuer |
OID4VCI notification endpointWallet reports accepted, failed, or deleted credentials to the issuer notification endpoint. | R | R |
Present-to-obtainHolder presents an existing credential before a new one is issued. | - | - |
Nonce endpointFresh c_nonce for proofs during OpenID4VCI issuance. | ✓ | ✓ |
