Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Mike Taylor]

Sounds good - no concerns with shifting the milestones.

On 5/16/24 11:53 AM, Nicolás Peña Moreno wrote:
We decided to further delay the start of the OT since our partner 
needs more time before they can put it in front of real users, so the 
current plan it to do the experiment on milestones 128 - 132.


On Tuesday, April 23, 2024 at 4:01:15 PM UTC-4 Nicolás Peña Moreno wrote:

I sent this intent before the feature was ready, and this required
a lot of UX work, so trial has not started. Our plan is to start
on Chrome M126 so I will assume the approvals are shifted to 126 -
130. If there are concerns let me know, thanks!

On Tuesday, February 27, 2024 at 3:04:38 PM UTC-5 Yoav Weiss wrote:

LGTM to experiment M124-M128 inclusive

On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña
 wrote:

Done

On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike
Taylor wrote:

Could you please request reviews for the
privacy/security/debuggability review gates in your
chromestatus entry?

On 2/21/24 3:21 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

The Federated Credential Management (FedCM) API
currently only allows one identity provider (IDP) to
be used when performing federated login in a website.
We would like to experiment with allowing multiple
providers to be specified in a single JavaScript
get() call, which allows FedCM to be used in cases
for which the website supports multiple IDPs for
federation. See also additional context in
https://github.com/fedidcg/FedCM/issues/319
.


Specification

https://fedidcg.github.io/FedCM



Summary

Allows FedCM to show multiple IDPs in the same
dialog. This provides developers with a convenient
way to present all supported identity providers to
users. In this I2E, we are tackling the simple case
of having all providers in the same get() call, while
building much of the UX infratructure that will allow
us to tackle more sophisticated production structures
later.



Blink component

Blink>Identity>FedCM




TAG review

https://github.com/w3ctag/design-reviews/issues/803



TAG review status

Pending


Risks

Interoperability and Compatibility

This should not have additional interop risks on top
of the existing FedCM API which is generally
supported but not yet implemented by Firefox and
Safari. In order to determine whether multiple IDPs
are supported in a browser which supports FedCM, the
developer can attempt to first call get() with
multiple IDPs. It will be rejected immediately if not
supported and the RP can retry with a single IDP.



Gecko: No signal
(https://github.com/mozilla/standards-positions/issues/730
)


WebKit: No signal
(https://github.com/WebKit/standards-positions/issues/120
)


Web developers: Positive
(https://github.com/fedidcg/FedCM/issues/319
)


Other signals:


Ergonomics

Using this API will just require expanding the get()
to use more providers, so it will benefit from the
ergonomics of the initial FedCM API.



Activation

The main activation issue is having to include all
IDPs in the same get() call, which may be challenging
in some cases because IDPs generally are independent
from each other. That said, we do have developers who
can use the single get() call, so we wish to start
with the simpler version of multi IDP support.



Security

The security considerations are similar to those of
the single IDP case. We do not require users to input

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

['Nicolás Peña Moreno' via blink-dev]

We decided to further delay the start of the OT since our partner needs 
more time before they can put it in front of real users, so the current 
plan it to do the experiment on milestones 128 - 132. 

On Tuesday, April 23, 2024 at 4:01:15 PM UTC-4 Nicolás Peña Moreno wrote:

