digital-credentials
digital-credentials copied to clipboard
WICG
registration of and commitment to a particular use case and purpose
User agents can help users make decisions about credential presentation, and filter out inappropriate or invasive uses of the credential API, if there is some documented commitment regarding a limited set of purposes for which the site will request credentials.
Sites could indicate (at a well-known location, and perhaps with the signature of a registrar or auditor) what information they will request and what purpose it would be used for. User agents can consume that information in real-time, and researchers/policymakers can review it to detect malfeasance and provide accountability.
(This is related to #136 before that was re-titled to focus on the protocol registry only. #209 also proposes to reflect some of that information for the user in the prompt itself.)
https://github.com/w3c/credential-considerations/blob/main/credentials-considerations.md#registration-of-use-cases
I think this is a very interesting idea to explore, but would like to clarify what you mean by "User agents can consume that information in real-time", @npdoty. Specifically, were you imagining user agents to show UI based on that information? That would definitely introduce a lot of complexity to such an effort. It would be much easier to stand up if it's primarily for ensuring accountability via public declarations.
In #209 @c2bo says:
That is very close to what we are currently planning to do. We introduced verifier_info as an optional request parameter for OpenID4VP (https://openid.github.io/OpenID4VP/openid-4-verifiable-presentations-wg-draft.html#section-5.1-2.10.1). This parameter can carry additional information about the request & verifier, such as a registration certificate. In the case of EUDI that would basically be a signed statement (by a registrar) where the verifier (that was already onboarded to the ecosystem and is known/identified) registers a purpose. This information is also made publicly available and can be used to file complaints with data protection agencies etc.
@mharbach, how do you think this would best fit your UXR analysis? In particular, presumably wallets will show this information to some degree as well. I suppose we already have an issue with duplication between the platform credential selector and wallet consent dialogs, how concerned are you about that duplication? Since we want to visually differentiate the credential selector by risk and ensure information provided is relevant, my thinking is that when we have this signed statement in the EUDI context, we should figure out how to show at least a summary of the information in the selector dialog even though it should probably get shown again for wallet consent (same as the list of requested properties).
@c2bo is there somewhere I can follow to see the details evolve on this for EUDIW? I don't see a mention in the ARF itself but perhaps I missed it?
@RByers AFAIK, its currently a mix of several high-level requirements in the ARF and ETSI is in the process of creating a technical specification based on those requirements for presentation (not final yet, will be TS 119 472-2).
There is an explicit requirement on intended use being part of the (signed) presentation request and shown to the user:
RPA_10 When asking for User approval, the Wallet Unit SHALL show to the User the User-friendly description of the Relying Party’s intended use and, if available, the link to the applicable privacy policy. Note: The User-friendly description of the Relying Party’s intended use is included in the presentation request and also in the registration certificate, if available. The link to the privacy policy is included in the registration certificate, or in the absence of a registration certificate, the Wallet Unit obtained the link from the Registrar’s online service, if the User requested this. See RPRC_19a and other requirements in Topic 44 for details.
Note that the ARF currently does not mandate Registration certificates (they are optional while registration itself is mandatory) with the alternative to certificates being that wallets retrieve the registration information from the national registrars online. Not a big fan of not making registration certificates mandatory if we mandate registration, but that's another discussion.
@mharbach, how do you think this would best fit your UXR analysis? In particular, presumably wallets will show this information to some degree as well. I suppose we already have an issue with duplication between the platform credential selector and wallet consent dialogs, how concerned are you about that duplication? Since we want to visually differentiate the credential selector by risk and ensure information provided is relevant, my thinking is that when we have this signed statement in the EUDI context, we should figure out how to show at least a summary of the information in the selector dialog even though it should probably get shown again for wallet consent (same as the list of requested properties).
@RByers First of all, I think the important part is that the information is available at all and that the friction in the UI can be tailored based on whether or not a purpose is available at all and, in the best case, how well the stated purpose matches users expectations. When it comes to the ideal presentation, I think that will depend on a number of things, such as what the set of possible purposes is and how much the wallets are already differentiating their UI based on that. I'm not immediately concerned about duplication, as long as the information is presented in a way that's helpful to users. That's probably something we need to evaluate when first implementations are available.
I'm wondering about what this means for other systems, given that this would be only for EUDI. It'd be great if we could encourage the provision of purpose information beyond the EU.
I'm wondering about what this means for other systems, given that this would be only for EUDI. It'd be great if we could encourage the provision of purpose information beyond the EU.
Fully agree - imho we need purpose information, but it seems rather tricky to have a general-purpose mechanism without some general assumptions on the ecosystems. In earlier versions of OpenID4VP, we had a purpose text field in the query and had pretty long discussions about free-text display and its dangers if there is no trusted source for said text. The result of those discussions was the removal of the free-text purpose field and instead the introduction of the current mechanism.
I think at the very least we should make sure there is some form of purpose information being shared AND that information is somehow bound to that verifier (e.g., signed over).
I think at the very least we should make sure there is some form of purpose information being shared AND that information is somehow bound to that verifier (e.g., signed over).
Agreed, that would be important. I'm somewhat worried that (if I understand correctly) the current mechanism is based on an optional field. I was hoping that one of the standards in the DC layer cake would formulate some form of requirement for purpose information. If we can't have that, a less optimal way to encourage providing purpose information would be through more frictionful UI treatments at the OS/browser level.
I think at the very least we should make sure there is some form of purpose information being shared AND that information is somehow bound to that verifier (e.g., signed over).
Agreed, that would be important. I'm somewhat worried that (if I understand correctly) the current mechanism is based on an optional field. I was hoping that one of the standards in the DC layer cake would formulate some form of requirement for purpose information. If we can't have that, a less optimal way to encourage providing purpose information would be through more frictionful UI treatments at the OS/browser level.
We got rather strong push back against the initial proposal of a free-text purpose field and decided to remove it for version 1.0 and revisit for 1.1 to have a general-purpose mechanism that we can get consensus on in the WG. There were concerns that something like an enum with pre-defined meaning would be better suited / less dangerous than a free-text field that is rendered in the wallet context, especially if you do not assume trust relationships/onboarding of verifiers. But then the question becomes who governs these pre-defined purposes etc.
We got rather strong push back against the initial proposal of a free-text purpose field and decided to remove it for version 1.0 and revisit for 1.1 to have a general-purpose mechanism that we can get consensus on in the WG.
Makes sense.
There were concerns that something like an enum with pre-defined meaning would be better suited / less dangerous than a free-text field that is rendered in the wallet context, especially if you do not assume trust relationships/onboarding of verifiers. But then the question becomes who governs these pre-defined purposes etc.
Interesting. What were the concerns, though?
There is a ton of (academic) research on app store privacy labels and of course the P3P effort from the early 2000s, that might be useful efforts to learn from to some extent.
There is an explicit requirement on intended use being part of the (signed) presentation request and shown to the user:
RPA_10 When asking for User approval, the Wallet Unit SHALL show to the User the User-friendly description of the Relying Party’s intended use and, if available, the link to the applicable privacy policy. Note: The User-friendly description of the Relying Party’s intended use is included in the presentation request and also in the registration certificate, if available. The link to the privacy policy is included in the registration certificate, or in the absence of a registration certificate, the Wallet Unit obtained the link from the Registrar’s online service, if the User requested this. See RPRC_19a and other requirements in Topic 44 for details.
Is the verifier_info metadata structure (optional, unstructured metadata for assertions of various unspecified kinds) intended to satisfy the "user-friendly description of the Relying Party's intended use" for presentation by the wallet?
If that's the proposed way to satisfy the EU requirements, we (I don't mean W3C specifically, I don't have a strong preference about where) could define additional standardized ways to communicate a user-friendly string and the signatures for it, so that verifiers will know what to include and wallets will have some advance notice on how to consume it. I wouldn't think wallets would be ready to just parse open-ended statements in unspecified formats and from unspecified sources otherwise.
I think this is a very interesting idea to explore, but would like to clarify what you mean by "User agents can consume that information in real-time", @npdoty. Specifically, were you imagining user agents to show UI based on that information? That would definitely introduce a lot of complexity to such an effort. It would be much easier to stand up if it's primarily for ensuring accountability via public declarations.
It's useful for both real-time transparency and after-the-fact/out-of-band accountability. And I think accountability is more likely if it's also sometimes made visible to real end users in real time.
We have experience that statements that are shown to the user typically have additional weight when regulators are considering whether they are false or misleading. If the statement isn't user visible, then some of the time it will be filled with nonsense data, and if it's commonplace that it's nonsense data that no one relies on, then it's less likely that consumer protection enforcement will hold anyone accountable for it. Per @mharbach's comments, there are a lot of different lessons to draw from P3P experience (and not all would be the same now), but that's at least one consideration.
(It's a little like GREASE, except with the reverse intent?)