Issuing the Credentials over OID4VCI
There are two ways to get subject data into an issuance: supply it inline when creating the offer (the simple approach), or let attribute sources contribute it into a pipeline session (the pipeline API). Both end in the same wallet-facing OID4VCI protocol. Backend schemas are in the OID4VCI Issuer API reference.
Simple approach: subject data in the offer
The backend creates a credential offer carrying the subject data and a pre-authorized code grant. The wallet scans the offer URI, exchanges the code for a token, and requests the credential.
In this walkthrough the wallet's holder key is generated in the KMS so the proof of possession can be signed during the run; in production the key lives in the holder's wallet:
- Overview
- Request
- Response
01 Generate wallet holder key
Endpoint: POST /api/kms/v1/keys
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- Overview
- Request
- Response
02 Create EuPid offer
Endpoint: POST /api/oid4vci/v1/backend/credential/offers
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
The wallet resolves the offer and reads the pre-authorized code:
- Overview
- Request
- Response
03 Resolve credential offer
Endpoint: GET /oid4vci/credentials/offers/00000000-0000-4000-8000-000000000012
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Issuer metadata announces the credential configurations and endpoints:
- Overview
- Request
- Response
04 Fetch issuer metadata
Endpoint: GET /.well-known/openid-credential-issuer/oid4vci
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
The token request uses the pre-authorized code grant. The response carries the access token for the credential endpoint and the nonce that must appear in the proof of possession:
- Overview
- Request
- Response
05 Exchange pre-authorized code for token
Endpoint: POST /token
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
The credential request includes an ES256 proof JWT (type openid4vci-proof+jwt) signed by the holder key, with the issuer as audience and the nonce from the token response. The issued SD-JWT carries the selectively disclosable claims and the status claim referencing the hosted status list:
- Overview
- Request
- Response
06 Request EuPid credential
Endpoint: POST /oid4vci/credential
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
The backend session reflects the completed lifecycle:
- Overview
- Request
- Response
07 Check EuPid offer status
Endpoint: GET /api/oid4vci/v1/backend/credential/offers/e2e-eupid-001
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
The Mdl follows the same sequence with namespace-qualified subject data; the response carries the ISO 18013-5 mdoc bound to the holder key:
- Overview
- Request
- Response
08 Create Mdl offer
Endpoint: POST /api/oid4vci/v1/backend/credential/offers
Captured response: 201 Created
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- Overview
- Request
- Response
11 Request Mdl credential
Endpoint: POST /oid4vci/credential
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
Pipeline API: attributes from sources
When subject data comes from multiple systems, or issuance needs an approval gate, use the attribute pipeline instead of inline subject data. Sources contribute attributes into a session keyed by correlation id; completeness is evaluated against the credential's mandatory claims; an approval decision releases issuance:
- Overview
- Request
- Response
01 Initialize pipeline session
Endpoint: POST /api/oid4vci/v1/backend/sessions
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- Overview
- Request
- Response
02 Contribute attributes
Endpoint: POST /api/oid4vci/v1/backend/sessions/OPAQUE-000041/attributes
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- Overview
- Request
- Response
03 Read accumulated attributes
Endpoint: GET /api/oid4vci/v1/backend/sessions/OPAQUE-000041/attributes
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- Overview
- Request
- Response
04 Evaluate completeness
Endpoint: GET /api/oid4vci/v1/backend/sessions/OPAQUE-000041/completeness
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
- Overview
- Request
- Response
05 Approve issuance
Endpoint: POST /api/oid4vci/v1/backend/sessions/OPAQUE-000041/approve
Captured response: 200 OK
This captured endpoint is shown from the E2E run; it is not mapped to one of the generated EDK REST API reference pages.
After approval, the offer and wallet protocol proceed exactly as in the simple approach, with the pipeline-collected attributes as subject data.