That all makes sense to me. I was just hoping to find it explained somewhere. Reilly Grant | Software Engineer | reil...@chromium.org | Google Chrome <https://www.google.com/chrome>
On Sat, Nov 11, 2023 at 12:16 PM Rick Byers <rby...@chromium.org> wrote: > 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/CAEmk%3DMY6UzyT-Ec3na6DLjY9MaZ1%2BQcuh9hNxV0MsFEoL2eBJg%40mail.gmail.com.
