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 ( openid/OpenID4VP#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: openid/OpenID4VP#233

[npdoty]

I missed that this issue was assigned to me. What are is the group looking for at this point, a proposal or pull request for the spec? Does the group agree that we should address this in the digital-credentials API?

It seems like we had the proposed response that this would be addressed at the protocol level, and since then we've gotten direct confirmation that it's even less likely to be handled by the protocol than it was before.

[timcappalli]

@npdoty it's the wallet that ultimately needs to present usage information and ask for consent before releasing a presentation. While the information itself may not be passed directly in the request, the wallet will typically use context from the request, in combination with local information or information from a trust framework to inform the user.

I don't see where this would slot in to the web platform layer of the exchange.

[npdoty]

It's the website that presents all the surrounding rich context about what the user is doing and what the site indicates to the user about the usage of the credential information. It's also the API that the developer has to communicate any additional information to the wallet. If the API doesn't provide a method for the site to explain why and how requested credential information will be used, and the protocol doesn't support sending that information to the wallet, then the user will never be able to make an informed decision.

More on transparency and in-context explanation: https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md#in-context-explanations

[timcappalli]

@npdoty Understood. Do you have a proposal or ideas on how to address this? I can allocate some time on the next meeting's agenda.

[jogu]

If the API doesn't provide a method for the site to explain why and how requested credential information will be used, and the protocol doesn't support sending that information to the wallet, then the user will never be able to make an informed decision.

Can you explain further why the verifier telling the user how they plan to use the credential isn't sufficient for the user to make an informed decision please? OAuth2 has always handled this in that way, it's the relying parties duty to inform the user how the shared information will be used, and the server's (wallet in this context) job to make sure the user is informed as to what will be shared.

This split makes sense as there's no need for the verifier to come back to the wallet in the future if the user wants to expand how the already shared information can be used.