search

mozilla / standards-positions

https://mozilla.github.io/standards-positions/
Mozilla Public License 2.0
633 stars 69 forks source link

Digital Credentials #1003

Closed RByers closed 3 months ago

RByers commented 5 months ago

Request for Mozilla Position on an Emerging Web Specification

Other information

The online digital credential space is complex space with lots of pieces, lots of uncertainty still, and perhaps a set of non-standardized browser-specific design properties. I think the useful review of this API is within the larger context and how having a browser API may make things better and/or worse, and the conditions (if any) under which Mozilla would be supportive of seeing this API added to the web. One possible useful resource is this talk I gave to PING at TPAC.

martinthomson commented 5 months ago

@RByers, the specification is pretty skeletal. I'm confident that I could NOT implement anything from that. The explainer has a banner saying that it isn't valid. What is going on with the proposal?

RByers commented 5 months ago

Yep, this is far from ready to ship but we do feel we're close to being able to do an origin trial, so I wanted to at least start this discussion. We're working on an updated explainer now which we should have posted in a week or so. It's fine with me if you say you can't form a standards position until the spec is more complete, including a more detailed security and privacy considerations section.

martinthomson commented 5 months ago

You got it. The issues that WebKit raise also give us pause. Enough so that I'd personally be inclined to say "negative", especially given the current state of the documentation. Has there been any effort to mitigate those concerns? Shipping an origin trial isn't exactly going to help there.

martinthomson commented 3 months ago

The digital credentials API is an extension to the credential management API that enables access to identity documentation that might be held in the user agent or a wallet on the same device.

We broadly agree with the concerns raised by the WebKit team, though we consider some of these to be significant enough to instead regard this proposal as negative. We observe some effort to mitigate these risks, but we are not confident that these will be successful in producing an unconditionally positive outcome. Additionally, our analysis revealed a privacy concern around the potential use of selective disclosure in the API.

A Web that follows our principles respects an individual’s choice about the identity they present to others. This is an essential part of making the Web a safe place for everyone. Credentials offered by governments and similar entities generally do not recognize this aspect of identity.

The potential that requests for digital credentials might become an expected part of online interactions exists and could damage this important characteristic of the Web. There are very few online interactions where providing identity is truly necessary, but many where sites (and governments) might prefer that the identity of a person be known. Increasing requests for identity does not mean a trivial annoyance. It could mean that people might be excluded from services and communities when they cannot provide credentials or instead choose to protect their privacy.

The potential for interoperability problems resulting from a proliferation of formats is particularly concerning. For people that seek to interact with government services, using identity documents in a fixed format from a single provider is likely to be acceptable. This isn’t true for a range of other services that might seek to use identity information, where limiting support for formats or providers might have the effect of unnecessarily excluding people.

We acknowledge that this style of API has superior utility to the hodgepodge of forms, QR codes, and other overlay systems that people have to navigate today when there is a genuine need to present credentials. Many people have wallets, or will get them soon, and Web integration could be far more convenient and reliable than those alternatives. We also recognize that the issuer-holder-verifier model that underpins the proposed API is a powerful tool for enabling individual autonomy, far superior to alternatives involving third party identity services. However, it is not enough to be superior to alternatives; it is essential to address risks and ensure that new features make the web better overall. We owe people a solution that acts in their interests, not just something that is justified because the alternative is worse or because it is more convenient.

The role of selective disclosure is an aspect of the overall system that is poorly understood and explored. While presenting a complete credential (a driving license or passport, say) can be readily understood to represent a total privacy break, the true privacy implications of selective disclosure are likely to be very poorly understood. The exact conditions under which selective disclosure might be engaged are not defined, which is already a problem. However, the potential for selective disclosure to be engaged without also providing unlinkability is very worrying.

There are some cases where linkability might be a desirable property, but the non-obvious privacy characteristics that result make it hard to recommend anything other than a system based on zero-knowledge proofs. Even if that were the case — and it seems like zero-knowledge solutions are unlikely to be ready in the near term — that sites are able to specify a provider makes zero-knowledge offerings risky for the same reasons that Privacy Pass is difficult to recommend.

Finally, we note that the proposal has too little information to implement. More work is needed.