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/25046dc9-36e2-48af-b0ad-30da79ec9141%40chromium.org.

Reply via email to