digital-credentials
digital-credentials copied to clipboard
WICG
API requests should provide the site with what they need to explain why and how requested credential information will be used
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)
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?
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.
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.
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.
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).
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
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 documentanda 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
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.
@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.
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
@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.
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.
@jogu I believe the verifier should be responsible for explaining to the user how they're going to use credentials when they make a credential request. If there is agreement on that point, I think it would be useful to record consensus on it, as frequently I've heard that that information will instead be handled by the wallet (perhaps obtained out of band?) and user consent gathered by the wallet.
My concern is that users won't have the information to make an informed decision if the verifier doesn't have any actual requirement to provide that information to the user, either on the website, at the API level, or as additional information communicated via the protocol to the wallet. Our past experience on the web has shown extremely poor uptake with informing the user -- sites have apparently preferred to just spam the user with requests to see what they can get. So far, despite a few requests on our calls, I've yet to see a demo site that explains to the user what credential information is needed and how it will be used.
That verifiers might decide later, after they've already obtained the credential information out of the user's wallet, that they want to use the information for some other purpose isn't a very encouraging condition that I think we want to support. Some sites will find it lucrative to decide later that they want to sell their user's identity information. If we design an API such that no promises are made by the verifier -- to the user or the user's wallet -- that would make it easier for websites to request information for one purpose and then change the purposes later, to sell user information.
I'd be happy to discuss proposals for this. To sketch two very briefly:
- in-page context with required fields, a button for the user to click to present a credential (This would elaborate on the suggestions in #134)
- enumerated values for purpose, sharing and retention, perhaps with additional site-provided explanatory string, in API method
See midi enumerated permission prompt example from https://github.com/mikewest/purposeful-permissions.
Browsers could normalize and pass on this text (with some confirmation that it was visible on the page) to the wallet, so that the wallet can either use it as part of its trust decisions, or record it as part of a log of credential presentations.
Where this information is declared (whether in the API call, or in surrounding required HTML content) would also be a useful place for links to trustmarks/validations/authentications as discussed in #136 (originally described as: "define a well-known way for a verifier to indicate registration, validation, trustmark assurances or other necessary info").
@jogu I believe the verifier should be responsible for explaining to the user how they're going to use credentials when they make a credential request. If there is agreement on that point, I think it would be useful to record consensus on it, as frequently I've heard that that information will instead be handled by the wallet (perhaps obtained out of band?) and user consent gathered by the wallet.
It is possible this varies between jurisdiction and/or depending on the meaning of "user consent". My understanding has always been that under EU GDPR it would be essentially legally infeasible for wallets to gather consent on behalf of the verifier as to how the verifier can use the released information (because it would require the wallet and verifier to have a much stronger contractual relationship). I'm happy to be correct if my understand is not correct, but if this is correct, then insisting that wallets/browser collect consent on the purpose as well leads to the user potentially being asked the exact same question multiple times, which isn't likely to improve user understanding.
That verifiers might decide later, after they've already obtained the credential information out of the user's wallet, that they want to use the information for some other purpose isn't a very encouraging condition that I think we want to support. Some sites will find it lucrative to decide later that they want to sell their user's identity information. If we design an API such that no promises are made by the verifier -- to the user or the user's wallet -- that would make it easier for websites to request information for one purpose and then change the purposes later, to sell user information.
I'm relatively sure it's a requirement of EU GDPR that I (as an end-user) can ask the verifier to use my data in new ways without requiring the consent of the third parties who provided the information (much of the point of GDPR is putting user's in control of their own data), and requiring that request to change usage to go back via the wallet seems problematic (for example, the wallet may not exist anymore or may no longer hold the credential).