Standardization

This page lists the technical standards and protocols the issuer and verifier implement. Interoperability with wallets and with other issuers and verifiers rests on these, so each one links to its primary specification.

Data Model

Credentials use the W3C Verifiable Credentials (VC) Data Model 2.0 as the foundation for their structure. This standard provides a flexible and interoperable framework for representing claims issued by trusted entities. It ensures that credentials can be securely shared and verified without direct interaction with the issuer.

The ISO mdoc format (ISO/IEC 18013-5) is also supported for verification. Both formats have their issuer's certificate chain validated the same way — see Trust model.

Proof Mechanism

Selective Disclosure JSON Web Token (SD-JWT) provides the cryptographic proofs. SD-JWT allows selective disclosure of credential attributes while maintaining integrity and confidentiality, so a holder can disclose only a subset of the claims contained in a credential while keeping the rest confidential.

Credential Issuance

Credential issuance follows OpenID for Verifiable Credential Issuance (OID4VCI), specifically the pre-authorized code flow.

Issuers may establish cryptographic binding with holders — holder binding — so that a credential is usable only by the wallet it was issued to and cannot be replayed by someone who obtains a copy. Holder binding is optional and is requested per credential; see require_cryptographic_holder_binding on the verifier side.

The wire-level detail of every step is in OID4VCI issuance protocol.

Credential Presentation Protocol

OpenID for Verifiable Presentations (OID4VP) is used for remote presentation flows, facilitating secure online interactions between holders and verifiers. The verifier states what it wants using the Digital Credentials Query Language (DCQL), which is part of the same specification. A DCQL query is carried inside a verification query, the object you create and reuse.

The wire-level detail is in OID4VP presentation protocol.

Credential Status

Revocation uses the IETF Token Status List draft. Each issued credential carries an index into a status list the issuer publishes; a verifier fetches the list and checks the bit at that index. See Revocation.

Trust Infrastructure

Trust is established with X.509 certificate chains, carried in the JOSE x5c header of the credential's signature. A verifier reads the issuer's certificate out of the credential itself, so it needs no directory lookup and never contacts the issuer. Verifier identity works the same way in reverse, with the verifier's OID4VP client_id derived from a hash of its own certificate.

Trust model covers this in full.

Authentication of holders remains yours to control. You can point the issuer at your own OAuth 2.0 authorization server using the pre-authorized code grant (urn:ietf:params:oauth:grant-type:pre-authorized_code), so your existing authentication and session policies decide who is entitled to a credential. If you would rather not run one, the issuer can act as the authorization server itself. See OAuth 2.0 integration.