OAuth2 & OpenID Connect Debugger — SD-JWT VC Issuance (2 of 4)

0. Choose a use caseHow the issuance starts
1. Discover the issuerIssuer + authorization server metadata
2. Authorize & approveAuthenticate, review tokens, request it
3. The credentialThe issued SD-JWT VC and its disclosures
4. Refresh itRefresh Token, then the issuer again

← Back to step 1 (discovery & configuration)

SD-JWT VC Issuance — Step 2 of 4: Approve and Request the Credential

The user has authenticated through the OIDC Authorization Code flow and debugger2.html has exchanged the code for tokens. What follows is the OID4VCI credential request: the wallet proves possession of a key it just generated, the user approves the issuance, and the access token is presented to the issuer's Credential Endpoint.

Collapse all panes Tip: click a pane's title to collapse/expand it.

Token Request (pre-authorized code)

This offer carries a pre-authorized_code, so there was no authorization request and nobody was sent to a login page: the End-User was identified by the issuer beforehand and this code is the proof of it. The wallet goes straight to the token endpoint with the grant type urn:ietf:params:oauth:grant-type:pre-authorized_code.

Pre-authorized codeFrom the Credential Offer. Single use, like an authorization code.	`—`
Transaction Code The code the issuer displayed on ITS screen (tx_code). It never travels in the offer — that separation is what makes the cross-device flow safe to start from a QR code anyone could photograph.
The callThe Token Request exactly as it will be sent: method, URL, headers and the form-encoded body.
Redeem the pre-authorized code for an access token. Nothing is issued yet — the credential is requested further down this page.
ResponseThe token endpoint's answer, verbatim.

Tokens from the OIDC Authorization Code Flow

The token set debugger2.html obtained from the authorization server. The access token is what authorizes the credential request below; the ID token says who was authenticated.

Access TokenPresented to the Credential Endpoint as a Bearer credential. The issuer decides what to put in the credential based on who this token belongs to. Inspect
ID TokenThe OIDC authentication result. Not sent to the credential endpoint — shown so you can see who the credential will be about. Inspect
Refresh TokenNot used by the issuance itself — but it is what lets step 4 refresh the credential later without troubling the End-User (OID4VCI section 14.5). An authorization server is not obliged to issue one, and the pre-authorized code grant normally does not.
ID Token claimsThe decoded ID token payload — the authenticated subject the issuer will describe.

OID4VCI Credential Request

Everything the request is built from. The holder key pair is generated in this browser; only its public half leaves, inside the proof of possession, and the issuer copies it into the credential's cnf claim so a verifier can later demand proof that the presenter holds the private half.

Credential Endpointcredential_endpoint from the credential issuer metadata retrieved in step 1.	`—`
Credential Issuercredential_issuer — also the audience of the proof of possession.	`—`
Credential requestedcredential_configuration_id, its format and its vct — the credential the issuer is being asked to mint.	`—`
Holder public keyThe public half of the key pair generated in this browser, as a JWK. It goes in the proof JWT header and ends up in the credential's cnf claim.
Keep the key pairWhether the PRIVATE half of the holder key pair may be written to this browser's localStorage. It has to be kept for the workflow to continue past this page: step 4 needs it to refresh the credential, and the presentation pages need it to sign the Key Binding JWT. Turn it off to keep it out of storage, and carry it yourself with Download Key Pair.	Save this holder key pair in browser localStorage
c_nonceA fresh nonce from the issuer's Nonce Endpoint, carried by the proof so the issuer knows the proof was made for this request.	`—`
Proof of possessionA JWT with typ openid4vci-proof+jwt, signed by the holder key, naming the credential issuer as its audience and carrying the c_nonce.
JWT Header:The header of the proof JWT carried in the request body's proofs.jwt, decoded. typ marks it as an OID4VCI proof of possession, alg is what it was signed with, and jwk is the holder public key the credential will be bound to.
JWT Payload:The payload of the proof JWT carried in the request body's proofs.jwt, decoded: the wallet as iss, the credential issuer as aud, when it was signed (iat), and the c_nonce that ties it to this request.
Request bodyThe JSON that will be POSTed to the credential endpoint with the access token as a Bearer credential.

Credential Request Options

Three things the wallet gets to decide, each of which changes the request below.

Naming the credential OID4VCI section 8.2. If the token response granted credential_identifiers (because the authorization used authorization_details), the request MUST use credential_identifier and MUST NOT use credential_configuration_id. Otherwise it is the other way round. This is not a preference — it follows from what was granted.	`—`
Keys to bind One proof per key, one credential per proof (section 8.3). The issuer's batch_credential_issuance.batch_size is the most it will accept; asking for more than one is how a wallet gets several copies of the same credential bound to different keys.
Encrypt the response Section 10. The wallet sends a public key and the issuer returns a JWE instead of JSON, which this page then decrypts. Only offered when the issuer advertises credential_response_encryption.

Approve Issuance

Issue this credential?

Approving will send the Credential Request shown below to the issuer, exactly as it appears. The issuer will mint an SD-JWT VC describing the authenticated user and bound to the holder key generated on this page.

Issuer: —
Credential: —
Subject: —
Claims the issuer says this credential can carry: —

Deferred Issuance

The issuer answered 202 with a transaction_id instead of a credential: it cannot issue this one immediately (a background check, a human in the loop). The wallet comes back to the Deferred Credential Endpoint with that identifier until the credential is ready. The issuer says how long to wait between attempts in interval, and the transaction_id stops working the moment the credential has been collected.

Transactiontransaction_id from the Credential Response. It identifies this deferred issuance and nothing else.	`—`
Endpointdeferred_credential_endpoint from the credential issuer metadata. An issuer that cannot defer does not publish one.	`—`
The callThe Deferred Credential Request as it is sent, each time.
AttemptsEvery poll and what came back, so the waiting is visible rather than implied.	—
Ask the Deferred Credential Endpoint again without waiting for the interval. The wallet is already retrying on its own.