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.
A credential format on SD-JWT with a type (vct), issuer key discovery and type metadata, used by digital identity wallets.
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.
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
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.
Revisions from the Datatracker, explanations from this site's daily runs, and mailing-list subjects naming the draft.
draft-ietf-oauth-sd-jwt-vc-26 telechat Secdir review
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.
Éric Vyncke's Discuss on draft-ietf-oauth-sd-jwt-vc-23: (with DISCUSS and COMMENT)
É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.
draft-ietf-oauth-sd-jwt-vc-25: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)
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.
draft-ietf-oauth-sd-jwt-vc-26: SD-JWT-based Verifiable Digital Credentials (SD-JWT VC)
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.