On Mon, Jun 24, 2024 at 12:02 PM Alex Russell <slightly...@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
<https://github.com/WICG/digital-credentials/issues/135> 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).


> On Mon, Jun 24, 2024, 7:28 AM Mike Taylor <miketa...@chromium.org> wrote:
>
>> LGTM to experiment for 6 milestones from M128 to M133 inclusive.
>> On 6/22/24 1:44 PM, Rick Byers wrote:
>>
>> 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
>> <https://docs.google.com/presentation/d/1Z7blMTME1tAQAdO-Wr42oVNN3CRIbklASjbJdB1JYOc/edit?resourcekey=0-ockU2NbemVbLEeF94-peNA#slide=id.p>,
>> but with eIDAS
>> <https://www.identity.com/eidas-2-0-redefining-digital-identity-in-the-eu/#What_Are_the_Objectives_of_eIDAS_20>
>> 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, g...@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
>> <https://docs.google.com/document/u/1/d/1L68tmNXCQXucsCV8eS8CBd_F9FZ6TNwKNOaFkA8RfwI/edit>
>> are being added to help reduce the risks
>> <https://github.com/w3cping/credential-considerations/> of
>> ecosystem-scale abuse of real-world identity.
>>
>> Blink component Blink>Identity>DigitalCredentials
>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EIdentity%3EDigitalCredentials>
>>
>> TAG review Mozilla feedback
>> <https://github.com/mozilla/standards-positions/issues/1003> 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
>> <https://github.com/w3cping/credential-considerations/> 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
>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md>
>> ? 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
>> <https://chromestatus.com/>.
>> --
>> 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+unsubscr...@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
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY_t3qqjJ_SpuyXvStGiN9qvKSn4w%2BC2nEbR2tRbwHKm_g%40mail.gmail.com?utm_medium=email&utm_source=footer>
>> .
>>
>> --
>> 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+unsubscr...@chromium.org.
>> 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
>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/3ff9c35f-71b0-4a88-a5ad-023664df88ad%40chromium.org?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
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+unsubscr...@chromium.org.
To view this discussion on the web visit 
https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAFUtAY-421uDmu2WNDBG5bYRSWAhfmahsHPVjDwN5NLkUdCkvw%40mail.gmail.com.

Reply via email to