Write initial privacy considerations for unnecessary use

[johannhof]

@npdoty there are some things here that strongly touch on ethical considerations which I think you'd probably be able to say much more detailed and eloquently than I can, so I'm happy to get your thoughts and potential contributions (maybe as a follow-up). But I hope this is a solid start that captures the main issues and, where possible, mitigations.

---

Preview | Diff

[RByers]

I wasn't sure of how much of this we wanted in our spec vs. other docs like credential-considerations. But if the WG agreed we should go into this level of details here (even though DC API is just one small piece of the larger picture) then I think this is a great start and I'm supportive of adding it to the spec.

[TallTed]

Small changes in quest for better clarity

[johannhof]

Small changes in quest for better clarity

Thanks for proofreading!

[johannhof]

I wasn't sure of how much of this we wanted in our spec vs. other docs like credential-considerations. But if the WG agreed we should go into this level of details here (even though DC API is just one small piece of the larger picture) then I think this is a great start and I'm supportive of adding it to the spec.

To be clear there was no explicit discussion which could signal consensus but #243 has been unchallenged for some time and I believe that it is an important question for the DC API, even though many of these things would have to be addressed at a larger societal level.

[marcoscaceres]

How can they do this without first getting issued a certificate from an issuing authority? Sites can't just request credentials - they need cryptographic authorization to do so.

The attack needs to maybe be rethought, that the Issuing Authority and the RP are somehow colluding, but if the issuing authority and the RP are already in cahoots, then they RP can just directly ask the Issuing Authority to give the RP the persons details without pulling them from the wallet?

[timcappalli]

Sites can't just request credentials

Yes, they can, and in most cases they will. Most use cases outside of government issued credentials do not user reader authentication / verifier allowlisting.

[npdoty]

