OpenID4VC
Learn how to configure OpenID4VC.
Overview
OpenID for Verifiable Credentials (OID4VC) is a protocol specification that extends OpenID Connect to enable the secure issuance and presentation of Verifiable Credentials. Built on widely-adopted OpenID Connect infrastructure, it provides standardized flows for three key parties: issuers who create credentials, holders who receive and store them, and verifiers who request and validate credentials.
The protocol defines two primary interactions: the Credential Issuance flow, which governs how credentials are securely issued to holders, and the Verifiable Presentation flow, which enables holders to present their credentials to verifiers. OID4VC supports multiple credential formats, flexible authentication methods, and privacy-preserving selective disclosure capabilities, making it a versatile solution for digital credential ecosystems.
The two flows are split into separate standards: OpenID for Verifiable Credential Issuance (OID4VCI) and OpenID for Verifiable Presentations (OID4VP). This page explains how to configure OID4VC for issuance, holding and verification.
For the full list of supported options, check the configuration reference.
Issuance
To enable OID4VCI, ensure an instance of type: "OPENID4VCI_DRAFT13"
is configured and enabled in the issuanceProtocol
object of the
configuration:
issuanceProtocol:
OPENID4VCI_DRAFT13:
display: 'exchange.openid'
type: 'OPENID4VCI_DRAFT13'
Several components of OID4VCI can be set in the configuration:
- Encryption key for tokens
- Timelines for codes and tokens
- Redirect URIs
Here's an example configuration without an encryption key, with explanations below:
issuanceProtocol:
OPENID4VCI_DRAFT13:
display: 'exchange.openid'
type: 'OPENID4VCI_DRAFT13'
params:
public:
preAuthorizedCodeExpiresIn: 300
tokenExpiresIn: 86400
refreshExpiresIn: 7776000
redirectUri:
enabled: true
allowedSchemes: ['https']
Encryption key
An encryption key must be set for each instance of OID4VCI. This key is typically put in a configuration override file or an environment variable.
See configuration override for details on providing an encryption key.
Code and token timelines
Use the following parameters to configure elements of the pre-authorized code flow of OID4VCI:
preAuthorizedCodeExpiresIn
: Sets how long, in seconds, a pre-authorized code remains valid for obtaining access tokens during the OpenID4VCI credential issuance flow. This window needs to be long enough for users to complete their wallet interaction, but short enough to minimize security risks.tokenExpiresIn
: Sets how long, in seconds, an access token remains valid for credential retrieval during the OpenID4VCI flow. This window must accommodate network latency, potential retry attempts, and your expected user interaction patterns.
Redirect URIs
URIs can be set for holders to be redirected to when they accept your credential offer. You must specify the allowed schemes. The redirect URI is then set on a per-credential basis during the credential creation process.
OID4VCI for ISO mdoc
For mdoc issuance, add the following parameter to your configuration:
refreshExpiresIn
: Sets how long, in seconds, wallets can wait to renew their expired mdoc credentials without going through the full issuance process again. As long as the wallet requests a new token before this time has elapsed it will be reissued, assuming the credential has not been suspended or revoked. Consider your security requirements when setting this value - a longer window provides more convenience for users but increases the lifetime of the original issuance tokens.
The expiration duration of the mdoc credential itself is configured in credential
format
configuration.
Related guide: mdoc validity
Holding
A wallet needs both an issuance protocol and a verification protocol configured and enabled to receive credentials and share presentations.
OID4VCI
To enable OID4VCI, ensure an instance of type: "OPENID4VCI_DRAFT13"
is
configured and enabled in the issuanceProtocol
object of the configuration:
issuanceProtocol:
OPENID4VCI_DRAFT13:
display: 'exchange.openid'
order: 1
type: 'OPENID4VCI_DRAFT13'
OID4VP
To enable OID4VP, ensure an instance of type: "OPENID4VP_DRAFT20"
is
configured and enabled in the verificationProtocol
object of the
configuration.
Use the supportedClientIdSchemes
parameter to define which Client
Identifier Schemes the wallet should support when validating the
authenticity of verifiers. Here's an example configuration:
verificationProtocol:
OPENID4VP_DRAFT20:
display: 'exchange.openid'
order: 1
type: 'OPENID4VP_DRAFT20'
params:
public:
holder:
supportedClientIdSchemes: [redirect_uri, verifier_attestation, did]
Configure for ISO mdoc
Wallets can be configured to present and exchange ISO mdocs using OID4VP. A few configurations need to be set to enable this:
- Set the URL scheme
- Define the accepted CA certificates
- Set the Client Identifier Scheme
Because of these differences, it is recommended to configure a second
instance of the OPENID4VP_DRAFT20
verification protocol. This allows
the wallet to parse incoming proof requests by their URL scheme and then
use the appropriate flavor of OID4VP for the exchange.
Here's an example configuration, with explanations below:
verificationProtocol:
MDOC_OPENID4VP:
display: "exchange.mdocOpenid"
order: 2
type: "OPENID4VP_DRAFT20"
params:
public:
urlScheme: mdoc-openid4vp // Flag this instance of OID4VC to be used when this URL scheme is encountered
x509CaCertificate: {{CA-CERTIFICATE}} // Define the Certificate Authority (CA) certificate used to validate verifier authenticity
holder:
supportedClientIdSchemes: [x509_san_dns] // Use the Client Identifier Scheme supported by the standard
URL scheme
By default the OID4VP verification protocol uses openid4vp
as the URL
scheme according to the OID4VP standard. The urlScheme
parameter allows
the specification of a different scheme. For the mdoc flavor of OID4VP we
use mdoc-openid4vp
as the URL scheme, to follow the ISO 18013-7 standard.
X.509 certificate
The wallet validates verifier authenticity by checking that the verifier's
certificate has been signed by an approved Certificate Authority. The
x509CaCertificate
parameter enables the wallet to define which CAs are
trusted.
Exchanges with verifiers whose certificates are not signed by trusted CAs will be rejected.
Client Identifier Scheme
The 18013-7 standard specifies the use of x509_san_dns
as the Client
Identifier Scheme for mdoc exchange. Set this as the only supported
scheme for presenting mdocs.
Verification
To enable OID4VP, ensure an instance of type: "OPENID4VP_DRAFT20"
is
configured and enabled in the verificationProtocol
object of the
configuration.
Several components of OID4VP can be set in the configuration:
- Request URI enabling
- Client Identifier Schemes
- Redirect URI
Here's an example configuration, with explanations below:
verificationProtocol:
OPENID4VP_DRAFT20:
display: 'exchange.openid'
order: 1
type: 'OPENID4VP_DRAFT20'
params:
public:
useRequestUri: true
verifier:
supportedClientIdSchemes: [redirect_uri, verifier_attestation, did]
defaultClientIdScheme: verifier_attestation
redirectUri:
enabled: true
allowedSchemes: ['https']
Request URI
When you create a proof request, a URI is generated. This URI can either contain the complete proof request information within it, or it can contain a request URI instead. If it contains a request URI, the wallet must make an HTTP request to fetch the complete proof request information.
Set to true
if:
- The proof request will be shared as a QR code. Using a request URI shortens the URL significantly, making it more suitable for use with a QR code.
Set to false
if:
- The proof request is small and will be shared as a hyperlink.
Client Identifier Schemes
Use supportedClientIdSchemes
to specify which schemes are supported in
interactions with wallets.
For any given interaction you can choose which scheme to use by passing
the clientIdScheme
param in the request body of the
/api/proof-request/v1/:id/share
endpoint:
{
"params": {
"clientIdScheme": "redirect_uri"
}
}
If no scheme is chosen during creation of the share URL, the
defaultClientIdScheme
is used.
Redirect URI
URIs can be set for holders to be redirected to when they accept your proof request. You must specify the allowed schemes. The redirect URI is then set on a per-proof request basis during the proof request creation process.
Configure for ISO mdoc
The system can be configured to verify ISO mdocs using OID4VP. A few configurations need to be set to enable this:
- Set the URL scheme
- Set the Client Identifier Scheme
- Set the redirect URI (if desired)
Because of these differences, it is recommended to configure a second
instance of the OPENID4VP_DRAFT20
verification protocol. These settings
enable wallets to parse incoming requests and use the appropriate flavor
of OID4VP for the exchange.
Here's an example configuration, with explanations below:
MDOC_OPENID4VP:
display: 'exchange.mdocOpenid'
order: 2
type: 'OPENID4VP_DRAFT20'
params:
public:
useRequestUri: true
urlScheme: mdoc-openid4vp
x509CaCertificate: MIIC6jCCApCg...
verifier:
supportedClientIdSchemes: [x509_san_dns]
defaultClientIdScheme: x509_san_dns
redirectUri:
enabled: true
allowedSchemes: ['https']
URL scheme
By default the OPENID4VP_DRAFT20
exchange protocol uses openid4vp
as
the URL scheme according to the OID4VP standard. The urlScheme
parameter allows the specification of a different scheme. For the mdoc
flavor of OID4VP we use mdoc-openid4vp
as the URL scheme, to follow
the ISO 18013-7 standard.
Client Identifier Scheme
The 18013-7 standard specifies the use of x509_san_dns
as the Client
Identifier Scheme for mdoc exchange. Set this as the only supported
scheme for verifying mdocs.
Redirect URI
If you configure a second instance of OPENID4VP_DRAFT20
for ISO mdocs,
be sure to set your redirect preferences and schemes.