Add additional text clarifying how to match vct and doctype

[GarethCOliver]

Resolves #741 by adding more explicit instructions on what allows a Credential to satisfy vct_values, and applies similar explicit text to doctype_value

This makes use of the SD-JWT VC draft 15 which added aka_vcts for this purpose

[c2bo]

I guess this should also go into 1.0 errata?

#741 also asks about the RP/Verifier side -> Should we add a sentence that these checks must be verified by the Verifier?

Text looks good otherwise imho

[Sakurann]

WG discussion: makes sense to have this in errata, too and also not to limit validation rules to the wallet but also verifier.

[brentzundel]

WG discussion suggests: Make sure it is clear this is an optional feature. @c2bo will propose text.

[GarethCOliver]

From conversation at IETF: SD-JWT-VC intends to add a claim to make it explicit what the super-types of a particular credential are (which will make this trivial and correct).

Until that is in place we shouldn't update this text, and should update to reference it when it is ready. Note that the part of this PR related to mdoc can still go through.

[GarethCOliver]

Updated text to reference the aka_vcts claim, making this nice and explicit.

[jogu]

I think if we make this change we have to make it in 1.0 as well - otherwise it's a breaking change in 1.1 and/or 1.0 and 1.1 differ in core behaviour.

But we need to come to a conclusion on #726 first really. If 1.0 is going to reference the latest SD-JWT spec then really 1.0 is going to gain this behaviour regardless, and if we agree on that then making it explicit in 1.0 is best.

(The actual changes in this PR do seem like a sensible way of addressing the problem.)

[jogu]

Note that this is tighter than the language in SD-JWT VC, which allows 'extends' to be considered too - https://drafts.oauth.net/oauth-sd-jwt-vc/draft-ietf-oauth-sd-jwt-vc.html#section-5.4

If the desired outcome is that only vct & aka_vcts matter, I think we should explicitly state that other data (like extends or any preexisting knowledge the wallet has of types that vct is equivalent to) MUST NOT be used.

However that feels like it would be a breaking change, so I think we need to say that Wallets may choose to return credentials with other vcts at a minimum in the case where aka_vcts is absent.

[Sakurann]

see #726 (comment)
1.1 and 1.0 errata will reference sd-jwt vc

[GarethCOliver]

Using just aka_vcts is by design. Using extends is highly problematic (both due to it being optional, and because it provides an inconsistent definition of extensibility between Wallet and Verifier).

aka_vcts is introduced for that purposes to provide a consistent shared definition so that a Wallet does not return an SD-JWT that a Verifier does not understand.

I think it would reasonable to provide it as a fallback when not present for backwards compatibility

[fkj]

I think that since using extends requires an out-of-band relationship anyway, we should not keep the fallback in the spec. Ecosystems that want to use the extends mechanism can still do that and the rest of us don't need to know about it. I think writing the "worse" way into the spec might make more people start doing it, which we should avoid.

[GarethCOliver]

updated text to make this RECOMMENDED and added a note

[brentzundel]

Discussed today, @GarethCOliver will adjust the text as in the meeting notes.

[javereec]

Editorial remarks. Looks good otherwise.

[Sakurann]

@jogu 1.0 is going to reference the latest SD-JWT spec. please re-review

[javereec]

Editorial suggestion

[javereec]

Another small editorial change.

Suggested change

	When a Wallet or Verifier needs to determine whether a Credential's type satisfies a Credential Query, it is RECOMMENDED do so by evaluating if at least one of the following is true:
	When a Wallet or Verifier needs to determine whether a Credential's type satisfies a Credential Query, it is RECOMMENDED to do so by evaluating if at least one of the following is true:

[brentzundel]

Discussed today, @jogu will re-review

[brentzundel]

Discussed in call. Looking for @jogu re-review