Normative version inconsistency for SD-JWT VC in 1.0 final

[Sakurann]

fixes #659 by changing typo in sd-jwt-vc version

[c2bo]

We need to touch that part anyway for 1.1 I believe (and check versions / remove some entries if there were no breaking changes)? Should this change be only scoped for 1.0 for the time being and we do a pass of the non-final specs part for 1.1 before final?

[brentzundel]

Discussed in call. We may need to update to 16, but only after making sure there aren't normative inconsistencies.
There is also an SD-JWT reference that need avaluation.

[jogu]

There's still an inconsistency as the normative references section now references draft 16. We need to update the normative references to be draft 10, unless there's a later draft that has no normative changes in which change we can update both places to that later version.

[brentzundel]

@Sakurann can you respond to the concerns raised by @jogu

[Sakurann]

Does @jogu 's concern only applies to the following sentence and section 2 vs 4? I don't understand the concern. is it still there if now the PR points to -16 and not -10?

A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

[Sakurann]

We need to touch that part anyway for 1.1 I believe (and check versions / remove some entries if there were no breaking changes)? Should this change be only scoped for 1.0 for the time being and we do a pass of the non-final specs part for 1.1 before final?

@c2bo do you see any problems with merging this PR now and we can revisit 1.1 before publication again

[c2bo]

We need to touch that part anyway for 1.1 I believe (and check versions / remove some entries if there were no breaking changes)? Should this change be only scoped for 1.0 for the time being and we do a pass of the non-final specs part for 1.1 before final?

@c2bo do you see any problems with merging this PR now and we can revisit 1.1 before publication again

fine by me and I believe Brent opened a new issue for that

[awoie]

Suggested change

	- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.
	- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2.4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

[fkj]

I agree that section 2.4 is the better reference. Section 2.4 also references the validation rules in section 2.5, so scoping it down like this makes it easier to find the rules without being too specific.

[awoie]

Suggested change

	- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.
	- A receiver (holder or verifier) of an SD-JWT VCLD applies the processing rules outlined in Section 2.4 of [@!I-D.ietf-oauth-sd-jwt-vc], including verifying signatures, validity periods, status information, etc.

[awoie]

thanks. we should use 2.4 instead of 2.

[paulbastian]

@javereec @fkj volunteering to review this PR

[jogu]

Draft 16 contains at least one breaking change ( https://www.ietf.org/archive/id/draft-ietf-oauth-sd-jwt-vc-16.html#name-document-history ):

Change lang to locale. While lang is more accurate, locale is what has traditionally been used in OpenID Connect and later related specs.

so I don't think we can just update to -16, unless people can think of language we can add that could explain this as not really being a breaking change.

There may be other breaking changes too, I didn't review the full history.

The alternative is to figure out how to make the normative references section of the draft refer to draft 10 (or the latest version that doesn't contain breaking changes). I don't know how we get mmarkdown/xml2rfc to reference a specific IETF draft rather than the latest one - probably we would need to create a manual reference instead of relying on the automatic [@!I-D.ietf-oauth-sd-jwt-vc] syntax.

[javereec]

Below are some notable differences between draft 10 and draft 16 of the SD-JWT VC spec that could potentially present an issue.

description	draft 10	draft 16
vct#integrity claim	Not part of "Registered JWT Claims"	Part of "Registered JWT Claims". Because if it, this must always be disclosed.
status claim constraint	No constraint on content format	Addition of "the associated Status List Token MUST be in JWT format" in section 2.2.2.2
Binary data encoding in claims	No requirement	Added requirement that: "Binary data in claims SHOULD be encoded as data URIs as defined in [RFC2397]" in section 2.2.2.3
Display data language tag property rename	Uses lang in section 8	Uses locale in section 4.5
SVG rendering method key change	Uses svg_template in section 8.1.2	Uses svg_templates in section 4.5.1.2
vct type metadata required	Not mentioned in type metadata in section 6.2	Mentioned and required in Type metadata in section 4.2
schema and schema_uri removed from type metadata	Mentioned in type metadata in section 6.2, but optional	Removed entirely from type metadata in section 4.2.
Type metadata glue documents (vctm) removed	Present	Removed
Introduction of mandatory claim in claim metadata	Not present	New mandatory boolean property. The claim itself is optional
Verification step when schema is present in type metadata removed	Contains "If a schema is provided in the Type Metadata, a recipient MUST validate the schema as defined in Section 6.5." in section 3.4	Verification step is removed in section 2.4

[awoie]

thanks. we should use 2.4 instead of 2.

I will also note that ETSI references -13. Because SD-JWT VC is probably most relevant for EUDI, and EUDI implementers will need to use -13, we should probably also use -13, or update to -16/-17 (next week) already. Between -13 and -16/-17 there shouldn't be any breaking changes.

[brentzundel]

After discussion in the WG today, we don't like it, but we should point to the latest version of SD-JWT VC and move forward.
Mid to long term there should probably be a registry.

[jogu]

After discussion in the WG today, we don't like it, but we should point to the latest version of SD-JWT VC and move forward.

Relevant minutes for references: https://lists.openid.net/pipermail/openid-specs-digital-credentials-protocols/Week-of-Mon-20260713/001320.html

The WG can't just decide "we're going to make breaking changes in an errata".

As I mentioned here #726 (comment) we really need to explain and justify why we're making a breaking change in an errata update (including making clear what behaviour we expect implementations with/without the errata update to have), and some of the explanation is likely to be guidance to implementers/ecosystems that needs to go into the specification text.

Mid to long term there should probably be a registry.

Can you expand on this point please? A registry of what? [Actually I think that question is answered by the minutes - I don't think a registry solves any of this problem - I believe it's a registry of credential format identifiers like dc+sd-jwt etc - but the registry still has to stay 'dc+sd-jwt' means "SD-JWT VC draft 18" and can't change the meaning of that value ever.)

[brentzundel]

Discussion in the group today: perhaps a breaking change in this circumstance might be necessary, and allowable under the need to address errata. If we go down this route, we need to be very explicit about the changes.
There seemed to be general support for this approach.
@Sakurann can you update this PR?

[Sakurann]

WG discussion (chair hat on)

multiple options:

• option 1: use the same sd-jwt format identifier but update the version -10 to -16/final
  • add a text saying that if the wallet does not know the version of sd-jwt vc, return it. many wallets do not know the version of the sd-jwt vc they hold. recommend final ver but not mandate.
• option 2: define format identifier per sd-jwt vc version (potentially a registry)
• option 3: define request parameter that allows verifier to specify sd-jwt version. if version is any, de facto same as option 1.

-> preferred direction seems to be option 1.

• for implementers who used VCI issuer metadata as opposed to sd-jwt vc metadata, same openid4vp code can be used. an email will be sent out asking implementers if anyone have strong objections updating from -10 to -16 (preferrably final ver of sd-jwt vc in vp 1.1 and haip 1.1 final)

what does conformance mean? need to provide clarity:

• strictly speaking, for vp 1.0, only returning sd-jwt vc -10 is compliant
• for 1.1, returning any sd-jwt vc version? returning an error is ok, but not non-compliant

[brentzundel]

Discussed today, @Sakurann please adjust this PR according to option 1. Make sure to mention wallet and verifier requirements.