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/CADY3MaeV%3DnZ2ThU_Qi%3D%3DeVx8vvu_ACzEm5drNukrKYsWYVRnxg%40mail.gmail.com.
