Issue a verifiable credential
Issues a credential to a holder upon presentation of a valid access token, as per OID4VCI. Supports encrypted and non-encrypted credential issuance.
For non-encrypted credential issuance the valid access token must be provided in one of the following header formats:
Bearer
- Authorization:
Bearer <access_token>. - Content-Type:
application/json - Body:
<credential request payload>
OR
DPoP Only required when using DPoP-bound access tokens.
- Authorization:
DPoP <access_token>. - DPoP:
<dpop_token> - Content-Type:
application/json - Body:
<credential request payload>
For encrypted credential issuance, contact us to configure how your MATTR VII enforces request and/or response encryption, and then:
- For request encryption,
Content-Typemust be set toapplication/jwtand the payload must be JWE formatted. - For response encryption, include the
credential_response_encryptionproperty in the raw request payload to specify encryption details.
Analytics Events
AuthorizationBearer <token>OID4VCI access token presented by a holder's wallet. Use the format: Authorization: Bearer <access_token>.
The wallet obtains this token from your tenant's token endpoint during a credential issuance flow. This is not the tenant management token used by operations that require bearerAuth.
DPoP?stringDPoP proof JWT. A signed JWT that demonstrates proof-of-possession of a private key.
When to use:
- Token endpoint: Required when
dpop_jktwas provided in the authorization request - Credential endpoint: Required when using DPoP-bound access tokens (Authorization header must use format:
Authorization: DPoP <access_token>)
The DPoP proof must be a signed JWT with the following structure:
Header:
alg: Must beES256typ: Must bedpop+jwtjwk: Public key (JWK format)
Payload:
htu: HTTP URI of the target endpointhtm: HTTP method (e.g.,POST)jti: Unique identifier for this DPoP proofiat: Unix timestamp when the DPoP proof was createdath: Optional base64url-encoded SHA-256 hash of theaccess_token. Required when authenticating with the resource server.htcd: Optional base64-encoded SHA-256 hash (content digest) of the HTTP request payload used to validate integrity.
Each DPoP proof must be unique and cannot be reused across requests.
- body
Exactly one of credential_configuration_id or credential_identifier is required.
credential_configuration_id*stringcredential_identifier?Credential IdentifierOne of the credential_identifiers values returned in the token response authorization_details, selecting the credential to issue for a single claim set.
Treat this value as opaque. It is derived by MATTR VII and does not encode the claim set identifier you supplied.
This property is mutually exclusive with credential_configuration_id, and only resolves while it remains bound to the grant. For mDocs, the same value is returned as credential_bundle_id on the credential response, so you can correlate an issued credential back to the claim set it was requested for.
Claim set identifiers are offered as an open beta preview feature and are not generally available yet. They are available on all tenants, and their behavior may change in a way that breaks existing integrations before they become generally available.
proofs?JSON object containing proof of possession of the key material the issued Credential shall be bound to.
credential_response_encryption?JSON object containing details for encrypting the issued credential in the response.
Credential issued
- response
credentials*array<>curl -X POST "https://example.com/v1/openid/credential" \ -H "Content-Type: application/json" \ -d '{ "credential_configuration_id": "2cdb2c15-39a7-4556-abab-4515ce2d831b", "proofs": { "jwt": [ "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9..." ] } }'{ "credentials": [ { "credential": { "@context": [ "https://www.w3.org/2018/credentials/v1" ], "id": "http://example.edu/credentials/3732", "type": [ "VerifiableCredential", "AlumniCredential" ], "issuer": "https://example.edu/issuers/14", "issuanceDate": "2020-03-10T04:24:12.164Z", "credentialSubject": { "id": "did:example:123", "alumniOf": "Example University" }, "proof": { "type": "RsaSignature2018", "created": "2020-03-10T04:24:12Z", "proofPurpose": "assertionMethod", "verificationMethod": "https://example.edu/issuers/keys/1", "jws": "EXAMPLE_JWS_TOKEN_eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiJ9aH0..." } } } ]}How would you rate this page?
Exchange authorization code for access token POST
This endpoint is used to exchange an authorization code or a pre-authorized code for an access token, which is later used to request a credential. - In an Authorization Code flow the authorization code is obtained from the authorization endpoint after the user has successfully authenticated. - In a Pre-authorized Code flow the pre-authorized code is obtained from the offer URI. See [https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-token-endpoint](https://openid.net/specs/openid-4-verifiable-credential-issuance-1_0.html#name-token-endpoint) for more information. When the session binds claim sets, `authorization_details` is determined by the credential issuer. A request that includes `authorization_details` is rejected with `invalid_authorization_details`. Claim set identifiers are offered as an **open beta preview** feature and are not generally available yet. They are available on all tenants, and their behavior may change in a way that breaks existing integrations before they become generally available.
Retrieve OID4VCI issuer metadata GET
Returns OID4VCI issuer metadata. This is the standard OID4VCI Well Known endpoint for your tenant. This endpoint is unprotected, public facing and can be deterministically found at the root of the tenant subdomain or alias by any party wishing to discover the OID4VCI capabilities.