Issue credentials

Issue SD-JWT VC and ISO/IEC 18013-5 mDoc credentials over OID4VCI. The Admin Console is the operator path; the REST examples below are sanitized request/response examples linked to the generated OpenAPI operation where one exists.

Audience: tenant administrator, issuer integrator, or service building an issuance pipeline.

Prerequisites: Onboard a tenant, configure a tenant KMS and issuer, and create a credential design. For a real wallet walkthrough, prepare an EUDI Wallet that supports the selected format and grant. The screenshots use the tenant-scoped console path; testing consoles must be exposed on the tenant host, not the platform host.

Configure the issuer

Use the issuer instance screens to configure the effective values before creating an offer:

1. Issuer Settings: metadata, security, and issuance defaults inherited by the instance.
2. Credential Defaults: common cryptography, signing, validity, status, and grant defaults.
3. Issuer Branding: the issuer identity and localized presentation.
4. Credentials: bind a credential design to a credential_configuration_id and choose its format-specific cryptography and status behavior.
5. Request Templates: reusable offer defaults and grant/authorization-server overrides.
6. Test: instance-scoped issuance console and its tenant-hosted exposure.

See Credential Issuer: Credentials, issuer defaults, and the OID4VCI connector pipeline for the field-level rules.

Authorization-server integration

The tenant Authorization Server area owns the hosted resource and its tenant-scoped clients, users, federation, and settings. The issuer then selects an authorization-server UUID through its issuer-level, credential-level, or template-level binding. The UUID is an administration selector; it is resolved to protocol metadata and never becomes a wire-format credential claim.

An external Keycloak proof is deployment-specific: publish discovery, register the client and redirect URI, configure scopes and claim mappings, bind the resource to the issuer, and complete the browser/wallet round trip before treating it as an interoperability result.

Select the credential format

The wire identifiers are format-specific and must not be mixed:

Credential	Configuration	DCQL / presentation consequence
IETF SD-JWT VC	format: "dc+sd-jwt" and a vct	Claims use SD-JWT paths; holder binding uses the SD-JWT key-binding proof.
ISO/IEC 18013-5 mDoc	format: "mso_mdoc" and a doctype	Claims use namespace-qualified mdoc paths such as org.iso.18013.5.1/family_name; the holder uses DeviceAuth.

For mDoc signing, the DSC means Document Signer Certificate. The IACA is the Issuing Authority CA that issues or anchors the DSC. Azure Key Vault can protect the non-exportable private key used by the issuer, but it does not create the customer's IACA/DSC chain. A VICAL is a separate ISO 18013-5 binary CBOR/COSE trust artifact; it is not the ETSI TS 119 602 JSON/JAdES trust-list format. See trust domains for the supported trust material boundary.

Pre-authorized-code flow

The backend creates the offer, the wallet resolves it, exchanges the pre-authorized code, and requests the credential with a wallet proof:

• Overview
• Request
• Response

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Resolve credential offer

Endpoint: GET /oid4vci/acme/oid4vci/credentials/offers/00000000-0000-4000-8000-000000000000

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Request EuPid credential

Endpoint: POST /oid4vci/acme/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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The same flow can target mso_mdoc; the mDoc offer and credential request show the namespace- qualified subject data and the mDoc configuration id:

• Overview
• Request
• Response

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Request Mdl credential

Endpoint: POST /oid4vci/acme/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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

The API example demonstrates pre-authorized issuance without a transaction-code challenge. Treat transaction-code support as a separate interoperability check: confirm the deployment's transaction-code request and validation behavior, then complete the exchange with a real wallet.

Authorization-code flow and external OIDC

An authorization-code offer carries authorization_code grant data instead of a pre-authorized code. The wallet follows the issuer's selected authorization server, authenticates there, and returns the code to the registered redirect URI before requesting the credential:

• Overview
• Request
• Response

Create offer with authorization code grant

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Fetch authorization server metadata

Endpoint: GET /.well-known/oauth-authorization-server

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

For an external Keycloak provider, configure an external OIDC authorization-server resource and issuer binding with the provider's discovery issuer, client registration, redirect URI, scopes, and claim mapping. The OID4VCI_AUTHORIZATION connector stage is the integration point for authorization context; the issuer pipeline can map approved connector fields into credential claims. Keycloak interoperability, ID-token claim mapping, redirect URI registration, and the wallet round trip require a live Keycloak and EUDI Wallet and are not proven by the sanitized HTTP captures alone. See authorization-server selection and tenant federation.

Connector-backed issuance and callbacks

When claims come from multiple systems, seed stable connector fields and bind invocations to the OID4VCI lifecycle rather than pushing long-lived PII into the offer:

Phase	Typical integration
OID4VCI_START / OID4VCI_PRE_AUTHORIZED	Create routing and issuance context.
OID4VCI_AUTHORIZATION / OID4VCI_TOKEN	Consume authenticated OIDC and token context.
OID4VCI_CREDENTIAL_REQUEST	Fetch current authoritative claims.
OID4VCI_PRE_ISSUE	Apply final policy, enrichment, and status decisions before signing.
OID4VCI_DEFERRED	Continue slow or asynchronous integrations.
OID4VCI_POST_ISSUANCE / OID4VCI_NOTIFICATION_RECEIPT	Retain evidence or process wallet notifications.

The pipeline REST API is for backend/admin seeding, observation, approval, and callback ingress; automatic execution is configured through PipelineConfiguration.invocationBindings. A callback must be capability-authenticated, correlation-bound, idempotent, and reconciled through the session/status API. Follow Attribute Pipeline, Connector Invocations, and OID4VCI REST API.

• Overview
• Request
• Response

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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Contribute attributes

Endpoint: POST /api/oid4vci/v1/backend/sessions/e2e-pipeline-001/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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Evaluate completeness

Endpoint: GET /api/oid4vci/v1/backend/sessions/e2e-pipeline-001/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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

• Overview
• Request
• Response

Approve issuance

Endpoint: POST /api/oid4vci/v1/backend/sessions/e2e-pipeline-001/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.

Live against connected environment

Connect an environment to rewrite this call to real service bases and run it.

Walk through it in the console

Open the issuer's Test area after configuring the instance and choose the offer/template to execute. The testing console is tenant-scoped:

The screenshot is an operator configuration proof. A complete EUDI Wallet proof additionally needs wallet authorization, proof-of-possession, mDoc issuer authentication/device authentication, trust evaluation, status retrieval, and any configured callback delivery.

Next

• Verify credentials with DCQL and OID4VP.
• Status lists and revocation.
• Keys and DID, including Azure Key Vault providerId/alias runtime operations.
• Issuing credentials over OID4VCI for the complete API walkthrough.