Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Mike Taylor]

LGTM3

On 1/24/24 11:24 AM, Yoav Weiss (@Shopify) wrote:

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

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
 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
 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
 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




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

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Yoav Weiss (@Shopify)]

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 
>  
> 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  
> 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  
>>> 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  
 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 
> 
>
> 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 

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Rick Byers]

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

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 
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  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 
>>> 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
 

 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 

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen McGruer]

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  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  
>> 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 
>>> 
>>>
>>> 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 
>>> 
>>> ? 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: 
>>> 

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Stephen Mcgruer]

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  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 
> 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
>> 
>>
>> 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
>> 
>> ? 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
>> .
>>
> --
> 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 

Re: [blink-dev] Re: Intent to Ship: Allow for WebAuthn credential creation in a cross-origin iframe

[Mike Taylor]

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  
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




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

?

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
.

--
You received this message because you are subscribed to the Google 
Groups "blink-dev" group.