draft-ietf-oauth-sd-jwt-vc-17

What's Changed

• Document History now with more 17 by @bc-pi in #407
• Fixes #408, #409, #410, #411, #412, #413, #417 by @awoie in #416
• Type Metadata retrieval words that might be less unclear by @bc-pi in #418

Full Changelog: draft-ietf-oauth-sd-jwt-vc-16...draft-ietf-oauth-sd-jwt-vc-17

draft-ietf-oauth-sd-jwt-vc-16

-16

• shepherd review and resulting changes
• use key discovery and validation mechanism instead of Issuer Signature Mechanism
• moved Display Metadata and Claim Metadata to be subsections of SD-JWT VC Type Metadata

What's Changed

• Remove reference to RFC9901 in abstract by @hannestschofenig in #396
• Clarify SD-JWT VC encoding format requirements by @hannestschofenig in #404
• Remove normative language introduction by @hannestschofenig in #403
• Update figure captions to include 'Example' by @hannestschofenig in #397
• Fix capitalization in security and privacy considerations by @hannestschofenig in #400
• Making the OAuth Status List an Informative Reference by @hannestschofenig in #401
• Nits by @hannestschofenig in #402
• Improve the intro to the Claim Metadata section by @hannestschofenig in #398
• shepherd review edits + Move Display & Claim Metadata to be subsections of SD-JWT VC Type Metadata by @bc-pi in #406

New Contributors

• @hannestschofenig made their first contribution in #396

Full Changelog: draft-ietf-oauth-sd-jwt-vc-15...draft-ietf-oauth-sd-jwt-vc-16

draft-ietf-oauth-sd-jwt-vc-15

-15

• remove unnecessary Relationships to Other Documents section

draft-ietf-oauth-sd-jwt-vc-14

-14

• State more explicitly that additional Issuer Signature Mechanisms can complement or override the defined mechanisms
• Add example of a vct value that is versioned (in the text)
• Use the three-word term Verifiable Digital Credential as consistently as possible throughout the document
• Update draft-ietf-oauth-selective-disclosure-jwt references to point to RFC 9901
• More consistent use of application/json content type and 200 status code when retrieving metadata
• Editorial improvements based on review feedback of -13
• Expand the example showing the vct claim
• Number and label the examples/figures
• Fix reference to Subresource Integrity document to point to W3C Recommendation version
• Move Privacy-Preserving Retrieval of Type Metadata section to Privacy Considerations where it belongs
• Move RFC 2397 to informative (only mentioned once and behind a SHOULD)
• Add line break between the two things in the JSON Web Token Claims Registration section
• Error responses both for JWT VC Issuer Metadata and Type Metadata retrieval now MUST use appropriate HTTP status codes
• Clarified that if an integrity property is present for a particular claim/property, the Consumer MUST verify the integrity of the retrieved document.
• Fixed the description of the claim metadata extension rules to correctly reflect the intended behavior.
• Added a note explaining the difference in overriding rules between claim metadata and display metadata when extending types.
• Merged section section 4 into section 3
• Replaced the term wallet with holder for consistency reasons

draft-ietf-oauth-sd-jwt-vc-13

-13

• Updated svg_template to match pluralised appendix example

draft-ietf-oauth-sd-jwt-vc-12

-12

• Change lang to locale. While lang is more accurate, locale is what has traditionally been used in OpenID Connect and later related specs.
• Remove JSON schema from Type Metadata
• Introduce optional mandatory property for claims
• Explicitly mention that Type Metadata can have additional stuff that has to be ignored if not understood
• Clarify that an SD-JWT VC doesn't contain a KB-JWT but rather might have an associated one (which makes it a SD-JWT+KB and Brian is still not sure about the term or these words, but it's where we've ended up)
• Remove the requirement to ignore unknown claims, as some applications may not want to follow this rule
• Fix cnf claim and JWK references and move them to normative
• List vct as one of the required values in type metadata and ensure that the use of the document integrity claims is clear
• Remove discussion of status and Status Provider from the Introduction
• Add a background_image property to the simple rendering aligned with the definition in OpenID4VCI
• Recommend to use sd=always or sd=never to avoid ambiguity and introduce rules for sd and mandatory when extending types
• Provide some guidance on versioning via the vct value
• Add security considerations for trust in type metadata
• Require data URIs for non-JSON types
• Require x5c to be in the protected header
• Clarify presentations of SD-JWT VC do not require KB
• Updated/expanded example for Type Metadata
• Be more consistent with style for lists of claims/parameters/properties
• Update PID example to make clear that it is not normative
• Clarification on processing of display metadata

draft-ietf-oauth-sd-jwt-vc-11

-11

• Clarify extend support for claim metadata
• Add privacy concerns regarding the use of x5u parameter in JWKs and similar remote retrieval mechanisms
• Added a section on Credential Type Extension and Issuer Authorization.
• Fixed an inconsistency to the description of display attribute of claim metadata.
• add vct#integrity to the list of claims that cannot be selectively disclosed
• Drop explicit treatment of the glue type metadata document concept
• Editorial updates and fixes.
• State that when the status claim is present and using the status_list mechanism, the associated Status List Token has to be a JWT.
• vct datatype is now just a string

draft-ietf-oauth-sd-jwt-vc-10

-10

• Rename 'Issuer-signed JWT Verification Key Validation' to 'Issuer Signature Mechanisms' and rework some text accordingly. Provide a web-based metadata resolution mechanism and an inline x509 mechanism. A DID-based mechanism is not explicitly provided herein but still possible via profile/extension. Be explicit that the employed Issuer Signature Mechanism has to be one that is permitted for the Issuer according to policy. Be more clear that one permitted Issuer Signature Mechanism is sufficient.
• Fix [...]#integrity claim values in examples (Subresource Integrity uses regular base64 encoding and some were wrong length)

draft-ietf-oauth-sd-jwt-vc-09

-09

• Use SD-JWT KB in place of SD-JWT with Key Binding JWT
• Editorial changes
• Document reasons for not using JSON Pointer or JSON Path (Issue #267)
• Clarify that private claim names MAY be used
• Update PID Example
• Fix section numbering in a few SD-JWT references

draft-ietf-oauth-sd-jwt-vc-08

-08

• Fix formatting issue introduced by the reintroduction of the DID paragraph in -07