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

VC Issuance — Step 4 of 4: Refresh the Credential

A credential does not stay current: its claim values go out of date and its validity window runs out. OID4VCI section 14.5, Refreshing Issued Credentials, names two ways to deal with that. The first needs no End-User interaction at all: the wallet obtains a fresh Access Token with its Refresh Token (RFC 6749 section 6) and asks the Credential Endpoint again. The second is to start the issuance over from step 1, which does involve the End-User — and is the only route left once the Refresh Token has expired too. This page is the first: the two calls it is made of, and then what the issuer actually changed.

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

The Credential You Hold

What there is to refresh, and why anyone would: the validity window is the usual reason, but not the only one — a claim the issuer knows has changed is another, and the wallet cannot tell from the credential which of those applies.

Credential typeWhat kind of credential this is — a vct for an SD-JWT VC, a type array for a W3C credential. A refresh asks for the same one — this is not a way to obtain a different credential.	`—`
ValidityThe credential's validity window next to now — nbf and exp for a JWS-secured credential, validFrom and validUntil for a W3C one. An expired credential is the plainest case for refreshing; a valid one may still be refreshed (section 14.3).	`—`
Bound toThe holder key this credential is bound to — cnf.jwk for an SD-JWT VC, credentialSubject.id (a did:jwk) for a W3C credential, which has no cnf claim. Refreshing it in place needs the private half of that key, because the Credential Request has to carry a key proof for it.	`—`
ObtainedWhich credential configuration was asked for, from which issuer, when — and how many times it has been refreshed already.	`—`

Credential History

