Enterprise integration scenarios

This page turns a representative enterprise integration request into a set of reusable EDK patterns. It is intentionally customer-neutral: the examples use acme.example.com, placeholder tokens, synthetic identifiers, and redacted cryptographic material. They are captured request/response shapes from an isolated local stack, not a connection to an external customer environment.

If you are still choosing a credential format, status mechanism, cryptographic provider, or trust model, start with Credentials, status, and trust. Return here for the captured request shapes that connect those decisions into one enterprise flow.

What the scenario covers

Concern	Reusable pattern	Primary guide
Select the complete profile	Choose the credential wire format, matching status representation, KMS/certificate boundary, and verifier trust source independently	Credentials, status, and trust
Bring your own keys	Register an existing provider key by providerId and provider-native alias; never send private material	Azure KMS, BYOK, and BYOC
Bring your own certificates	Register a provider-native leaf or stored public certificate chain; deletion removes only the EDK reference	Azure KMS, BYOK, and BYOC
Azure Key Vault	Attach and validate the Azure resource, then configure the tenant-owned credential reference	Azure KMS, BYOK, and BYOC
SD-JWT VC and ISO mDoc	Create separate credential configurations and offers; use vct for SD-JWT VC and docType plus namespace paths for mDoc	Credential status profile walkthroughs
CWT and mDoc status	Create a one-bit CWT Token Status List, embed its stable URI/index in MSO metadata, and resolve it fail-closed	Credential status profile walkthroughs
W3C VCDM 1.1 and StatusList2021	Use jwt_vc_json with a VCDM 1.1 context and bitstring_status_list with vc+jwt	Credential status profile walkthroughs
W3C VCDM 2.0 and StatusList2021	Use jwt_vc_json-ld with a VCDM 2.0 context and the same bitstring status-list join	Credential status profile walkthroughs
mDoc second edition	Use DeviceRequest version 1.1, alternatives, issuer identifiers, response-size limits, and explicit DeviceResponse statuses	mDoc second-edition use cases
mDoc VICAL	Configure signed CBOR/COSE issuer trust separately from ETSI trust lists and status tokens	mDoc VICAL and CWT status
DCQL and OID4VP	Author one query containing both formats, bind a pinned version, and create a verifier request	DCQL REST API
Developer Console	Discover the policy-filtered catalog, open the mounted OpenAPI spec, and use the generated route-safe Postman artifact	Developer Console

For the complete profile-by-profile request chains, use Credential status profile walkthroughs. For cloud KMS provisioning and external key/certificate ownership, use Azure KMS, BYOK, and BYOC.

1. Select the cryptographic provider

Runtime cryptographic calls use the tenant KMS API. The selector is providerId plus the provider-native alias (or kid), not an opaque platform resource handle. Opaque handles are configuration references used when a managed resource is attached, shared, rotated, or retired.

The following captured call creates a provider-scoped P-256 signing key. The same alias can then be used for public-key lookup, signing, verification, and later cleanup.

• Overview
• Request
• Response

Generate key with providerId and alias

Endpoint: POST /api/kms/v1/providers/default/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.

Live against connected environment

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

The raw signature request carries the same selector and base64-encoded input. The response contains only the signature; private key material is never returned.

• Overview
• Request
• Response

Create raw signature with providerId and alias

Endpoint: POST /api/kms/v1/signatures/raw/create

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.

For an existing external key, use POST /api/kms/v1/keys/register with providerId, the exact provider-native alias, and an optional kid. This records a tenant reference; it does not import or copy the key. For a shared Azure provider, the native object must satisfy the provider's tenant ownership check before it can be registered or used.

2. Associate certificates without exporting keys

Use the certificate-reference API for a tenant-owned certificate or a provider-native certificate. A stored public chain is supplied as base64 DER certificates. A provider-native Azure Key Vault leaf is addressed by the provider's certificate identifier and is read through the provider capability; the application does not fetch AIA URLs or export a PFX.

For an mDoc issuer, keep these relationships explicit:

