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.

[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.