Digital Credentials API

[RByers]

WebKittens

@marcoscaceres @hober

Title of the spec

Digital Credentials

URL to the spec

https://wicg.github.io/digital-credentials/

URL to the spec's repository

https://github.com/WICG/digital-credentials

Issue Tracker URL

No response

Explainer URL

https://github.com/WICG/digital-credentials/blob/main/explainer.md

TAG Design Review URL

No response

Mozilla standards-positions issue URL

mozilla/standards-positions#1003

WebKit Bugzilla URL

https://bugs.webkit.org/show_bug.cgi?id=268516

Radar URL

rdar://problem/122053716

Description

We've been working together for some time on this space, starting with WebKit's first proposal for an mdoc explainer, so I assume WebKit is supportive in some capacity. But we're getting close to doing an intent-to-prototype in Chromium and so I wanted to get WebKit's official standards position on the record. Thanks!

[marcoscaceres]

Um, I think you mean "WebKit's standards position on the record".

But yes, I believe we (WebKit) are supportive of this effort for the reasons you mentioned:

• WebKit folks made the initial proposal
• WebKit folks are also prototyping
• WebKit folks are participating in the relevant community (WICG)
• I am co-editing the WICG's Digital Credentials spec.

Unless anyone objects, I'd like to mark this as supportive in a week or so.

[RByers]

Whoops, I'm sorry for the silly mistake. Yes of course, I'm only asking for WebKit's position 🙂. Corrected.

[marcoscaceres]

Although we are supportive, it's not without concerns - which I believe are broadly shared by the standards and wider community.

Annoyance

If Verifiers too liberally grant sites the ability to request credentials, this API could become annoying to users as they will be constantly asked "paper's please?" (e.g., a drivers license) where autofill could have sufficed, or worse, where passing high-value credentials would normally be unnecessary.

Further, although issuance is out of scope, issuance could become either an annoyance, or worse (a deliberate) burden to users, where Verifiers abuse their power. For example, having to physically go to a government agency to request a digital credential.

Interoperability

If the spec doesn't nail down the request format(s), there is a real risk of interop issues with either badly designed request formats, or overly specific or proprietary request formats needing to be supported by wallets or platforms.

The bar should be set fairly high for what formats the API supports.

Security

Following on from the above, passing arbitrary request content to wallets or the OS should be considered a non-starter. The community should work towards very well specified requests and response data structures for the API.

Privacy

This API has the potential to pull high-value government-issued certified credentials (drivers licenses, passports, etc.) from the browser - so the upmost care needs to be taken that credentials are never passed to unintended parties.

There is also making sure that each party involved cannot collude to reveal who is using what credential for what purpose (e.g., government shouldn't know which person purchased an age restricted item or accessed an age restricted website, although the credential may be required to purchase or access a particular service).

Venue

On parallel to incubation, the spec needs to find a home at the W3C somewhere.

[RByers]

Thanks Marcos. Perhaps it's worth noting that we (Chrome team) share almost all of those concerns.

The one place I think we disagree is around security. We believe that without the flexibility to control the format, issuers and wallets will just continue to rely on sending arbitrary data through other (less secure) means like custom schemes and/or their own network connection (eg. it's common for bank apps in Europe to just get a push notification initiated by a checkout flow on a web page). So we see this API more like the Web Share API as an API specifically for communicating arbitrary data to native apps in a way the user and user agent can at least reason about somewhat. While we consider the request to be "arbitrary", we do plan to tailor our security and privacy mitigations based on the contents of the request (not something we can do with the alternative when the request is flowing out-of-band).

Anyway, we should keep having this debate in the WICG group. I just wanted to note here for the record that it's an outstanding point of disagreement.

[marcoscaceres]

Update on Venue:
w3c/strategy#450

We also made strides on the OpenID / request format.

[marcoscaceres]

Recording that Mozilla's position is up - currently "negative".