API requests should provide the site with what they need to explain why and how requested credential information will be used about digital-credentials HOT 6 OPEN

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.

from digital-credentials.

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?

from digital-credentials.

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.

from digital-credentials.

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.

from digital-credentials.

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

from digital-credentials.

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

from digital-credentials.