It's a large assumption that all issuers will require relying parties to get an authorization certificate for the specific information they are going to request and that all client software will deny requests from relying parties that do not have specific pre-authorization. We have specifically heard in previous CG meetings that this is directly counter to the requirements of issuers, wallets, and verifiers. Of the existing test deployments in browsers and operating systems, I don't know of any that enforce a requirement that all relying parties get pre-authorization from the issuer. There may be some requirements to this effect in eIDAS, but the implementation of those also seems pretty shaky (registration and access certificates appear to be optional in the ARF drafts I'm reading). I'm not aware of any US state that has implemented any part of this.

That said, if the Working Group believes this is a requirement that should be met throughout the ecosystem, that would be useful to document. I certainly agree that it should be met in order to increase accountability and decrease overasking and other kinds of abuse.

But even so, there would still be a significant risk of abuse. A relying party might get authorization from an issuer or other authority to request information for one purpose, and then request it for something else. They might do it maliciously from the start, or their requirements might change, or their might be internal abuse. I wouldn't conclude that it's entirely out of scope for detailing privacy considerations and mitigating threats that a malicious party may have misrepresented something to some third party at some point in the past.

[johannhof]

Thanks Tim, I was confused here for a moment but, still ramping up on the technical details, I believe that e.g. OpenID4VP supports unsigned requests and there's no formal requirement for the issuer to authorize the verifier. I'm happy to add a small clarification to the sentence, but this is more about establishing the threat model / problem space rather than going into technical details, i.e. this can still be a risk that exists, even if it's largely mitigated in practice.

[npdoty]

I also haven't seen any evidence that it is mitigated (at all, much less largely) or will be mitigated in practice, even for government-issued credentials.

[timcappalli]

@johannhof I'm more pushing back on Marcos' comments which appear to be making assumptions based on Apple's requirements for Apple Wallet, which do not reflect the reality of the rest of the ecosystem.

[johannhof]

Might make sense to continue discussing this in #279

[marcoscaceres]

The requirements are not for "Apple Wallet", they are a general requirement to participate in some ecosystems. That some don't require this is a concern, but it's not a universally accepted thing.

Ecosystems that don't do such mitigation maybe should?

[marcoscaceres]

This one yes... this could happen, again, if the Issuing Authority is too liberal handing out certificates.

This is a warning then for "Issuing Authorities" ... don't do this. We need to check if ISO or other standards bodies warn around not doing this.

[marcoscaceres]

Again, Issuing Authorities should limit what should be requested - but also RPs and protocols should restrict oversharing.

[marcoscaceres]

correct.

[marcoscaceres]

Yes, which is why we required the requests not be encrypted by design/from the start. We should say that we do this on purpose (i.e., the browser is not a "dumb pipe" here).

[johannhof]

I do mention this in other places. I feel like this is more of a high-level overview of the different actors and maybe not the place to get into design decisions?

[marcoscaceres]

I don't agree. It's a design consideration that some are willing to violate.

[marcoscaceres]

We should again say, "by design" ... the spec requires a UI to be presented (or it will... that will be a MUST).

[marcoscaceres]

Again, this requires collusion with the Issuing Authority. That needs to be called out (i.e., government authorities are generally not in the game of just letting any website ask for someone's passport, for instance).

[timcappalli]

government authorities are generally not in the game of just letting any website ask for someone's passport

That is literally the state of the physical world, and also how digital government credentials (derived passports, mDLs, etc) currently operate in the United States.

[johannhof]

+1, this is also my understanding. Also, I think this is a valid overall statement even if the exchange itself is authorized. Theft from the verifier can occur, even if it's outside of the scope of DC to ensure that it doesn't.

[mohamedamir]

What is a user agent in this context?
Only a browser?, I feel this is a bit too much to ask from browsers.
If it refers to the all involved user-agents, I think it's fair to even completely block the request in such case!

[johannhof]

So I'm not saying it should be blocked outright, just that it's recommended to put up additional friction and/or warnings to make it understandable to the user that the user agent does not know what is being requested. Does that make sense?

The user agent clarification bit is tracked in #263, which I can tackle soon

[mohamedamir]

My point is:

If this text is is written with browser in mind, a browser isn't expected to understand the majority of requests anyway given the current architecture.

If it is the collection of "browser + OS + wallet", if they don't understand the request, they probably cannot respond anyway.

[johannhof]

Right, I'd say this is where the trust boundary matters - if browser + OS + wallet are tightly integrated it may be reasonable to say these should be blocked. I can add a blurb about that. If we consider a component like the wallet outside of the trust boundary then this may not apply. But I get your point, and I can try to reword it a bit. :)

[simoneonofri]

Regarding trust boundaries, let's say that according to a basic model, two software components, even on the same device, are not trusted by default. Since there is not too much trust, if we cannot put specific mitigations in place, we can put a requirement to manage the threat we have in mind.

[mohamedamir]

I have a general comment here.
This PR raises very important points, however, those are more eco-system concerns, and a result of digitizing credentials more than the introduction of this API.
The API itself on its own has very little chance of addressing those concerns.
If the spec is what defines how the API should be implemented, I don't see how all of that is relevant here.
(sorry, if I am overlooking something here)

[johannhof]

@mohamedamir I agree that our overall goal should be to stay focused on what aspects of user privacy the API can influence, but I'm not sure this section is in conflict with that. Yes there are some very hard problems here that can not be solved by the DC API alone, but I think it's necessary for specification authors and implementers to consider harms to users that could arise from the use of their API and how to mitigate them.

"Unnecessary requests" is a big topic and as such there's a lengthy introduction that calls out harm in various ways, but I believe that towards the end I make some recommendations for how specifically the DC API can start to mitigate them (either directly or via protocol requirements).

[johannhof]

@mohamedamir this is ready for another look

[npdoty]

We don't need to address it immediately, but I suspect that the distinction here will not be entirely whether something is government-issued or not. There are other types of high-assurance credentials that are unique, cross-context, are issued by other authorities and have potential offline as well as online implications.

Related to #117 and #85.

[johannhof]

Yeah I was just reviewing these issues, I'll link to them here as an open question, thanks!

[kdenhartog]

++ to this. If I remember correctly, the framing that's been used within the verifiable credentials use cases note is whether the claims are 3P attested or self attested and whether the claims are identity based claims or non-identity based claims. This is likely something worth referencing and pointing to as an indication of how the specific claims being shared can impact the privacy model.

For example, if someone is just sharing self attested claims to speed up the process of filling out a form that's really not a big issue. This is basically the standard model used by web app forms today that allows for the user to falsify information to generate a pseudonym as they choose.

The Devices section of the note also indicates how the API may be used for non-identity based claims (albeit these specific claims likely do introduce fingerprinting risks, but we can ignore that for the high level distinction).

That seems to be a valid use case here to for this API IMO.

[burdges]

It's likely this appears elsewhere already, but..

If a credential C proves attributes of end users to some credential verifier V, then the credential C should never be used without the user agent first verifying some certificate C-V-DPA of the credential verifier V. This certificate C-V-DPA must be issued by a competent data protection authority DPA in EU terms, and specify the attributes, or attribute combinations, this specific credential verifier V may request of the end user.

In real world terms, if you say present and id at a bank or airport then you know you're physically in that bank or airport, but users have minimal idea if a website is legitimate when you present id there. You might've lIoydsbank.com when you wanted lloydsbank.com for example. It's already problematic that users type their PII into random websites, but if users can now prove their PII then the proving system itself should enforce that verifiers submit to whatever DPA the credential issuer requires.

At least in the EU, there already exist DPAs with considerable legal authority, so it seems insane for the credential system to prove attributes about the users, without first using a more conventional certificate-like infrastructure to verify the credential verifiers.

As some have pointed out, there are DPAs like Ireland who would ruber stamp credential verifiers, but really the credential issuer should determnine the required root DPA for verifier certification. A user agent holding a credential issued by France should always require a root certificate by France's national DPA before signing anything. A French DPA could then certify the Irish DPA, or a private auditing company, to certify end user credential verifiers, just like in regular certificate chains, or then later revoke that authorization, say after detecting abuse. Also, revocations should propagate through existing certificate revocation list infrastructure, which recently saw major upgrade.

All these techniques seem well established, but they should become practice from day one.

I raised this here earlier: #35 (comment)

[kdenhartog]

nit, since it's not directly relevant to the changes. We can change this in a follow up issue if you'd prefer.

I'm not sure if this framing is the best way to speak to this problem. All attributes maintain some level of information entropy which are either highly unique or not. I don't think it's useful to frame this as an either or claim, but rather should consider the specific bit entropy of the claim on an individual basis.

I'd suggest something more like the following:

All attributes maintain some amount of information entropy which can be highly unique or not. In the case of many identity based claims, these will be highly unique such as a name, driver's license numbers, or phone numbers. The requesting page therefore needs to be more purposeful in the information they request depending on the level of information entropy that can be deduced from the combined subset of claims within a credential.

[kdenhartog]

nit: I think we reasonably can deduce the amount of information entropy being revealed on a per credential basis and change the permissioning experience accordingly.

For example, if a verifier submits a request for just an age attribute over 21, we can reasonably deduce that this reveals -log2(6Bil/8bil) which is roughly .43 bits of entropy. On the other hand, revealing an attribute like a name should be assumed to be more unique. If it's just a first name, it's less unique than if it's first and last name.

In this way, the browser can prompt differently and engage the user depending on the relevant claims being requested by the site and this can be done with simple heuristics built on common claims. If however we cannot deduce it, then we would warn the user and deter them from sharing in the same way that we would with safe browsing interstitials (UX designed for friction, but it can be overridden).

[kdenhartog]

Are we concerned about which site is making the request? For example, do we expect that the request is only made from the top level site, or will we be allowing the API to be called by an iframe with a different origin?

[kdenhartog]

Do we have any sort of mitigations that are being suggested here or is the intent of this to just call out that we acknowledge this is a problem only?

[kdenhartog]

This doesn't align well with the browser trust model IMO. A site is granted a limited set of permissions and is isolated in a sandbox for a reason. In this case, saying that we're ok with self-regulation asserts that we're okay with sites doing as they wish. As we've already seen with other lower stakes permissions policy use cases these often are not used appropriately. As such, I do not believe the minimum bar for a user agent should be build on the assumption that this is the ideal scenario for verifiers to self regulate. Instead, we should be building in pro-active mechanisms to prevent the use of these dark patterns that will emerge from the introduction of this API.

[kdenhartog]

Suggested change

	privacy.
	privacy. Implementers are encouraged to discourage these cases through the use
	of technical mitigation techniques highlighted above.

[kdenhartog]

Suggested change

	Mitigating unnecessary requests for non-government credentials
	Mitigating unnecessary requests for LA3P credentials

[kdenhartog]

Suggested change

	For non-government-issued credentials, it is recommended that the
	For LA3P credentials, it is recommended that the

[kdenhartog]

Suggested change

	credentials such as cinema tickets.
	credentials such as cinema tickets. In these cases, User Agents
	should consider the potential for fingerprinting risks if the user
	accepts the request.

[kdenhartog]

Thank you for including this as a potential mitigation technique. While it's a new idea, if we find it works appropriately, I think it could also be applied more generally to other permission policy abuses too which is encouraging. One step at a time though.