OAuth2 & OpenID Connect Debugger — SD-JWT VC Issuance (1 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

SD-JWT VC Issuance — Step 1 of 4: Discover the Issuer

Issue a Selective Disclosure JWT Verifiable Credential (SD-JWT, RFC 9901) using OpenID for Verifiable Credential Issuance (OID4VCI). This page plays the wallet's part of the discovery phase: retrieve the Credential Issuer Metadata to learn what the issuer offers and where its endpoints are, retrieve the Authorization Server Metadata (RFC 8414) of the server that authorizes issuance, and settle the parameters both documents define. Step 2 authenticates the user through the existing OIDC Authorization Code flow on the debugger pages and asks the user to approve issuance; step 3 shows the credential the issuer returns.

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

Credential Offer

An issuer has offered you a credential. This is the Credential Offer it sent, exactly as received — nothing has been requested yet.

Offered bycredential_issuer from the offer. The panes below are filled in from it, so the rest of the workflow talks to this issuer.	`—`
Credential offeredcredential_configuration_ids — which entry of the issuer's credential_configurations_supported is on offer.	`—`
GrantThe grants member says how to get authorized. authorization_code sends you to the issuer to sign in; its issuer_state ties that request back to this offer.	`—`
How it arrivedBy value the offer travels in the credential_offer query parameter; by reference the wallet fetches it from credential_offer_uri.	`—`
The offerThe Credential Offer object itself (OID4VCI section 4).
Forget the offer and carry on as a wallet-initiated issuance. The metadata and configuration below stay as they are.

Receive a Credential Offer

In a cross-device flow the issuer shows a QR code on its own screen and your wallet is somewhere else, so the offer does not arrive in this browser by itself. Paste what the QR code contains — an openid-credential-offer:// URI, an https:// link carrying credential_offer or credential_offer_uri, or the Credential Offer JSON itself.

Scanned offer Whatever the QR code encodes. OID4VCI defines the openid-credential-offer:// URI scheme for exactly this hand-over.
Read the offer, then discover the issuer it names and the authorization server that issuer names — the same thing that happens when an offer arrives in the URL.

Credential Issuer Metadata (OID4VCI)

	An OID4VCI Credential Issuer publishes its metadata at a path that ends in `/.well-known/openid-credential-issuer`. See the OID4VCI spec.
Credential Issuer Metadata URL:The Credential Issuer Metadata endpoint. Retrieving it tells the wallet which credentials this issuer offers, which authorization server protects them, and where the nonce and credential endpoints are, and fills the OID4VCI half of the Configuration Parameters pane below. Populate Meta Data re-applies the document afterwards.
Fetch the Credential Issuer Metadata document from the URL above.	Forget the retrieved Credential Issuer Metadata document, its table, and the OID4VCI values it populated (on screen and in local storage).
Verify the signed_metadata JWT on the Credential Issuer Metadata document. The issuer's keys are resolved from the SD-JWT VC issuer metadata (/.well-known/jwt-vc-issuer) or from a jwks_uri in the document itself; the signature is verified in the browser, the iss claim is checked against credential_issuer, and any signed claim that disagrees with the plain JSON is reported.
Credential to request:One entry of credential_configurations_supported — the credential the wallet will ask this issuer to mint. Its format, vct, scope and proof algorithms fill the Configuration Parameters pane below.

Authorization Server Metadata (RFC 8414)

	An OAuth 2.0 Authorization Server Metadata endpoint uses a path that ends in `/.well-known/oauth-authorization-server`. See the RFC 8414 spec. This document is stored under the same names debugger.html uses, so retrieving it here also configures the OAuth2 / OIDC workflow.
Metadata Endpoint URL:The RFC 8414 metadata endpoint of the authorization server that protects this credential issuer. Defaulted from the credential issuer metadata's authorization_servers member once that document has been retrieved. Retrieving it fills the authorization server half of the Configuration Parameters pane below; Populate Meta Data re-applies the document afterwards.
Fetch the authorization server metadata document from the URL above.	Forget the retrieved authorization server metadata document and every value it populated — here AND on the debugger pages, since both share the same local storage.
Verify the signed_metadata JWT on the RFC 8414 document against the keys at its own jwks_uri, exactly as the Metadata Retrieval pane on debugger.html does.

Configuration Parameters

Every parameter the two metadata documents above can define, plus the client settings the authorization request needs. Retrieving either document fills its half of this pane; each value can then be overridden by hand, and Populate Meta Data in that pane re-applies the document. The OAuth 2.0 / OpenID Provider parameters are stored under the same names debugger.html uses, so what is set here is what the OIDC workflow will run with. A member the retrieved document leaves out is marked -->not defined<--.

Authorize Issuance (OIDC Authorization Code Flow)

OID4VCI authorizes issuance with an ordinary OAuth 2.0 / OpenID Connect Authorization Code flow, so this step hands over to the debugger pages that already implement it. The sdjwtvc=1 query parameter tells debugger.html that it is running as part of this workflow: it starts the authorization request with the configuration above, the user authenticates at the identity provider, debugger2.html exchanges the code for tokens, and the browser then returns here — to step 2, where the tokens are shown and the user is asked to approve issuance.

Hand-off URL:Where the Start button goes. The query parameter is what puts debugger.html into SD-JWT VC issuance mode.	`/debugger.html?sdjwtvc=1`
Authorization Endpoint:The endpoint the authorization request will be sent to — the value from the Configuration Parameters pane above.	`—`
Ask for the credential with: OID4VCI has two ways to say which credential is wanted (section 3.3.4). A scope is the simple one. authorization_details (RFC 9396) is the expressive one: the token response then grants credential_identifiers, and the Credential Request MUST name one of those instead of a credential_configuration_id.
Credential requested:The credential configuration the Credential Request will ask for in step 2.	`—`
Save the configuration and go to debugger.html?sdjwtvc=1 to authenticate the user.