SD-JWT-based Verifiable Credentials (SD-JWT VC)

A credential format on SD-JWT with a type (vct), issuer key discovery and type metadata, used by digital identity wallets.

Where it stands
With the IESG
Official text
draft-ietf-oauth-sd-jwt-vc-26
2026-11-06
Documented support
0
Activity
4 signals in 90 days

No explainer written for this spec yet. The summary, relations and documented support below are maintained.

A credential format on SD-JWT with a type (vct), issuer key discovery and type metadata, used by digital identity wallets.

How it relates to other specs

Relations diagram
flowchart LR
  s_sd_jwt_vc["SD-JWT-based Verifiable Credentials"]
  s_sd_jwt["Selective Disclosure for JWTs"]
  s_status_list["Token Status List"]
  s_openid4vci["OpenID for Verifiable Credential Issuance"]
  s_openid4vp["OpenID for Verifiable Presentations"]
  style s_sd_jwt_vc stroke-width:3px
  s_sd_jwt_vc -->|Profiles| s_sd_jwt
  s_sd_jwt_vc -->|Builds on| s_status_list
  s_openid4vci -->|Works with| s_sd_jwt_vc
  s_openid4vp -->|Works with| s_sd_jwt_vc

Documented support

Adoption lists only support stated in official documentation (the vendor's or project's own, or a standards body's page naming it), and a weekly check confirms the cited phrase is still on that page. Experimental, alpha and beta support is counted separately as preview.

No sourced support entries collected yet. This says nothing about how widely it is used.

Activity

Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.

Explanations on this site

  • Minor or unclearOAuth WG

    The Secdir reviewer rates draft-ietf-oauth-sd-jwt-vc-26 as Ready, with all earlier concerns resolved.

    draft-ietf-oauth-sd-jwt-vc-26 telechat Secdir review

    Read the explanation

    Ionuț Mihalcea posted the Secdir telechat review of draft-ietf-oauth-sd-jwt-vc-26 with the result Ready. It updates the review of -19, and the reviewer says all issues raised there were resolved or explained by the authors. The message contains no new technical findings and no text change.

  • DiscussionOAuth WG

    The IESG ballot on sd-jwt-vc-23 questions two SHOULDs, and the authors answer that they will soften one and explain the other.

    Éric Vyncke's Discuss on draft-ietf-oauth-sd-jwt-vc-23: (with DISCUSS and COMMENT)

    Read the explanation

    Éric Vyncke entered a DISCUSS on -23. He asks why type matching (Section 2.2.2.2) and status checking (Section 2.4) are not MUSTs, and notes that the type-matching SHOULD is not really an interoperability requirement under BCP 14. An author replied that the type-matching text was added late, was meant to help layers above such as DCQL and OpenID4VP, and would be better without BCP 14 language. For status, the author said a verifier may be offline and that more text will cover the consequences of not checking. Vyncke's comments also second a DISCUSS about a missing formal update of RFC 7800 and suggest replacing the normative reference to RFC 6890 with the IANA IPv4 and IPv6 special-purpose registries. The -25 diff acts on the first two points.

    • A wallet or verifier library that matches credential types via aka_vcts and needs to know whether the rule is a protocol requirement
    • A verifier that may be offline and has to decide how to handle a credential with a status claim
  • EditorialOAuth WG

    The -25 revision drops the BCP 14 SHOULD on type matching, adds a status-check risk note and regenerates the examples.

    draft-ietf-oauth-sd-jwt-vc-25: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)

    Read the explanation

    The type-matching text no longer uses SHOULD: a Holder or Verifier now "treats" an SD-JWT VC as being of a given type if the type is the vct value or in aka_vcts. The status-check text keeps SHOULD but adds that a Verifier that does not check status cannot detect revocation or suspension and accepts that risk under its policy. The examples were rewritten: the typ in the example headers changed from vc+sd-jwt to dc+sd-jwt, the PID example now uses a fictional "Ændgard" issuer with a urn:example:eudi:pid:aendgard:1 vct and extra claims (sex, age_in_years, portrait and others), and the signatures and hashes were recomputed. The rest of the diff shows only table-of-contents page numbers and whitespace, and the material is truncated.

  • EditorialOAuth WG

    The -26 revision of SD-JWT VC only swaps an RFC 6890 reference for the IANA registries and drops a duplicate sentence.

    draft-ietf-oauth-sd-jwt-vc-26: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)

    Read the explanation

    Two textual changes, both tied to Éric Vyncke's review. The SSRF considerations now cite the IANA IPv4 and IPv6 Special-Purpose Address Registries instead of RFC 6890, and the RFC 6890 reference entry is removed. In Section 2.2.2.2 the sentence saying Holders and Verifiers can treat the SD-JWT VC as a credential of the vct and aka_vcts types is removed. The other diff hunks only change dates, expiry and whitespace in the document history. The history lists no change in requirements.