[c2bo]

per comment in #744

#744 (comment):

@c2bo will raise a separate PR for bringing the same changes to v1.0 Errata

(also added document history entry)

[brentzundel]

discussed today. We cam to agreement on the language for 1.o, @c2bo will revise the PR so v1.1 matches.

[brentzundel]

discussed today: All changes have been made to review comments, please re-check (@javereec and @jogu ?)

[fkj]

I think the language is clearer if you flip this around:

Suggested change

Note: A Wallet can infer that a Credential satisfies the `vct_values` parameter via out-of-band mechanisms e.g., type extension, in the absence of an `aka_vcts` claim. However, because standard evaluation by the Verifier relies strictly on matching `vct` or `aka_vcts` values, such presentations could be subject to rejection. To preserve data minimization and avoid presentation failure, Wallets should only use out-of-band type resolution when it is known the Verifier will resolve it in the same way and accept the presentation.

Note: A Wallet can infer that a Credential satisfies the `vct_values` parameter via out-of-band mechanisms e.g., type extension, in the absence of an `aka_vcts` claim. However, because standard evaluation by the Verifier relies strictly on matching `vct` or `aka_vcts` values, such presentations could be subject to rejection. To preserve data minimization and avoid presentation failure, Wallets SHOULD NOT use out-of-band type resolution except when it is known the Verifier will resolve the type in the same way and accept the presentation.

[jogu]

Leaving aside the wording (I'm okay with the new wording if we're going to say this), I think that SHOULD NOT is actually really hard to satisfy.

The onus really falls onto the verifier - if it's requesting a vct that is likely to have type extensions that aren't encoded in aka_vcts, it needs to keep on top of that.

If you think about the EU PID (where I believe it's expected that each country will extend it and have their own VCT) my expectation would be something like when Albania is admitted to the EU, it will be on each verifier to update to accept the VCT for Albania's PID. There is no realistic way I'm aware of for the wallet to know if the verifier has made that update or not.

The better fix is telling issuers they SHOULD include aka_vcts if they're extending a type. The VP spec is an odd place to put a requirement on issuers (and ideally it would be a MUST, which we can't do in 1.0 Errata or 1.1), but we could at least say it non-normatively here, and make it a SHOULD in the HAIP SD-JWT VC profile. Something like this (would need copying to 1.1 as well):

Suggested change

Note: A Wallet can infer that a Credential satisfies the `vct_values` parameter via out-of-band mechanisms e.g., type extension, in the absence of an `aka_vcts` claim. However, because standard evaluation by the Verifier relies strictly on matching `vct` or `aka_vcts` values, such presentations could be subject to rejection. To preserve data minimization and avoid presentation failure, Wallets should only use out-of-band type resolution when it is known the Verifier will resolve it in the same way and accept the presentation.

Note: In the absence of an `aka_vcts` claim, a Wallet can infer that a Credential satisfies the `vct_values` parameter via out-of-band mechanisms, e.g., type extension. However, a Wallet generally cannot know whether the Verifier will resolve the type in the same way, so such presentations may be rejected. The most reliable way to avoid this is for Issuers that extend a type to list the extended types in the `aka_vcts` claim defined in [@!I-D.ietf-oauth-sd-jwt-vc], so that Wallets and Verifiers can match against `vct_values` without out-of-band knowledge. A Verifier that requests a type likely to be extended by Credentials without an `aka_vcts` claim needs to recognize those extended types itself.

What do people think?

[c2bo]

We cannot really put requirements on Issuers and this is about handling the out of band resolution. We can wordsmith to make that text better, but i would not change the general direction of this text. which is basically a warning on the out-of band resoltion (to only use it of there is certainty the verifier will act the same by ecosystem rules etc.)

[jogu]

I don't think you can really get that certainty though. (and the text is carefully worded so it's not a requirement on Issuers.)

I at least see where the SHOULD / SHOULD NOT was going now. Can we clarify that it's "where the ecosystem requires Verifiers to use out of band resolution" perhaps?

I still think it would be useful to include a sentence that makes clearer that this is a thing the issuers need to get right (and to include an actual SHOULD on the issuer in HAIP).

[c2bo]

I agree with adding something in HAIP (or VCI for that matter), it just feels like the wrong place to me with OpenID4VP since we are talking about wallet <-> RP interactions here.