Every attempt made on this page, newest first — not only the ones that worked. Each access token refresh, each Credential Request, each poll of the Deferred Credential Endpoint, and what you then decided about what came back, is one row with what the issuer actually said. (It is this workflow's counterpart of the Token History pane on oauth2_oidc_2.html, which does the same for token sets — and it records more, because “I tried to refresh and it did not work” is the case a debugger is most needed for.)

The # column numbers the attempts in the order they were made, so every row has one; Gen is the generation number, which only the rows the wallet holds have — those are the credentials there is something to go back to. The newest 100 attempts are kept, in a scrolling list of fixed height so the panes below it do not move as the log grows.

Attempt is what was tried; Outcome is what came of it: success (an access token came back), FAILED (with the refusal in the next column), deferred (the issuer needs more time), returned — not kept yet (a credential is in hand awaiting your decision), kept, or discarded. Only the kept rows are generations the wallet holds — they carry a Gen number and can be activated; everything else is there as a record and says log only.

Activate makes a generation the credential in hand again, together with the holder key it is bound to (without that key the credential could not be presented at all), so you can move backwards as well as forwards: a refresh that turned out worse than what it replaced is a real outcome, and going back to the credential that was working is what a wallet does about it.

—

Refresh the Access Token

Plain OAuth 2.0: grant_type=refresh_token at the authorization server's Token Endpoint. Nothing about this call is OID4VCI-specific — which is section 14.5's point. What is specific is what the token is for: it is about to be spent on the Credential Endpoint again. If the access token in hand has not expired, this step can be skipped entirely; section 14.3 permits asking the Credential Endpoint again with the token you already have.

Token Endpointtoken_endpoint from the authorization server metadata retrieved in step 1 — the same endpoint the OIDC leg used to exchange the authorization code.	`—`
Access token in handThe access token the workflow currently holds, with its own expiry — the thing this call is about to replace.	`—`
Refresh TokenIssued alongside the access token, and the whole reason a credential can be refreshed without troubling the End-User. An authorization server is not obliged to issue one. Inspect
scope OPTIONAL, and narrowing only: RFC 6749 section 6 allows a scope no broader than the one originally granted. Leave it empty to keep the scope the credential was authorized with.
The callThe Token Request exactly as it will be sent: method, URL, and the form-encoded body. A confidential client's client_secret appears here too, because it is part of the call.
Exchange the refresh token for a fresh access token. No credential is issued by this call — that is the pane below.
ResponseThe token endpoint's answer, verbatim. Watch whether a new refresh_token comes back: a rotating server invalidates the old one.

Ask the Credential Endpoint Again

The same Credential Request step 2 makes — a fresh c_nonce, a proof of possession signed by the holder key, the credential named the way section 8.2 requires — sent with the access token from above. Section 14.3 is explicit that the endpoint may be asked again, and equally explicit that the issuer decides what comes back: the same credential, or an updated one. It may also decide the access token is no longer good enough and answer 401, which is its right.

Credential Endpointcredential_endpoint from the credential issuer metadata retrieved in step 1.	`—`
PresentingThe access token this request will carry as a Bearer credential — the refreshed one if the pane above produced one.	`—`
Holder key A refreshed credential normally stays bound to the key the old one used, which is what makes it a replacement. Binding a new key produces a credential a verifier will demand a different proof of possession for — a legitimate thing to want, but not a replacement.
Holder private key The private half of the key this credential is bound to. It is not in this browser's storage — either it was issued elsewhere, or "Save this holder key pair in browser localStorage" is turned off on step 2 — so paste it here to reuse that key. The file from Download Key Pair works as-is, and so does a bare private JWK.
c_nonceA fresh nonce from the issuer's Nonce Endpoint. The one step 2 used was spent on the original issuance — a c_nonce is single use.	`—`
Key proof (openid4vci-proof+jwt)The CREDENTIAL's key proof, the same one step 2 sends: typ openid4vci-proof+jwt, signed by the holder key, naming the credential issuer as its audience and carrying the c_nonce above. It is what binds the refreshed credential to that key, and every Credential Request carries one with or without DPoP. It is NOT the DPoP proof, which is a typ dpop+jwt header.
Request bodyThe JSON that will be POSTed. Identical in shape to step 2's — a refresh is not a different request, it is the same request made again.
The callThe fully assembled HTTP request: method, full URL, headers including the Bearer access token, and the body.
Send it. Nothing the wallet already holds is touched by this: what comes back is compared with the credential in hand, and replaces it only if you say so.
Deferred The issuer answered 202 with a transaction_id instead of a credential (section 9): the refreshed credential is not ready yet, and is collected from the Deferred Credential Endpoint. A refresh is nothing anyone is waiting on, so this page does not poll on a timer — it asks when you do.	`—` —
ResponseThe Credential Response, verbatim.

What Changed

Section 14.5 leaves it to the issuer “whether to update both the signature and the claim values, or only the signature”, and section 14.3 allows the answer to be the same credential over again. None of that can be assumed from the wallet's side, so it is read off the two credentials here. Note that the salts, Disclosures and digests are new every time whatever the issuer decided — that is how SD-JWT works, not evidence of a change — which is why the claim comparison is of values.

Disclosed claim values:

Keep which one?

Section 14.5: “the Wallet might need to check if it already has a Credential of the same type and, if necessary, delete the old Credential. Otherwise, the Wallet might end up with more than one Credential of the same type, without knowing which one is the latest.” Nothing has been replaced yet — that decision is the wallet's, so it is put here rather than made quietly.

—

Keeping it does not navigate anywhere: the Credential History pane above gains the new generation and marks it as the one in hand, and Verify in step 3 is there when you want the full check of it.

Next: Present It

The presentation workflow is the other half of the format: a Verifier asks for some of this credential's claims over OID4VP, and this wallet answers with only the Disclosures it chooses plus a Key Binding JWT. Nothing is copied by going there — both workflows read the same browser storage, so what goes is whatever this wallet is holding: the generation marked as in hand above, with the holder key it is bound to.

VC Tools

Tools that are useful at any point in these workflows, and belong to none of their steps.

DID Tools Resolve a DID to its document, read the keys it publishes, check that one of them really signed the credential this browser is holding, and check that the DID and an origin are the same entity.	Resolve a Decentralized Identifier (`did:jwk`, `did:key`, `did:web`) to its document, verify that a key it publishes signed the credential in this browser, and verify a domain linkage (DIF Well Known DID Configuration). Opens in this tab; the workflow's state is untouched.
Certificate Authority & X.509 Tools Build a Root, Intermediate and Issuing CA, issue certificates with any X.509v3 extension, and test a real TLS or mutual-TLS handshake with what you issued.	Build a certificate authority — Root, Intermediate and Issuing — and issue TLS server, TLS client, code-signing and S/MIME certificates with full X.509v3 extension control. Useful when the issuer or verifier is behind TLS you control. Opens in this tab; the workflow's state is untouched.