LGTM2 On Tuesday, January 23, 2024 at 4:40:55 PM UTC+1 Rick Byers wrote:
> It would be great to get an official response from WebKit and Mozilla to > make sure we understand their position, but I don't think we should block > further on it. I understand why they might have concerns given their > engine's preference for embeds being anonymous. In Chromium we've been > consistent in working to preserve personalized / authenticated embeds (and > so the rich composition of web pages) where we can ensure it doesn't > conflict with our privacy goals around clear user transparency and control > over sharing of information (fenced frames > <https://developers.google.com/privacy-sandbox/relevance/fenced-frame> > being the most obvious example). We know that avoiding popups and redirects > helps reduce drop-off in any authentication or commerce flow, and combined > with Stripe's public statement of support, I'm convinced this is a valuable > capability. > > Everything else looks great to me, so LGTM1 > > On Tue, Jan 23, 2024 at 10:23 AM Stephen McGruer <smcgr...@chromium.org> > wrote: > >> Fyi; I've retargeted this launch to M123 since it seems clear it won't >> get the necessary Blink approvals in time for M122 (which has already >> branched). >> >> On Wednesday, January 17, 2024 at 11:07:56 AM UTC-5 Stephen McGruer wrote: >> >>> Sounds great: >>> >>> https://github.com/WebKit/standards-positions/issues/304 >>> https://github.com/mozilla/standards-positions/issues/964 >>> >>> Will update if we get any reply :) >>> >>> On Wed, 17 Jan 2024 at 10:25, Mike Taylor <miketa...@chromium.org> >>> wrote: >>> >>>> I think erring on the side of requesting a signal here is a good idea. >>>> :) >>>> On 1/17/24 8:33 AM, Stephen Mcgruer wrote: >>>> >>>> API owners: It wasn't clear to me if I should still be formally >>>> requesting signals from WebKit and Gecko in the case of a change to an API >>>> (WebAuthn) where the change has been ratified + landed by the associated >>>> Working Group. The change is in some ways 'minor', but in other ways it is >>>> significant new behavior (allowing use of part of the API in cross-origin >>>> iframes, where it wasn't allowed before) and so perhaps requesting signals >>>> is warranted? Let me know please :D >>>> >>>> On Wed, 17 Jan 2024 at 08:31, Stephen Mcgruer <smcgr...@chromium.org> >>>> wrote: >>>> >>>>> Contact emails smcgr...@chromium.org >>>>> >>>>> Explainer None >>>>> >>>>> 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 component Blink>WebAuthentication >>>>> <https://bugs.chromium.org/p/chromium/issues/list?q=component:Blink%3EWebAuthentication> >>>>> >>>>> TAG review None >>>>> >>>>> TAG review status Not applicable >>>>> >>>>> Risks >>>>> Interoperability and Compatibility >>>>> >>>>> There is only minor interoperability risk if other browsers do not >>>>> adopt this change. In a browser that does not support credential creation >>>>> inside a cross-origin iframe, attempting to call >>>>> navigator.credentials.create results in an asynchronous-but-immediate >>>>> error >>>>> message indicating that creation cannot happen. This means that a >>>>> developer >>>>> can create a fallback flow of: 1. Have some button for the user, e.g. >>>>> "register passkey", in the iframe 2. When the user clicks it, attempt to >>>>> create a credential 3. If it fails due to an incompatible browser, >>>>> instead >>>>> use the click to open a pop-up window in which one *can* do the >>>>> registration - a much poorer user flow but one that works. >>>>> >>>>> *Gecko*: No signal >>>>> >>>>> *WebKit*: No signal No formal signal, but note that folks from Apple >>>>> were against the proposal when discussed in the WebAuthn WG >>>>> >>>>> *Web developers*: Positive developer feedback on >>>>> https://github.com/w3c/webauthn/issues/1656 (one example - >>>>> https://github.com/w3c/webauthn/issues/1656#issuecomment-890819845). >>>>> No known negative developer feedback >>>>> >>>>> *Other signals*: >>>>> >>>>> Security >>>>> >>>>> To avoid malicious iframes from creating credentials (attempting to >>>>> trick the user in some way), this feature requires both (a) a new >>>>> permission policy set on the frame, and (b) a user gesture (so the user >>>>> must click or interact with the iframe in some way). >>>>> >>>>> 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 >>>>> >>>>> Existing devtools support suffices for this feature >>>>> >>>>> Will this feature be supported on all six Blink platforms (Windows, >>>>> Mac, Linux, ChromeOS, Android, and Android WebView)? Yes >>>>> >>>>> Is this feature fully tested by web-platform-tests >>>>> <https://chromium.googlesource.com/chromium/src/+/main/docs/testing/web_platform_tests.md> >>>>> ? Yes >>>>> >>>>> In review: https://github.com/web-platform-tests/wpt/pull/43729 >>>>> (Chrome Dev passes 5/5 added tests) >>>>> >>>>> Flag name on chrome://flags None >>>>> >>>>> Finch feature name WebAuthAllowCreateInCrossOriginFrame >>>>> >>>>> Requires code in //chrome? False >>>>> >>>>> Tracking bug >>>>> https://bugs.chromium.org/p/chromium/issues/detail?id=1420639 >>>>> >>>>> Estimated milestones >>>>> Shipping on desktop 122 >>>>> DevTrial on desktop 122 >>>>> Shipping on Android 122 >>>>> DevTrial on Android 122 >>>>> Anticipated spec changes >>>>> >>>>> Already landed in the spec, no remaining changes expected. >>>>> >>>>> Link to entry on the Chrome Platform Status >>>>> https://chromestatus.com/feature/5175677674586112 >>>>> >>>>> Links to previous Intent discussions Intent to prototype: >>>>> https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3Maf7EmNUH1zYSi7DimKd5NfddYY3navNx3-ELPyeqHpPMw%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/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%40mail.gmail.com >>>> >>>> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CADY3MaeX7OPn44HzmaTraBj%3DYEaosz4Y-aYdDr4Y%2BT7mkm9A0Q%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/b090cb3c-ac2a-4080-a583-6d77f60e5d79n%40chromium.org >> >> <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/b090cb3c-ac2a-4080-a583-6d77f60e5d79n%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/929be112-f30a-409d-a809-a2b7b9bd33a7n%40chromium.org.
