Open danielfett opened 3 weeks ago
There is also the possibility that such a mechanism is not necessary or appropriate in a credential query language.
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.
@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.
@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:
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?).
The
purpose
element was removed from the new query language until the exact mechanism was discussed and agreed on.Relevant
_Originally posted by @awoie in https://github.com/openid/OpenID4VP/pull/220#discussion_r1696310253_