0. Choose a use case How the issuance starts 1. Discover the issuer Issuer + authorization server metadata 2. Authorize & approve Authenticate, review tokens, request it 3. The credential The issued SD-JWT VC and its disclosures 4. Refresh it Refresh Token, then the issuer again ← Back to step 1 (discovery & configuration)
SD-JWT VC Issuance — Step 3 of 4: The Issued Credential The SD-JWT VC the issuer returned, taken apart as RFC 9901 defines it: an issuer-signed JWT whose selectively-disclosable claims appear only as digests, followed by one Disclosure per claim. The holder decides which Disclosures to present; a verifier hashes each one it receives and looks for that digest in the JWT's _sd array.
Collapse all panes Tip: click a pane's title to collapse/expand it.
Issuer-signed JWT The signed part of the credential. _sd holds one digest per selectively-disclosable claim (plus any decoys the issuer added), cnf holds the holder's public key, and vct says what kind of credential this is.
Header typ should be the SD-JWT VC media type (dc+sd-jwt; vc+sd-jwt in earlier drafts), and alg must not be none.
Payload The issuer-signed claim set, with selectively-disclosable claims represented only by their digests in _sd.
Checks Signature verified against the issuer's published keys, plus the structural checks RFC 9901 and SD-JWT VC ask for.
Disclosures Each Disclosure is base64url([salt, claim name, claim value]). Its digest is base64url(SHA-256(the ASCII of that base64url string)) — recomputed here in the browser and looked up in the JWT's _sd array, which is exactly what a verifier does.
Resulting Claim Set What a verifier ends up with if the holder presents every Disclosure: the always-visible claims plus every disclosed claim, with the SD-JWT machinery (_sd, _sd_alg) removed. Presenting fewer Disclosures yields a smaller claim set — that is the point of selective disclosure.
Notify the Issuer The Credential Response carried a notification_id, which is the issuer asking to be told what became of the credential (OID4VCI section 11). It is optional for the wallet — an issuer cannot assume a notification will arrive — but it is how an issuer learns that a credential it minted was actually accepted, or was rejected, or has since been deleted. The access token from the issuance authorizes the call.
notification_id From the Credential Response. The issuer issues one per response, and it identifies the credential being reported on.
—Endpoint notification_endpoint from the credential issuer metadata. An issuer that does not want notifications does not publish one.
—Event The three events the spec defines: credential_accepted (stored successfully), credential_failure (something went wrong), credential_deleted (the End-User removed it).
credential_accepted credential_failure credential_deleted The call The Notification Request exactly as it will be sent.
POST it. A successful notification is answered with 204 and no body.
