Define "purpose" mechanism for new credential query language

[danielfett]

The purpose element was removed from the new query language until the exact mechanism was discussed and agreed on.

Relevant

IMO, free text is not a good idea for a lot of reasons, e.g., disambiguation between different translations of the the same reason and actually providing different reasons -> prone to errors; privacy; i18n/l18n which is hard to scale with this approach. A more appropriate approach is to define reason codes. There was a lot of work in other standards orgs on that, e.g., Kantara.

_Originally posted by @awoie in https://github.com/openid/OpenID4VP/pull/220#discussion_r1696310253_

[bc-pi]

There is also the possibility that such a mechanism is not necessary or appropriate in a credential query language.

[marcoscaceres]

It's also kinda not ideal that the RP can provide misleading information, even with an enum/codes. It's true that the query language might only give you what, and not the why... though the why could just be better presented by the RP.

This is usually what (web/native) apps do for permission requests. See "Priming users" from this article:

This is usually the preferred approach because it allows the for a richer set of affordances (using images, videos, text, sounds, whatever) to explain why something is needed. It also leaves i18n in the hands of developers.

Yes, a site/app could lie... but that could be mitigated at a policy level.

[npdoty]

@marcoscaceres this is not usually what web or native apps do for permission requests. Usually, sites provide no context and inundate users with permission requests and hope they just shrug and accept. It is rare that a site or app provides a detailed contextual explanation prior to initiating a permission request, although that is necessary for users to have informed understanding and provide genuine consent.

Given many many years of hoping that web sites and apps will provide the necessary contextual information up front and having seen no evidence of that adoption, I think it's well past time that we make changes to the Web platform so that sites need to provide some of this information when making high-sensitivity contextual requests for information. Smartphone operating systems/app stores increasingly do require this for applications -- both purpose strings and privacy labels. (That said, I don't know that mobile OS's have this functionality for web-to-app or app-to-app communications.)

There has been discussion in the WICG browser API setting and in Presentation Exchange about the possibility of requiring verifiers to provide that contextual information in the setting of the website or app and then providing a binding to that information to be passed along to a wallet application. In that way, a website could provide an explanation in the context of their site using HTML, and the information could also be passed along to the wallet. Some related discussion here: https://github.com/WICG/digital-credentials/issues/134

But some means of communicating purpose (and other relevant information beyond just the purpose) should be a requirement for passing on to a wallet application, or otherwise enforced prior to passing on to the wallet (or both). Removing this altogether from the API and hoping that verifiers will provide it -- despite ample evidence that they won't -- is not a good design choice.

[jogu]

@npdoty I appreciate the point, but I'm not sure there's a practical way forward that's been suggested yet.

It feels like trying to use technical measures to address what is (at least in many jurisdictions, e.g. GDPR within the EU) a legal problem.

Forcing or allowing people to provide a purpose in the query has potential downsides:

1. Because they're then providing the purpose in the query, it can be viewed that this lessens the need for the verifier to inform the user themselves
2. There's resistance to the wallets actually doing anything with the information provided in query for various reasons, not least that the information could be incomplete or (in the case of an attacker controlled site) actively trying to mislead the user.
3. We all acknowledge it's pretty hard (with exception, e.g. as you & others mention both Apple and Google has being pushing app developers relatively hard to explain to the user and/or Apple/Google why they need some of the higher value permissions) to get good purposes written, and protocol level enforcement will to some extent just gravitate towards people still doing the minimum to get pass that hurdle. (i.e. providing a purpose to the user is still pretty useless if it doesn't accurately reflect how the data will be used).

Or put another way, if we're going to pass this information to the wallet, and the wallet doesn't want to display it, then we need to have a clear idea of what we do expect the wallet to do with it. (And if we think about the browser API case and consider 'browser' instead of/as well as 'wallet' I'm not sure the answer gets any clearer. PEPC is interesting and I don't fully understand it - I'm not sure what protocol changes, if any, are needed at the OID4VP layer to enable that?).