Intent to Experiment: Digital Credential API

[Rick Byers]

Hello blink-dev,

I'd like to request permission to start an OT for this API. There's still a lot to figure out in the larger space of digital credentials on the web, but with eIDAS regulation passing in the EU which requires large platforms like Google to accept such credentials before 2026, we believe it's urgent to start testing out better solutions in the wild and try to rapidly iterate on designs.

Thanks,

   Rick

Contact emails

rby...@chromium.org, go...@chromium.org

Explainer

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

Specification

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

Summary

Websites can and do get credentials from mobile wallet apps through a variety of mechanisms today (custom URL handlers, QR code scanning, etc.). This Web Platform feature would allow sites to request identity information from wallets via Android's IdentityCredential CredMan system. It is extensible to support multiple credential formats (eg. ISO mDoc and W3C verifiable credential) and allows multiple wallet apps to be used. Mechanisms are being added to help reduce the risks of ecosystem-scale abuse of real-world identity.

Blink component

Blink>Identity>DigitalCredentials

TAG review

Mozilla feedback from Martin (also on the TAG) suggests we need to invest more in the threat model for the larger space and clarify specific privacy mitigations before requesting TAG review. We are involved in ongoing work in the PING to analyze and provide guidelines for the larger space of digital credentials on the web.

TAG review status

Not started

Risks

Interoperability and Compatibility

There are multiple standards efforts involved here. We have been working with WebKit and Mozilla in the WICG on defining this specific API. But the greater interoperability risk will come from the data that is sent and returned via this API. Details of that are still in discussions but mostly driven outside the web browser community in the OpenID Foundation (eg. OpenID4VP: https://openid.net/specs/openid-4-verifiable-presentations-1_0.html) and ISO (18013-7 "mdoc": https://www.iso.org/standard/82772.html)

Gecko: Negative (https://github.com/mozilla/standards-positions/issues/1003) We share most of Mozilla's concerns and continue to work with them (and the broader community) on mitigations. I believe we feel greater risk for the established practice of custom schemes becoming prevalent than Mozilla does (eg. due to Google being mandated by eIDAS regulation to accept EUDI credentials by 2026).

WebKit: In development (https://github.com/WebKit/standards-positions/issues/332) WebKit implementation progress: https://bugs.webkit.org/show_bug.cgi?id=268516

Web developers: No signals

Other signals: This work in the W3C PING is relevant: https://github.com/w3cping/credential-considerations/

Ergonomics

There's a possibility that these credentials will be used alongside other types of credentials in the future - such as optionally minting a passkey when a digital credential is used to sign up for a site, or by allowing sign-up with either a digital credential or a federated credential via FedCM. As such we argued it was best to put this work in the context of the Credential Management API. However there's also a compelling argument that identity claims are much more than "credentials" and should evoke different developer expectations. The agreed upon compromise was to add a new credential container at 'navigator.identity'.

Activation

The primary activation concern is enabling existing deployments using technology like OpenID4VP to be able to also support this API. As such we have left the request protocol unspecified at this layer, to be specified along with existing request protocols to maximize activation opportunity.

Security

See https://github.com/WICG/digital-credentials/blob/main/horizontal-reviews/security-privacy.md and https://github.com/WICG/digital-credentials/issues/115

WebView application risks

No

Goals for experimentation

We want to gather initial feedback from production usage of end-to-end scenarios involving at least one wallet and at least one real-world verifier website (partners committed but not yet disclosed publicly).

We will be looking to the verifier for feedback on usability. Eg. does a  "use my digital wallet" button work OK in practice even when few users have such a credential? To what extent do users report feeling more comfortable sing selective disclosure of their age as compared to providing a photo of their driver's license?

Ongoing technical constraints

None

Debuggability

None necessary - just new JS API. For testing we may want to add a developer option to provide a fake wallet (as for the devtools fake authenticator for WebAuthn), but this is not urgent.

Will this feature be supported on all six Blink platforms (Windows, Mac, Linux, ChromeOS, Android, and Android WebView)?

No

Android only initially due to the nature of communicating with Android wallet apps. We will be creating another feature soon for "cross-device presentment" which will use the identical API on desktop, but will have a separate intent for that.

Is this feature fully tested by web-platform-tests?

We have initial tests here: 

https://wpt.fyi/results/credential-management/digital-identity.https.html?label=experimental&label=master&aligned

DevTrial instructions

https://github.com/WICG/digital-identities/wiki/HOWTO%3A-Try-the-Prototype-API-in-Chrome-Android

Flag name on chrome://flags

web-identity-digital-credentials

Finch feature name

WebIdentityDigitalCredentials

Requires code in //chrome?

True

Tracking bug

https://issues.chromium.org/issues/40257092

Launch bug

https://launch.corp.google.com/launch/4268575

Estimated milestones

OriginTrial Android last	134
OriginTrial Android first	128
DevTrial on Android	119

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5166035265650688?gate=4923904445906944

Links to previous Intent discussions

Intent to prototype: https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAL9PXLx3sHWmdE-ikAEDay_S3ijf0%2BfxB_LbsuOx8YJx%2BZA7%2Bg%40mail.gmail.com

This intent message was generated by Chrome Platform Status.

[Mike Taylor]

LGTM to experiment for 6 milestones from M128 to M133 inclusive.

--
You received this message because you are subscribed to the Google Groups "blink-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blink-dev+...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_t3qqjJ_SpuyXvStGiN9qvKSn4w%2BC2nEbR2tRbwHKm_g%40mail.gmail.com.

[Alex Russell]

It would be good to see a more thorough considered alternatives section in the explainer. It's not immediately clear what (in code) the alternatives would entail.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ff9c35f-71b0-4a88-a5ad-023664df88ad%40chromium.org.

[Rick Byers]

On Mon, Jun 24, 2024 at 12:02 PM Alex Russell <sligh...@chromium.org> wrote:

It would be good to see a more thorough considered alternatives section in the explainer. It's not immediately clear what (in code) the alternatives would entail.

Sure, we could do that. I filed this issue and left some questions for you there to better understand what you're looking for (beyond all the alternative proposals I've already linked to for details).