API requests should provide the site with what they need to explain why and how requested credential information will be used

[npdoty]

Opaque, protocol-specific request strings don't allow site authors to indicate why and how each field in the request will be used, or to provide the context for a user to make a reasonable decision.

We could also open similar issues on the other specifications (although I'm not sure those organizations do work in public or would be interested in accepting feedback at this stage). But since the request is coming from the web site and in the context of a rich HTML page, this API is exactly the place to enforce that requests are legitimate and explained to the user.

(for dc2-proposal)

[aniltj]

Opaque, protocol-specific request strings don't allow site authors to indicate why and how each field in the request will be used, or to provide the context for a user to make a reasonable decision.

Instead of at the attribute/field level, would not the ability to return the purpose for which the information is requested, and how it will be treated after the purpose is fulfilled (deleted / shared / stored / protected / ?) be of more value to provide the user with the context for a reasonable decision?

[npdoty]

An overall explanation like that might be useful, yes. But if selective disclosure is intended as one of the primary privacy-focused mechanisms of this technology, then people will also need to be able to understand and make field-by-field decisions.

[Sakurann]

Opaque, protocol-specific request strings don't allow site authors to indicate why and how each field in the request will be used, or to provide the context for a user to make a reasonable decision.

This is not exactly true. OID4VP has a client_metadata parameter that can pass things like a human-readable terms of service document and a human-readable privacy policy document. OID4VP also has a pretty robust mechanism for verifier identification and passing the information that allows to pass information that the wallet can use to make a decision if it can trust the verifier or not.

We could also open similar issues on the other specifications (although I'm not sure those organizations do work in public or would be interested in accepting feedback at this stage).

For OpenID4VP, the work is done in public, completely open. Please feel free to open issues/PRs in https://github.com/openid/OpenID4VP and join our calls on Thursday 8am PST.

[npdoty]

A service's general privacy policy could be one piece of context, although it wouldn't be specific to the request and our experience has been that these long documents aren't useful to most users in making decisions.

I see that the Presentation Exchange draft contains optional purpose fields for a Presentation Definition and for each field in an optional fields list. Samples suggest these can be used as a short human-readable explanation of the intended purpose of a presentation, or the purpose of a particular field within that presentation.

Would it make more sense to put purpose specification at the top level of the API (and also identify it as part of the HTML page making the request)? Or to add requirements to the API that the UA will parse the request protocol string, require that certain optional properties are present and use those to present UI? The former seems more ergonomic and might more easily encourage the presentation of explanatory detail in the relevant context of the webpage. The latter could have the advantage of the explanatory detail only being described in a single place so that the UA and the wallet have the same context to present to the user.

[marcoscaceres]

Generally speaking, as the browser will likely hand this off to the OS or wallet, we need to check if OSs/Wallets are currently showing this kind of information.

If software is displaying these strings somewhere, we should be mindful to pass a localized string - or some localization information (dir, lang, text).

[npdoty]

More detailed description on requirements and motivation for in-context explanations: https://github.com/w3cping/credential-considerations/blob/main/credentials-considerations.md#in-context-explanations

[jogu]

As Nick pointed me at this issue on today's call, just to add a response:

We're currently discussing 'purpose' in the OID4VP spec, and getting pretty strong push back that browsers & wallets don't want to display purpose strings provided by the verifiers (because that kind of display of free form text has presented opportunities for the providing-entity to confuse the user before), and that this information should be presented in the verifier ( https://github.com/openid/OpenID4VP/issues/230 ).

That is separate from who the information will be sent to and what information is being requested, I think everyone is in agreement that the wallets will show that information, with the browser/platform potentially getting involved depending on the risk.

Also just to update on the working group's latest thinking on client_metadata parameter based on what Kristina said above:

OID4VP has a client_metadata parameter that can pass things like a human-readable terms of service document and a human-readable privacy policy document.

The latest thinking is that these things wouldn't be pass in the request (because in an unsigned request they're not inherently trustable as genuinely matching the party the information will be provided to) but they should still be available to the wallet somehow via whatever mechanism the wallet uses to establish trust in the verifier (so e.g. if OpenID Federation was in use they could be retrieved from the entity statement for the verifier). We're working to make that clear here: https://github.com/openid/OpenID4VP/pull/233