Developer Console
The Developer Console is the deployment-aware API workspace. It shows only mounted and licensed API surfaces, renders their current OpenAPI descriptions and examples in Scalar, generates matching Postman artifacts, and forwards approved live requests without exposing the access token to browser code.
Use it beside Credentials, status, and trust, not as a replacement for that explanation. The guide tells you which operations belong together; the Developer Console tells you which of those operations this deployment actually exposes.
Runtime base path: /api/developer-console/v1
Three views of the same contract
- Catalog
- Scalar/OpenAPI
- Postman
GET /catalog returns a policy-filtered list of mounted tools. A missing tool may be disabled, unmounted, or unlicensed; the browser does not receive hidden entries and then conceal them with CSS.
For credential work, look for these surfaces:
| Guide step | Mounted API surface |
|---|---|
| Define SD-JWT, mdoc, or W3C design | Credential design |
| Create and transition status | Status-list management |
| Fetch public signed status | Status-list hosting |
| Create offer and issue | OID4VCI issuer |
| Author format-specific query | DCQL |
| Create request and verify | OID4VP verifier |
| Resolve provider, key, and certificate | KMS |
| Admit issuer/VICAL signer and attach policy | Trust domain |
Select a catalog tool to load its mounted OpenAPI document from GET /specs/{specId}. Scalar shows the operation description, parameters, named request examples, response schemas, security, product scope, and license metadata from that deployment.
The profile guides deliberately point to named examples such as VCDM 1.1 employee credential, VCDM 2.0 employee credential, mdoc CWT status list, and both StatusList2021 examples. Do not copy the first example in a dropdown without confirming its profile.
The console generates a deterministic Product > Guide > Story collection from the same filtered catalog. Its matching environment contains deployment hosts and identifiers, never secrets or access tokens.
- Generated Developer Console collection
- Generated Developer Console environment
- Four credential/status profiles
The generated collection is a catalog mirror. The dedicated credential/status collection is a curated learning sequence with format-specific prerequisites, execution order, response checks, and failure boundaries.
Run one complete credential profile
Do not mix folders. Choose one row and keep its design, OID4VCI format, credential status reference, public status response, and verification query aligned.
| Collection folder | Credential format | Status format | What to inspect after issuance |
|---|---|---|---|
| 01 JWT Token Status List + SD-JWT VC | dc+sd-jwt | JWT Token Status, application/statuslist+jwt | SD-JWT vct, holder binding, disclosures, status.status_list URI/index |
| 02 CWT Token Status List + ISO mdoc | mso_mdoc | CWT Token Status, application/statuslist+cwt | CBOR/MSO docType, DSC x5chain, device/holder binding, MSO status URI/index |
| 03 W3C VCDM 1.1 + StatusList2021 | jwt_vc_json | StatusList2021 VC-JWT, application/vc+jwt | VCDM 1.1 context/type and credentialStatus |
| 04 W3C VCDM 2.0 + StatusList2021 | jwt_vc_json-ld | StatusList2021 VC-JWT, application/vc+jwt | VCDM 2.0 context/type and credentialStatus |
The fifth folder contains Azure KMS, BYOK, and BYOC mutations. Those requests are disabled by default because they require an explicitly approved Azure target and tenant-owned credentials.
Before running a folder
Populate only values owned by your local or approved test deployment:
- tenant and gateway bases resolved from that deployment;
- a tenant-scoped management token held in an approved secret mechanism;
- a status-list KMS resource handle and provider-native signing alias;
- the issuer verification method or X.509 signing selection required by the profile;
- the OID4VCI credential endpoint, wallet access token, credential identifier, and proof obtained from the live protocol flow.
The collection does not manufacture a valid wallet proof or bypass OID4VCI. An empty credentialEndpoint, walletAccessToken, credentialIdentifier, or proofJwt means the issuance request is not ready.
Profile 1: SD-JWT VC and JWT Token Status
- What the guide means
- Admin Console
- Scalar/OpenAPI
SD-JWT VC uses JSON claims and selective disclosures. Its OID4VCI format is dc+sd-jwt. The status reference is issuer-signed as status.status_list.uri and idx; the referenced publication is a compact JWT Token Status List.
Run folder 01 in this order:
- Create JWT status list and save the returned list id.
- Fetch JWT status list and confirm
application/statuslist+jwt. - Complete the live OID4VCI offer/token steps and set the four wallet variables.
- Issue SD-JWT VC and decode the issuer-signed payload.
- Revoke SD-JWT status entry, fetch again after the cache policy permits, and verify rejection of the same credential.
Use the console to inspect the same configuration before running the request set.
Profile 2: ISO mdoc and CWT Token Status
- What the guide means
- Admin Console
- Scalar/OpenAPI
mdoc uses mso_mdoc, CBOR issuer-signed data, a DSC certificate chain, and optionally device authentication. Its status publication is raw COSE/CWT bytes. VICAL may contribute mdoc trust anchors, but it is not the status list.
Run folder 02 in this order:
- Create CWT mdoc status list and confirm
cwt,mdocProfile: status_list, and one-bit status. - Fetch CWT mdoc status list and confirm
application/statuslist+cwt; do not parse it as JSON. - Complete the live OID4VCI mdoc offer/token steps.
- Issue ISO mdoc, base64url-decode the returned opaque credential as CBOR, and inspect the MSO status URI/index.
- Revoke mdoc status entry, refresh the CWT, and verify rejection of the same mdoc.
Read mDoc VICAL and CWT status before claiming VICAL-backed verification.
Select the named mdoc examples rather than the default JSON/JWT example.
Profile 3: W3C VCDM 1.1 in JWT and StatusList2021
- What the guide means
- Admin Console
- Scalar/OpenAPI
VCDM 1.1 uses OID4VCI jwt_vc_json, the VCDM 1.1 context, and an issuer-signed credentialStatus object. The public status artifact is a StatusList2021 credential serialized as application/vc+jwt.
Run folder 03 in this order:
- Create VCDM 1.1 credential design and confirm its context and
EmployeeCredentialV11binding. - Create VCDM 1.1 StatusList2021 list.
- Complete OID4VCI issuance using the
jwt_vc_jsonconfiguration. - Decode the VC JWT and confirm
credentialStatus.statusListCredentialandstatusListIndex. - Fetch VCDM 1.1 StatusList2021 credential, then revoke and prove rejection after refresh.
The curated folder currently supplies the design, list, fetch, and revoke contracts. Preserve the real OID4VCI request and response as sanitized runtime evidence; do not infer issuance from design creation.
Select the named VCDM 1.1 examples in both operations.
Profile 4: W3C VCDM 2.0 in JWT and StatusList2021
- What the guide means
- Admin Console
- Scalar/OpenAPI
VCDM 2.0 uses OID4VCI jwt_vc_json-ld and the VCDM 2.0 context. It can use the same StatusList2021 entry shape as the VCDM 1.1 lane, but its credential contract is not interchangeable with 1.1.
Run folder 04 in this order:
- Create VCDM 2.0 credential design and confirm its context and
EmployeeCredentialV20binding. - Create VCDM 2.0 StatusList2021 list.
- Complete OID4VCI issuance using the
jwt_vc_json-ldconfiguration. - Decode the VC JWT and confirm VCDM 2.0 content plus
credentialStatus. - Fetch, revoke, refresh, and prove rejection as in the 1.1 lane.
Do not advertise VCDM 2.0 as jwt_vc_json merely because its serialization is a JWT.
Select the named VCDM 2.0 examples in both operations.
From issuance to verification
The four curated folders emphasize design and status. To complete the lifecycle in the live Developer Console, continue through the mounted OID4VCI, DCQL, and OID4VP tools:
- Create an offer for the exact credential configuration.
- Complete the wallet token and credential request.
- Inspect and store the credential in a real wallet.
- Author a DCQL query using the matching format and claim paths.
- Bind a pinned query version to the verifier.
- Create the OID4VP request and complete it with the wallet.
- Record signature/holder or device binding, trust, and status outcomes separately.
A created offer, server-side testing session, or rendered QR is not proof that a wallet stored or presented a credential.
Exposure and safety model
Two settings decide what appears:
- Console exposure is tenant-wide:
PUBLICorAS_PROTECTED; the default is protected. - Tool exposure is per tool:
INHERIT,PUBLIC, orAS_PROTECTED; a tool can tighten but not weaken the console policy.
Each tool also has a safety class:
| Class | Reach |
|---|---|
STATIC | Specification and documentation only |
BROWSER_LOCAL | Runs locally without tenant state |
TENANT_READ | Reads tenant data |
TENANT_EXECUTE | Executes without persisting a change |
TENANT_MUTATE | Changes tenant state |
Anything above BROWSER_LOCAL, and anything not explicitly public-capable, is forced to AS_PROTECTED. A missing tenant or licensed capability returns 404 so unavailable tools are not exposed as a discoverable permission list.
How live Try it keeps tokens out of browser code
The backend-for-frontend owns the authorization-code session:
- Start
- Complete
- Forward
The browser sends an allowlisted route id. The server chooses authority, resource, audience, scope, and redirect rules, then returns an authorization URL plus HttpOnly session cookies and a CSRF value.
The callback rotates the cookies and returns grant metadata without returning the access token.
The browser supplies the route id and approved upstream request body. The server resolves the target, attaches its server-held credential, filters headers, and preserves the upstream status. Mutations require the cookie-backed CSRF session.
The BFF is not an arbitrary proxy: the browser cannot choose an unrestricted upstream URL, audience, or scope. A 409 from an issuer remains a 409; read the upstream body before diagnosing it as a console failure.
Diagnose unavailable surfaces
404: console disabled, tool disabled, route unmounted, or capability unlicensed. These are intentionally indistinguishable.401: authentication is required for the effective exposure.503: configuration or catalog resolution failed; treat this as an operational fault.