• the non-exportable KMS key signs the Document Signer Certificate (DSC) or is the key associated with that DSC;
• the Issuing Authority CA (IACA) anchors the DSC chain;
• the mDoc x5chain matches the intended DSC/IACA path; and
• the verifier's trust policy admits that chain.

Azure Key Vault protects the key operation. It does not, by itself, establish IACA governance, VICAL trust, or wallet device authentication.

3. Create separate issuance lanes

Use separate credential configurations for SD-JWT VC and ISO mDoc. The captured offers show the important wire difference: ordinary claims are flat for SD-JWT VC, while mDoc claims are namespace-qualified and the offer selects the Mdl configuration.

• 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

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.

The backend pipeline is a separate, observable input path. Initialize a session, contribute data from an authorized backend or connector, evaluate completeness, and only then allow issuance or approval according to policy.

• 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.

The offer/session response proves that the server created protocol state. It does not prove that a wallet stored a credential, that an mDoc device response was authenticated, or that a verifier accepted the resulting credential.

4. Author one multi-format verifier request

DCQL must match each wire format independently. An SD-JWT VC query uses meta.vct_values; an mDoc query uses meta.doctype_value and paths beginning with the mDoc namespace. Bind a version to the verifier so an in-flight authorization request remains stable while a later query version is edited.

• Overview
• Request
• Response

Create combined query

Endpoint: POST /api/dcql/v1/queries

Captured response: 409 Conflict

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

Bind combined query to verifier

Endpoint: POST /api/dcql/v1/verifiers/00000000-0000-4000-8000-000000000000/bindings

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.

Create the OID4VP request from the bound query. The response contains a wallet-facing request URI and a backend status URI; a real wallet is still required to complete the holder and device-binding steps.

• Overview
• Request
• Response

Create verification request

Endpoint: POST /oid4vp/backend/auth/requests

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.

5. Publish and transition status

The management API creates a tenant-scoped list and the hosting API exposes the signed token at a stable correlation-id URL. Updating an entry changes the published status state; it does not rewrite the credential signature.

• Overview
• Request
• Response

04a Create X.509 token status list

Endpoint: POST /api/statuslist/v1/statuslists

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

Revoke a status entry

Endpoint: POST /api/statuslist/v1/statuslists/00000000-0000-4000-8000-000000000000/status

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 captured local lane uses an IETF Token Status List JWT (application/statuslist+jwt). The CWT/mDoc lane is documented with concrete management, hosting, MSO, and transition examples in mDoc VICAL and CWT status. The CWT response is deliberately shown as raw binary because its COSE signature and protected x5chain are generated with the tenant's selected key. A JWT status token, a CWT status token, and an mDoc MSO status field are different representations and must not be treated as interchangeable.

6. Azure deployment and local verification

Configure Azure Key Vault in the deployment layer with the deployment's secret-injection mechanism. Do not put client secrets, access tokens, private JWK members, or certificate private keys in Postman environments, OpenAPI examples, screenshots, or documentation. After configuration, verify the provider's capabilities and then exercise the tenant KMS API with providerId and aliases.

For local development, use the software provider or an explicitly provisioned test vault. The Compose and E2E wrappers in the deployment repository are the repeatable local lanes; run them only against an operator-supplied local or approved target manifest. The target-safety harness must reject a missing or unapproved target before making the first request.

Screenshots

These screenshots show the corresponding operator surfaces. They are illustrative, use sanitized data, and should be paired with the REST captures above rather than treated as runtime proof on their own.

Boundaries worth testing

Use the captured happy paths as a starting point, then add negative tests for:

• wrong tenant, provider, alias, kid, or certificate association;
• private-key material appearing in a request or response;
• mDoc docType or namespace mismatch;
• revoked, suspended, reactivated, expired, stale, malformed, and unavailable status sources;
• an untrusted or expired DSC/IACA chain;
• a DCQL version edited after a verifier session was created; and
• protected Developer Console operations called without the server-held session/CSRF flow.

These API captures and the generated Postman artifacts are source and local stack evidence. They do not replace a real EUDI Wallet presentation, external authorization-server claim-mapping test, VICAL producer/consumer proof, or an approved deployed-release run.