> I sent this intent before the feature was ready, and this required a lot 
> of UX work, so trial has not started. Our plan is to start on Chrome M126 
> so I will assume the approvals are shifted to 126 - 130. If there are 
> concerns let me know, thanks!
>
> On Tuesday, February 27, 2024 at 3:04:38 PM UTC-5 Yoav Weiss wrote:
>
>> LGTM to experiment M124-M128 inclusive
>>
>> On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña  wrote:
>>
>>> Done
>>>
>>> On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote:
>>>
>> Could you please request reviews for the privacy/security/debuggability 
 review gates in your chromestatus entry?
 On 2/21/24 3:21 PM, Nicolás Peña wrote:

 Contact emails 

 n...@chromium.org

 Explainer 

 The Federated Credential Management (FedCM) API currently only allows 
 one identity provider (IDP) to be used when performing federated login in 
 a 
 website. We would like to experiment with allowing multiple providers to 
 be 
 specified in a single JavaScript get() call, which allows FedCM to be used 
 in cases for which the website supports multiple IDPs for federation. See 
 also additional context in https://github.com/fedidcg/FedCM/issues/319.

 Specification 

 https://fedidcg.github.io/FedCM

 Summary 

 Allows FedCM to show multiple IDPs in the same dialog. This provides 
 developers with a convenient way to present all supported identity 
 providers to users. In this I2E, we are tackling the simple case of having 
 all providers in the same get() call, while building much of the UX 
 infratructure that will allow us to tackle more sophisticated production 
 structures later.


 Blink component 

 Blink>Identity>FedCM 
 

 TAG review 

 https://github.com/w3ctag/design-reviews/issues/803

 TAG review status 

 Pending

 Risks

 Interoperability and Compatibility 

 This should not have additional interop risks on top of the existing 
 FedCM API which is generally supported but not yet implemented by Firefox 
 and Safari. In order to determine whether multiple IDPs are supported in a 
 browser which supports FedCM, the developer can attempt to first call 
 get() 
 with multiple IDPs. It will be rejected immediately if not supported and 
 the RP can retry with a single IDP.


 Gecko: No signal (
 https://github.com/mozilla/standards-positions/issues/730)

 WebKit: No signal (
 https://github.com/WebKit/standards-positions/issues/120)

 Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)

 Other signals:

 Ergonomics 

 Using this API will just require expanding the get() to use more 
 providers, so it will benefit from the ergonomics of the initial FedCM API.


 Activation 

 The main activation issue is having to include all IDPs in the same 
 get() call, which may be challenging in some cases because IDPs generally 
 are independent from each other. That said, we do have developers who can 
 use the single get() call, so we wish to start with the simpler version of 
 multi IDP support.


 Security 

 The security considerations are similar to those of the single IDP 
 case. We do not require users to input usernames and passwords due to 
 spoofing concerns, and we also have input protection to prevent accidental 
 click right after the UI is shown.


 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?

 n/a, FedCM is not supported on WebView


 Goals for experimentation 

 We want to ensure that the single get() call is sufficient for the use 
 cases we are targeting, where the multiple IDPs are owned by a single 
 entity, as well as gather developer feedback before fully shipping. The 
 multiple independent IDPs scenario is out of scope for experimentation, as 
 we anticipate that it will be hard to impossible to use FedCM in a single 
 get() call in such a scenario.

 A successful trial would result in our partner requesting us to ship 
 this feature to allow using FedCM with their multiple IDPs.

 Ongoing technical constraints 

 None


 Debuggability 

 The debug tools are similar to that of original 

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

['Nicolás Peña Moreno' via blink-dev]

I sent this intent before the feature was ready, and this required a lot of 
UX work, so trial has not started. Our plan is to start on Chrome M126 so I 
will assume the approvals are shifted to 126 - 130. If there are concerns 
let me know, thanks!

On Tuesday, February 27, 2024 at 3:04:38 PM UTC-5 Yoav Weiss wrote:

> LGTM to experiment M124-M128 inclusive
>
> On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña  wrote:
>
>> Done
>>
>> On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote:
>>
> Could you please request reviews for the privacy/security/debuggability 
>>> review gates in your chromestatus entry?
>>> On 2/21/24 3:21 PM, Nicolás Peña wrote:
>>>
>>> Contact emails 
>>>
>>> n...@chromium.org
>>>
>>> Explainer 
>>>
>>> The Federated Credential Management (FedCM) API currently only allows 
>>> one identity provider (IDP) to be used when performing federated login in a 
>>> website. We would like to experiment with allowing multiple providers to be 
>>> specified in a single JavaScript get() call, which allows FedCM to be used 
>>> in cases for which the website supports multiple IDPs for federation. See 
>>> also additional context in https://github.com/fedidcg/FedCM/issues/319.
>>>
>>> Specification 
>>>
>>> https://fedidcg.github.io/FedCM
>>>
>>> Summary 
>>>
>>> Allows FedCM to show multiple IDPs in the same dialog. This provides 
>>> developers with a convenient way to present all supported identity 
>>> providers to users. In this I2E, we are tackling the simple case of having 
>>> all providers in the same get() call, while building much of the UX 
>>> infratructure that will allow us to tackle more sophisticated production 
>>> structures later.
>>>
>>>
>>> Blink component 
>>>
>>> Blink>Identity>FedCM 
>>> 
>>>
>>> TAG review 
>>>
>>> https://github.com/w3ctag/design-reviews/issues/803
>>>
>>> TAG review status 
>>>
>>> Pending
>>>
>>> Risks
>>>
>>> Interoperability and Compatibility 
>>>
>>> This should not have additional interop risks on top of the existing 
>>> FedCM API which is generally supported but not yet implemented by Firefox 
>>> and Safari. In order to determine whether multiple IDPs are supported in a 
>>> browser which supports FedCM, the developer can attempt to first call get() 
>>> with multiple IDPs. It will be rejected immediately if not supported and 
>>> the RP can retry with a single IDP.
>>>
>>>
>>> Gecko: No signal (
>>> https://github.com/mozilla/standards-positions/issues/730)
>>>
>>> WebKit: No signal (
>>> https://github.com/WebKit/standards-positions/issues/120)
>>>
>>> Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)
>>>
>>> Other signals:
>>>
>>> Ergonomics 
>>>
>>> Using this API will just require expanding the get() to use more 
>>> providers, so it will benefit from the ergonomics of the initial FedCM API.
>>>
>>>
>>> Activation 
>>>
>>> The main activation issue is having to include all IDPs in the same 
>>> get() call, which may be challenging in some cases because IDPs generally 
>>> are independent from each other. That said, we do have developers who can 
>>> use the single get() call, so we wish to start with the simpler version of 
>>> multi IDP support.
>>>
>>>
>>> Security 
>>>
>>> The security considerations are similar to those of the single IDP case. 
>>> We do not require users to input usernames and passwords due to spoofing 
>>> concerns, and we also have input protection to prevent accidental click 
>>> right after the UI is shown.
>>>
>>>
>>> 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?
>>>
>>> n/a, FedCM is not supported on WebView
>>>
>>>
>>> Goals for experimentation 
>>>
>>> We want to ensure that the single get() call is sufficient for the use 
>>> cases we are targeting, where the multiple IDPs are owned by a single 
>>> entity, as well as gather developer feedback before fully shipping. The 
>>> multiple independent IDPs scenario is out of scope for experimentation, as 
>>> we anticipate that it will be hard to impossible to use FedCM in a single 
>>> get() call in such a scenario.
>>>
>>> A successful trial would result in our partner requesting us to ship 
>>> this feature to allow using FedCM with their multiple IDPs.
>>>
>>> Ongoing technical constraints 
>>>
>>> None
>>>
>>>
>>> Debuggability 
>>>
>>> The debug tools are similar to that of original FedCM: console messages 
>>> and DevTools issues. Seeing FedCM network requests is not supported in 
>>> DevTools but can be achieved via chrome://net-export.
>>>
>>>
>>> Will this feature be supported on all six Blink platforms (Windows, Mac, 
>>> Linux, ChromeOS, Android, and Android WebView)? 
>>>
>>> No
>>>
>>> As with the initial FedCM, we do not support Android WebView.
>>>
>>>
>>> Is this feature fully tested by 

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Yoav Weiss (@Shopify)]

LGTM to experiment M124-M128 inclusive

On Tue, Feb 27, 2024 at 4:16 PM Nicolás Peña  wrote:

> Done
>
> On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote:
>
>> Could you please request reviews for the privacy/security/debuggability
>> review gates in your chromestatus entry?
>> On 2/21/24 3:21 PM, Nicolás Peña wrote:
>>
>> Contact emails
>>
>> n...@chromium.org
>>
>> Explainer
>>
>> The Federated Credential Management (FedCM) API currently only allows one
>> identity provider (IDP) to be used when performing federated login in a
>> website. We would like to experiment with allowing multiple providers to be
>> specified in a single JavaScript get() call, which allows FedCM to be used
>> in cases for which the website supports multiple IDPs for federation. See
>> also additional context in https://github.com/fedidcg/FedCM/issues/319.
>>
>> Specification
>>
>> https://fedidcg.github.io/FedCM
>>
>> Summary
>>
>> Allows FedCM to show multiple IDPs in the same dialog. This provides
>> developers with a convenient way to present all supported identity
>> providers to users. In this I2E, we are tackling the simple case of having
>> all providers in the same get() call, while building much of the UX
>> infratructure that will allow us to tackle more sophisticated production
>> structures later.
>>
>>
>> Blink component
>>
>> Blink>Identity>FedCM
>> 
>>
>> TAG review
>>
>> https://github.com/w3ctag/design-reviews/issues/803
>>
>> TAG review status
>>
>> Pending
>>
>> Risks
>>
>> Interoperability and Compatibility
>>
>> This should not have additional interop risks on top of the existing
>> FedCM API which is generally supported but not yet implemented by Firefox
>> and Safari. In order to determine whether multiple IDPs are supported in a
>> browser which supports FedCM, the developer can attempt to first call get()
>> with multiple IDPs. It will be rejected immediately if not supported and
>> the RP can retry with a single IDP.
>>
>>
>> Gecko: No signal (
>> https://github.com/mozilla/standards-positions/issues/730)
>>
>> WebKit: No signal (
>> https://github.com/WebKit/standards-positions/issues/120)
>>
>> Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)
>>
>> Other signals:
>>
>> Ergonomics
>>
>> Using this API will just require expanding the get() to use more
>> providers, so it will benefit from the ergonomics of the initial FedCM API.
>>
>>
>> Activation
>>
>> The main activation issue is having to include all IDPs in the same get()
>> call, which may be challenging in some cases because IDPs generally are
>> independent from each other. That said, we do have developers who can use
>> the single get() call, so we wish to start with the simpler version of
>> multi IDP support.
>>
>>
>> Security
>>
>> The security considerations are similar to those of the single IDP case.
>> We do not require users to input usernames and passwords due to spoofing
>> concerns, and we also have input protection to prevent accidental click
>> right after the UI is shown.
>>
>>
>> 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?
>>
>> n/a, FedCM is not supported on WebView
>>
>>
>> Goals for experimentation
>>
>> We want to ensure that the single get() call is sufficient for the use
>> cases we are targeting, where the multiple IDPs are owned by a single
>> entity, as well as gather developer feedback before fully shipping. The
>> multiple independent IDPs scenario is out of scope for experimentation, as
>> we anticipate that it will be hard to impossible to use FedCM in a single
>> get() call in such a scenario.
>>
>> A successful trial would result in our partner requesting us to ship this
>> feature to allow using FedCM with their multiple IDPs.
>>
>> Ongoing technical constraints
>>
>> None
>>
>>
>> Debuggability
>>
>> The debug tools are similar to that of original FedCM: console messages
>> and DevTools issues. Seeing FedCM network requests is not supported in
>> DevTools but can be achieved via chrome://net-export.
>>
>>
>> Will this feature be supported on all six Blink platforms (Windows, Mac,
>> Linux, ChromeOS, Android, and Android WebView)?
>>
>> No
>>
>> As with the initial FedCM, we do not support Android WebView.
>>
>>
>> Is this feature fully tested by web-platform-tests
>> 
>> ?
>>
>> Yes
>>
>>
>> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/
>> Some of these tests are not relevant as they are related to the multi-get()
>> approach.
>>
>>
>> Flag name on chrome://flags
>>
>> FedCmMultiIdp
>>
>> Finch feature name
>>
>> FedCmMultipleIdentityProviders
>>
>> Requires code in //chrome?
>>

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Nicolás Peña]

Done

On Monday, February 26, 2024 at 7:55:09 PM UTC-5 Mike Taylor wrote:

> Could you please request reviews for the privacy/security/debuggability 
> review gates in your chromestatus entry?
> On 2/21/24 3:21 PM, Nicolás Peña wrote:
>
> Contact emails 
>
> n...@chromium.org
>
> Explainer 
>
> The Federated Credential Management (FedCM) API currently only allows one 
> identity provider (IDP) to be used when performing federated login in a 
> website. We would like to experiment with allowing multiple providers to be 
> specified in a single JavaScript get() call, which allows FedCM to be used 
> in cases for which the website supports multiple IDPs for federation. See 
> also additional context in https://github.com/fedidcg/FedCM/issues/319.
>
> Specification 
>
> https://fedidcg.github.io/FedCM
>
> Summary 
>
> Allows FedCM to show multiple IDPs in the same dialog. This provides 
> developers with a convenient way to present all supported identity 
> providers to users. In this I2E, we are tackling the simple case of having 
> all providers in the same get() call, while building much of the UX 
> infratructure that will allow us to tackle more sophisticated production 
> structures later.
>
>
> Blink component 
>
> Blink>Identity>FedCM 
> 
>
> TAG review 
>
> https://github.com/w3ctag/design-reviews/issues/803
>
> TAG review status 
>
> Pending
>
> Risks
>
> Interoperability and Compatibility 
>
> This should not have additional interop risks on top of the existing FedCM 
> API which is generally supported but not yet implemented by Firefox and 
> Safari. In order to determine whether multiple IDPs are supported in a 
> browser which supports FedCM, the developer can attempt to first call get() 
> with multiple IDPs. It will be rejected immediately if not supported and 
> the RP can retry with a single IDP.
>
>
> Gecko: No signal (
> https://github.com/mozilla/standards-positions/issues/730)
>
> WebKit: No signal (
> https://github.com/WebKit/standards-positions/issues/120)
>
> Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)
>
> Other signals:
>
> Ergonomics 
>
> Using this API will just require expanding the get() to use more 
> providers, so it will benefit from the ergonomics of the initial FedCM API.
>
>
> Activation 
>
> The main activation issue is having to include all IDPs in the same get() 
> call, which may be challenging in some cases because IDPs generally are 
> independent from each other. That said, we do have developers who can use 
> the single get() call, so we wish to start with the simpler version of 
> multi IDP support.
>
>
> Security 
>
> The security considerations are similar to those of the single IDP case. 
> We do not require users to input usernames and passwords due to spoofing 
> concerns, and we also have input protection to prevent accidental click 
> right after the UI is shown.
>
>
> 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?
>
> n/a, FedCM is not supported on WebView
>
>
> Goals for experimentation 
>
> We want to ensure that the single get() call is sufficient for the use 
> cases we are targeting, where the multiple IDPs are owned by a single 
> entity, as well as gather developer feedback before fully shipping. The 
> multiple independent IDPs scenario is out of scope for experimentation, as 
> we anticipate that it will be hard to impossible to use FedCM in a single 
> get() call in such a scenario.
>
> A successful trial would result in our partner requesting us to ship this 
> feature to allow using FedCM with their multiple IDPs.
>
> Ongoing technical constraints 
>
> None
>
>
> Debuggability 
>
> The debug tools are similar to that of original FedCM: console messages 
> and DevTools issues. Seeing FedCM network requests is not supported in 
> DevTools but can be achieved via chrome://net-export.
>
>
> Will this feature be supported on all six Blink platforms (Windows, Mac, 
> Linux, ChromeOS, Android, and Android WebView)? 
>
> No
>
> As with the initial FedCM, we do not support Android WebView.
>
>
> Is this feature fully tested by web-platform-tests 
> 
> ? 
>
> Yes
>
>
> https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/
>  
> Some of these tests are not relevant as they are related to the multi-get() 
> approach.
>
>
> Flag name on chrome://flags 
>
> FedCmMultiIdp
>
> Finch feature name 
>
> FedCmMultipleIdentityProviders
>
> Requires code in //chrome? 
>
> True
>
> Tracking bug 
>
> https://bugs.chromium.org/p/chromium/issues/detail?id=1348262
>
> Launch bug 
>
> https://launch.corp.google.com/launch/4229762
>
> Estimated milestones 
>
> 

Re: [blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Mike Taylor]

Could you please request reviews for the privacy/security/debuggability 
review gates in your chromestatus entry?


On 2/21/24 3:21 PM, Nicolás Peña wrote:

Contact emails

n...@chromium.org


Explainer

The Federated Credential Management (FedCM) API currently only allows 
one identity provider (IDP) to be used when performing federated login 
in a website. We would like to experiment with allowing multiple 
providers to be specified in a single JavaScript get() call, which 
allows FedCM to be used in cases for which the website supports 
multiple IDPs for federation. See also additional context in 
https://github.com/fedidcg/FedCM/issues/319 
.



Specification

https://fedidcg.github.io/FedCM 


Summary

Allows FedCM to show multiple IDPs in the same dialog. This provides 
developers with a convenient way to present all supported identity 
providers to users. In this I2E, we are tackling the simple case of 
having all providers in the same get() call, while building much of 
the UX infratructure that will allow us to tackle more sophisticated 
production structures later.




Blink component

Blink>Identity>FedCM 




TAG review

https://github.com/w3ctag/design-reviews/issues/803 




TAG review status

Pending


Risks

Interoperability and Compatibility

This should not have additional interop risks on top of the existing 
FedCM API which is generally supported but not yet implemented by 
Firefox and Safari. In order to determine whether multiple IDPs are 
supported in a browser which supports FedCM, the developer can attempt 
to first call get() with multiple IDPs. It will be rejected 
immediately if not supported and the RP can retry with a single IDP.




Gecko: No signal 
(https://github.com/mozilla/standards-positions/issues/730 
)



WebKit: No signal 
(https://github.com/WebKit/standards-positions/issues/120 
)



Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319 
)



Other signals:


Ergonomics

Using this API will just require expanding the get() to use more 
providers, so it will benefit from the ergonomics of the initial FedCM 
API.




Activation

The main activation issue is having to include all IDPs in the same 
get() call, which may be challenging in some cases because IDPs 
generally are independent from each other. That said, we do have 
developers who can use the single get() call, so we wish to start with 
the simpler version of multi IDP support.




Security

The security considerations are similar to those of the single IDP 
case. We do not require users to input usernames and passwords due to 
spoofing concerns, and we also have input protection to prevent 
accidental click right after the UI is shown.




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?


n/a, FedCM is not supported on WebView



Goals for experimentation

We want to ensure that the single get() call is sufficient for the use 
cases we are targeting, where the multiple IDPs are owned by a single 
entity, as well as gather developer feedback before fully shipping. 
The multiple independent IDPs scenario is out of scope for 
experimentation, as we anticipate that it will be hard to impossible 
to use FedCM in a single get() call in such a scenario.



A successful trial would result in our partner requesting us to ship 
this feature to allow using FedCM with their multiple IDPs.



Ongoing technical constraints

None



Debuggability

The debug tools are similar to that of original FedCM: console 
messages and DevTools issues. Seeing FedCM network requests is not 
supported in DevTools but can be achieved via chrome://net-export.




Will this feature be supported on all six Blink platforms (Windows, 
Mac, Linux, ChromeOS, Android, and Android WebView)?


No

As with the initial FedCM, we do not support Android WebView.



Is this feature fully tested by web-platform-tests 
? 



Yes

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/ 
Some 
of these tests are not relevant as they are related to the multi-get() 
approach.




Flag name on chrome://flags

FedCmMultiIdp


Finch feature name

FedCmMultipleIdentityProviders


Requires code in //chrome?

True


Tracking bug

[blink-dev] Intent to Experiment: FedCM multi IDP in single get() call

[Nicolás Peña]

Contact emails

n...@chromium.org

Explainer

The Federated Credential Management (FedCM) API currently only allows one 
identity provider (IDP) to be used when performing federated login in a 
website. We would like to experiment with allowing multiple providers to be 
specified in a single JavaScript get() call, which allows FedCM to be used 
in cases for which the website supports multiple IDPs for federation. See 
also additional context in https://github.com/fedidcg/FedCM/issues/319.

Specification

https://fedidcg.github.io/FedCM

Summary

Allows FedCM to show multiple IDPs in the same dialog. This provides 
developers with a convenient way to present all supported identity 
providers to users. In this I2E, we are tackling the simple case of having 
all providers in the same get() call, while building much of the UX 
infratructure that will allow us to tackle more sophisticated production 
structures later.


Blink component

Blink>Identity>FedCM 


TAG review

https://github.com/w3ctag/design-reviews/issues/803

TAG review status

Pending

Risks

Interoperability and Compatibility

This should not have additional interop risks on top of the existing FedCM 
API which is generally supported but not yet implemented by Firefox and 
Safari. In order to determine whether multiple IDPs are supported in a 
browser which supports FedCM, the developer can attempt to first call get() 
with multiple IDPs. It will be rejected immediately if not supported and 
the RP can retry with a single IDP.


Gecko: No signal (https://github.com/mozilla/standards-positions/issues/730)

WebKit: No signal (https://github.com/WebKit/standards-positions/issues/120)

Web developers: Positive (https://github.com/fedidcg/FedCM/issues/319)

Other signals:

Ergonomics

Using this API will just require expanding the get() to use more providers, 
so it will benefit from the ergonomics of the initial FedCM API.


Activation

The main activation issue is having to include all IDPs in the same get() 
call, which may be challenging in some cases because IDPs generally are 
independent from each other. That said, we do have developers who can use 
the single get() call, so we wish to start with the simpler version of 
multi IDP support.


Security

The security considerations are similar to those of the single IDP case. We 
do not require users to input usernames and passwords due to spoofing 
concerns, and we also have input protection to prevent accidental click 
right after the UI is shown.


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?

n/a, FedCM is not supported on WebView


Goals for experimentation

We want to ensure that the single get() call is sufficient for the use 
cases we are targeting, where the multiple IDPs are owned by a single 
entity, as well as gather developer feedback before fully shipping. The 
multiple independent IDPs scenario is out of scope for experimentation, as 
we anticipate that it will be hard to impossible to use FedCM in a single 
get() call in such a scenario.

A successful trial would result in our partner requesting us to ship this 
feature to allow using FedCM with their multiple IDPs.

Ongoing technical constraints

None


Debuggability

The debug tools are similar to that of original FedCM: console messages and 
DevTools issues. Seeing FedCM network requests is not supported in DevTools 
but can be achieved via chrome://net-export.


Will this feature be supported on all six Blink platforms (Windows, Mac, 
Linux, ChromeOS, Android, and Android WebView)?

No

As with the initial FedCM, we do not support Android WebView.


Is this feature fully tested by web-platform-tests 

?

Yes

https://source.chromium.org/chromium/chromium/src/+/main:third_party/blink/web_tests/external/wpt/credential-management/fedcm-multi-idp/
 
Some of these tests are not relevant as they are related to the multi-get() 
approach.


Flag name on chrome://flags

FedCmMultiIdp

Finch feature name

FedCmMultipleIdentityProviders

Requires code in //chrome?

True

Tracking bug

https://bugs.chromium.org/p/chromium/issues/detail?id=1348262

Launch bug

https://launch.corp.google.com/launch/4229762

Estimated milestones

DevTrial on desktop

122

  OT desktop 124 - 128

  OT Android 125 - 128

Link to entry on the Chrome Platform Status

https://chromestatus.com/feature/5067784766095360

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 blink-dev+unsubscr...@chromium.org.
To view this discussion on the web visit