Credential Formats
SD-JWT VC (dc+sd-jwt), W3C VC as JWT (jwt_vc_json), ISO/IEC 18013-5 mdoc (mso_mdoc), and ISO/IEC 23220.
Overview
Unlike the Community Stack, the Enterprise Stack isn't split into three separate products (Issuer, Verifier, Wallet). It's a single, unified stack that can power different digital identity use cases. One of those is running one or many digital wallets via its multi-tenant model.
Below is the full list of Enterprise Stack capabilities that are relevant for building digital wallet solutions.
Wallet Capabilites
Protocols
OID4VCI 1.0 and OID4VP 1.0 with pre-authorized and authorization-code flows; ISO-18013-7 for mDL / mdoc remote flows. Deprecated Wallet v1 still covers earlier drafts.
Status Credential Formats
TokenStatusList (incl. draft 8), Bitstring Status List v1.0, StatusList2021, RevocationList2020
Digital Credentials API
Unified browser API for credential issuance/verification; abstracts OID4VCI/VP & ISO-18013-7 for 1-click web integrations.
Same-device remote flow
User stays on one device for issuance or presentation, typically via redirect or in-app handover.
Cross-device remote flow
QR code or companion-device handover for issuance and remote presentation.
Proximity presentation
In-person credential share over BLE or NFC, including ISO/IEC 18013-5 proximity flows.
Selective disclosure
Only 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 reference
Wallet fetches the presentation request from request_uri over HTTPS, including GET and POST retrieval.
X.509 verifier identity
Verifier identity from certificate-bound client identifiers, including x509_hash and x509_san_dns.
Posted / encrypted presentation responses
Authorization responses posted to response_uri as direct_post or encrypted direct_post.jwt.
Pushed Authorization Requests
Authorization 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.
DPoP
Access tokens are bound to the wallet key during issuance.
Wallet / client attestation
Issuer can accept only attested wallet software; wallets can send attestation headers.
Key attestation
On roadmapIssuer can require hardware-backed or attested holder keys on the credential proof.
Signed and unsigned issuer metadata
Wallets consume unsigned HTTPS issuer metadata and can verify signed JWT issuer metadata.
OID4VCI notification endpoint
On roadmapWallet reports accepted, failed, or deleted credentials to the issuer notification endpoint.
Nonce endpoint
Fresh c_nonce for proofs during OpenID4VCI issuance.
Last updated on July 30, 2026