Note FedCM, PaymentRequest and Storage access API effectively all follow this policy too. 3PCD doesn't block cross-origin information sharing, it just requires user consent (and hopefully understanding) for doing so. These patterns all seem strictly stronger in terms of transparency and control than eg. the widespread behavior around popup windows and redirects which are the main way federated sign-in is still done on the web without 3PCs.
On Thu, Nov 9, 2023, 11:48 a.m. Stephen Mcgruer <smcgr...@chromium.org> wrote: > To clarify - WebAuthn credentials are already available for reading in a > cross-origin iframe, as long the "publickey-credentials-get" permission > policy is set. So the question probably stands for WebAuthn in general, > rather than just this change to allow creation as well? > > I'm cc-ing agl@ as the expert here, but my understanding is that WebAuthn > credentials (aka passkeys) are unpartitioned, but require sufficient user > interaction/consent that they are considered compatible with the > deprecation of third-party cookies and unpartitioned storage. A frame on > origin A embedded under origin B can request (via credentials.get()) its > unpartitioned passkey, but the user will at minimum* see and have to > confirm a UI that indicates that they are identifying themselves to origin > A, and will usually have to interact with an authenticator flow (e.g., > TouchID, or a password prompt) as well. > > * At minimum because WebAuthn always requires something called 'user > presence' which might just have a UI where the user can click to confirm, > but almost always is used with the stronger 'user verification' which does > an authentication flow. > > On Thu, 9 Nov 2023 at 12:39, Reilly Grant <reil...@chromium.org> wrote: > >> Is this proposal compatible with the deprecation of third-party cookies >> and partitioned storage? Since credentials are origin-bound, what >> credentials are available to a frame on origin A embedded under origin B? >> Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome >> <https://www.google.com/chrome> >> >> >> On Wed, Nov 8, 2023 at 12:48 PM Stephen Mcgruer <smcgr...@chromium.org> >> wrote: >> >>> Contact emailssmcgr...@chromium.org >>> >>> ExplainerNone >>> >>> Specification >>> https://w3c.github.io/webauthn/#publickey-credentials-create-feature >>> >>> Summary >>> >>> This feature allows web developers to create WebAuthn[0] credentials >>> (that is, "publickey" credentials, aka passkeys) in cross-origin iframes. >>> Two conditions are required for this new ability: 1. The iframe has a >>> publickey-credentials-create-feature permission policy. 2. The iframe has >>> transient user activation. This will allow developers to create passkeys in >>> embedded scenarios, such as after an identity step-up flow where the >>> Relying Party is providing a federated identity experience. [0]: >>> https://w3c.github.io/webauthn/ >>> >>> Blink componentBlink>WebAuthentication >>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication> >>> >>> >>> TAG reviewNone >>> >>> TAG review statusNot applicable >>> >>> Risks >>> >>> Interoperability and Compatibility >>> >>> None >>> >>> *Gecko*: No signal >>> >>> *WebKit*: No signal >>> >>> *Web developers*: No signals >>> >>> *Other signals*: >>> >>> WebView application risks >>> >>> Does this intent deprecate or change behavior of existing APIs, such >>> that it has potentially high risk for Android WebView-based applications? >>> >>> None >>> >>> Debuggability >>> >>> Will be debuggable by usual devtools tooling for JavaScript. >>> >>> >>> Is this feature fully tested by web-platform-tests >>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>> ?N/A (Not yet implemented) >>> >>> Flag name on chrome://flagsNone >>> >>> Finch feature nameNone >>> >>> Non-finch justificationNone >>> >>> Requires code in //chrome?False >>> >>> Estimated milestones >>> >>> No milestones specified >>> >>> >>> Link to entry on the Chrome Platform Status >>> https://chromestatus.com/feature/5175677674586112 >>> >>> -- >>> 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/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%40mail.gmail.com >>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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/CADY3Mae12e1MvWouhD5qZRCQsRaG_h_bXjC%2B0yeUfB4uHX4xww%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Mae12e1MvWouhD5qZRCQsRaG_h_bXjC%2B0yeUfB4uHX4xww%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/CAFUtAY9sKv%3Dd1N9VDWXwsLumhhnHSXPOsWVbCGnFmvxFjVB9mg%40mail.gmail.com.
