Skip to main content

OpenID for Verifiable Credentials

OpenID for Verifiable Credentials defines protocol contracts for two different interactions:

  • OpenID4VCI coordinates credential issuance between a wallet and a credential issuer.
  • OpenID4VP coordinates credential requests and presentations between a verifier and a wallet.

The protocols build on established OAuth and OpenID mechanisms while remaining able to carry different credential formats.

Issuance with OpenID4VCI​

An issuance flow can include:

  1. discovery of issuer metadata and supported credential configurations;
  2. a credential offer or another initiation mechanism;
  3. authorization of the wallet or end user;
  4. proof that the wallet controls required key material;
  5. issuance of one or more credentials;
  6. deferred delivery or notification where supported;
  7. lifecycle information needed for later use.

The protocol defines how the interaction is coordinated. It does not decide whether the applicant has been adequately proofed or whether the issuer is legally authorized to issue the credential.

Presentation with OpenID4VP​

A presentation flow can include:

  1. a verifier request describing the evidence required;
  2. verifier identity and purpose information;
  3. a wallet evaluation of compatible credentials;
  4. holder review and consent;
  5. creation of a fresh, audience-bound response;
  6. verifier validation and policy evaluation;
  7. an institutional decision outside the protocol.

A presentation response is evidence for a decision, not the decision itself.

Digital Credentials Query Language​

OpenID4VP defines DCQL, a JSON-encoded query language through which a verifier can describe acceptable credentials, claims, alternatives, and combinations.

DCQL can improve interoperability by making requests more explicit, but a technically valid query can still be disproportionate. UbID requires request design to respect purpose limitation and minimisation.

Same-device and cross-device interactions​

Wallet and verifier interactions may occur on the same device or across devices. QR codes, deep links, redirects, browser-mediated APIs, or other approved initiation mechanisms can be used depending on the profile.

Each profile must define protections for:

  • request authenticity;
  • redirect and origin validation;
  • nonce and state handling;
  • replay resistance;
  • audience binding;
  • response encryption where required;
  • user consent and transaction context;
  • timeout and abandonment behavior.

Credential-format independence​

OpenID4VCI and OpenID4VP are transport and coordination protocols. They can support credential formats such as SD-JWT-based credentials, W3C Verifiable Credentials, or ISO mobile documents when the ecosystem profile defines them.

Protocol compatibility does not mean format compatibility. Wallets, issuers, and verifiers must agree on the exact credential format, profile, algorithms, status mechanism, and claim semantics.

Metadata and discovery​

Public metadata can describe supported issuers, authorization servers, credential configurations, formats, algorithms, endpoints, and presentation capabilities. Metadata enables automation, but it is not a substitute for trust governance.

A partner should validate metadata provenance, pin approved profiles, reject unsupported combinations, and treat unexpected changes as controlled compatibility events.

UbID position​

The UbID reference architecture identifies OpenID4VCI-aligned issuance and OpenID4VP-aligned presentation as preferred interoperability contracts. The external specifications are final OpenID specifications, but UbID capability status and supported feature subsets remain product- and deployment-specific.

Documentation and partner profiles must therefore distinguish:

  • aligned architecture;
  • implemented flow;
  • tested interoperability profile;
  • production availability;
  • certified or independently assessed conformance.

These terms are not interchangeable.

Public documentation boundary​

This page does not publish production metadata, client identifiers, redirect URIs, transaction codes, credential offers, session values, customer DCQL, private schemas, or environment-specific endpoint contracts.

Source standards​

See Issuer Integration, Verifier Integration, and Wallet and Holder Integration.