Developer credential journey
This is the shortest route through the developer surfaces for a tenant-scoped credential. Use the Admin Console for guided configuration, the REST reference for an integration contract, and the Developer Console or Postman for repeatable operation discovery and execution. The three surfaces share identifiers, but a successful request on one surface does not prove that a later wallet or verifier step completed.
The journey at a glance
| Stage | Start here | Carry forward | Result to confirm |
|---|---|---|---|
| 1. Authenticate and provision | Authentication and tenant provisioning | Tenant id, slug, gateway origins, operator or tenant token | The intended tenant resolves and the required capabilities are enabled |
| 2. Design claims | Credential designs | Design id/version, format binding, claims, context or type identifiers | The design is valid for the selected credential format |
| 3. Publish standalone status | Status lists and revocation | List id, public URI, proof format, media type, length and bit width | The public artifact is signed and served with the matching media type |
| 4. Configure the authorization server | Authorization-server configuration | Hosted/external server UUID, clients, identities, federation and active binding | The selected OAuth/OIDC resource is valid and available |
| 5. Configure the issuer | Issuer configuration | Issuer instance, credential configuration id, signing selector and status-list id | Issuer metadata advertises the exact configuration |
| 6. Issue to a wallet | Issuance details | Offer, grant, wallet token, proof, credential and status URI/index | The wallet receives a format-correct credential |
| 7. Configure verifier and DCQL | Verify credentials and DCQL authoring | Query id/version, verifier binding and trust-domain attachment | The request asks for the intended claims and credential format |
| 8. Establish trust | Trust domains | Domain id, anchors/admissions, policy and consumer attachment | The issuer and, for mdoc, DSC/IACA/VICAL inputs resolve under policy |
| 9. Verify and monitor status | Verification and status transitions | Presentation, verification result, status URI/index and refreshed list | Signature, holder/device binding, claims, trust, validity and status all pass |
The four documented pairings are SD-JWT VC with JWT Token Status, ISO mdoc with CWT Token Status, W3C VCDM 1.1 JWT with Bitstring Status, and W3C VCDM 2.0 JWT with Bitstring Status. The profile walkthroughs show their format-specific differences. Credentials, status, and trust is the decision matrix when choosing a profile.
Choose the right surface
Each task guide links its Console path, REST reference, and relevant static capture. Use the Developer Console to inspect the tenant-filtered catalog and the exact OpenAPI operation before running it. Its browser execution uses the authenticated BFF session; it does not expose an upstream bearer token to the page. See Developer Console for Scalar, request/response views, and the general export.
For the complete deployment journey, download the canonical
EDK-Enterprise-Deployment.postman_collection.json.
Its 01--05 folders bootstrap platform and tenant authentication; 04a Authentication Preflight
decodes and checks both administrative JWTs before any tenant operation; the later numbered folders
reuse the captured tenantAccessToken for tenant administration and runtime operations. For a
format-specific status/issuance handoff, also download
EDK-Credential-Status-Profiles.postman_collection.json.
It is secret-free and uses customer-neutral example values. Supply authentication and approved
runtime values separately.
The canonical collection is the cross-product correlation point: 02 Tenant Onboarding creates
the tenant, 03 Tenant Owner Activation and Sign-in completes the one-time bootstrap, 04 Tenant Service Token creates the confidential client, 04a Authentication Preflight verifies the token
boundaries, and 05 onward uses the tenant service token.
Each request description names the corresponding guide and the prerequisite failure explains which
numbered request to run next.
The authentication contract is explicit: platformAccessToken is limited to platform setup and
tenant registration; tenantAccessToken is the tenant confidential-client token for tenant APIs;
walletAccessToken is created by the matching OID4VCI token exchange and is used only by that wallet
credential session. Public metadata and hosted status-list reads carry no bearer token. The temporary
operatorSession and tenantBootstrapSession values are cleared after their token boundary.
Exact Postman profile lanes
Run one profile folder at a time. The intended order is status-list creation and public fetch,
offer creation and resolution, issuer and authorization-server discovery, token exchange, issuance,
trusted pre-revoke verification, revocation, refreshed public fetch, and post-revoke rejection.
The Manual items are explicit handoff checkpoints for wallet proof, trust, or format-specific
decoding; they are not claims of unattended interoperability.
| Profile folder | Key requests |
|---|---|
01 JWT Token Status List + SD-JWT VC | Create 01 JWT Token Status List + SD-JWT VC status list, Create 01 JWT Token Status List + SD-JWT VC offer, Issue 01 JWT Token Status List + SD-JWT VC, Revoke 01 JWT Token Status List + SD-JWT VC status entry, Refresh 01 JWT Token Status List + SD-JWT VC status list |
02 CWT Token Status List + ISO mDoc | Create 02 CWT Token Status List + ISO mDoc status list, Create 02 CWT Token Status List + ISO mDoc offer, Issue 02 CWT Token Status List + ISO mDoc, Revoke 02 CWT Token Status List + ISO mDoc status entry, Refresh 02 CWT Token Status List + ISO mDoc status list |
03 W3C VCDM 1.1 + Bitstring Status List | Create 03 W3C VCDM 1.1 + Bitstring Status List status list, Create VCDM 1.1 credential design, Create 03 W3C VCDM 1.1 + Bitstring Status List offer, Issue 03 W3C VCDM 1.1 + Bitstring Status List, Revoke 03 W3C VCDM 1.1 + Bitstring Status List status entry, Refresh 03 W3C VCDM 1.1 + Bitstring Status List status list |
04 W3C VCDM 2.0 + Bitstring Status List | Create 04 W3C VCDM 2.0 + Bitstring Status List status list, Create VCDM 2.0 credential design, Create 04 W3C VCDM 2.0 + Bitstring Status List offer, Issue 04 W3C VCDM 2.0 + Bitstring Status List, Revoke 04 W3C VCDM 2.0 + Bitstring Status List status entry, Refresh 04 W3C VCDM 2.0 + Bitstring Status List status list |
The separate 05 Azure KMS, BYOK, and BYOC (opt-in) folder contains Attach Azure KMS resource,
Register BYOK key, and Register BYOC provider-native certificate. Those are optional,
environment-dependent mutations. They are not prerequisites for the profile lanes and must only
run against an explicitly approved target.
Boundaries that matter
- A tenant token authorizes tenant-scoped management operations. A public status URI is fetched anonymously when the profile exposes public hosting; do not copy a management bearer token into that request.
- Creating a design does not configure an issuer. Creating a status list does not issue a credential or allocate an index for a nonexistent credential. The issued credential response supplies the status URI and index to use for later transitions.
- Issuance does not prove wallet storage or presentation. Verification does not replace status freshness, issuer trust, holder/device binding, or DCQL matching.
- VICAL, DSC/IACA validation, ETSI trust material, and credential status answer different trust questions. mDoc VICAL and CWT status keeps those paths separate.
When a step fails, inspect the response and the exact mounted operation before changing claims or URLs. Missing catalog entries usually indicate tenant, license, capability, or route exposure; format errors indicate a mismatch between the design, status profile, issuer configuration, or wallet request; verifier rejection is normally the correct fail-closed outcome.