FedCM Multi IDP Support

[npm1]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Federated Credential Management API with multiple IDP support
• Specification or proposal URL: https://github.com/fedidcg/FedCM/blob/main/proposals/multi-idp-api.md (thanks @tttzach!)
• Mozillians who can provide input (optional): @bvandersloot-mozilla @martinthomson

Other information

Hey, I am requesting standards position on the FedCM API multi IDP support. The explainer is up from GitHub and is based on a bunch of discussions in the FedID CG. The original FedCM request was done in #701 but since this is a substantial update, I figured it's worth requesting standards position for this as well.

[bvandersloot-mozilla]

This represents my understanding of the problem and solution spaces pretty well. I assume this request is for the Batched Get Implementation- is that right?

Overall, I think this proposal makes sense and is a substantial improvement to FedCM. But I have a few open concerns:

• The cutoff for inclusion in the dialog for the before-or-during-onload case should be “an implementation-defined time, no sooner than the end of the window onload event.” This gives a little more flexibility and is a relaxation of your definition.
• IDP ordering is unresolved and an important feature. I don’t like response time factoring into the ordering- this favors IdPs with multiple points of presence when RPs don’t specify the ordering. However, there are answers here that I like: prioritization based on prior use, randomization, and/or sort-by-hash.

I agree that this version is probably confusing for developers, however with good documentation that offers a one-sentence explanation of the semantics of a call to navigator.credentials.get({‘identity’: {}}) I think it will work out in the end.

This does further complicate the eventual vision of the Credential Management API to integrate all options in a single dialog. However, similar issues need to be solved in WebAuthN, so I don’t worry too much.

Do my suggestions in the open concern bullets above sound like positive improvements to your proposal?

[npm1]

This represents my understanding of the problem and solution spaces pretty well. I assume this request is for the Batched Get Implementation- is that right?

Indeed!

• The cutoff for inclusion in the dialog for the before-or-during-onload case should be “an implementation-defined time, no sooner than the end of the window onload event.” This gives a little more flexibility and is a relaxation of your definition.

We haven't spec'd this out but that is certainly the intention. It is mentioned in the explainer here https://github.com/fedidcg/FedCM/blob/main/proposals/multi-idp-api.md#2-batched-get-implementation

• IDP ordering is unresolved and an important feature. I don’t like response time factoring into the ordering- this favors IdPs with multiple points of presence when RPs don’t specify the ordering. However, there are answers here that I like: prioritization based on prior use, randomization, and/or sort-by-hash.

Good ideas! I wonder if the IDP ordering needs to be specified since it is part of the user agent dialog? I think all of those prioritization options would be valid under the spec we come up with. If you force me to pick a specific ordering from the above, I would say that prior use is good for the user so I would use that, and randomization could be used to break ties (i.e. to order all the previously unused IDPs).

Do my suggestions in the open concern bullets above sound like positive improvements to your proposal?

Yep, they all sound good to me! Thanks for the feedback.

[npm1]

Pinging this thread along with an update. In Chrome, we are planning to do an Origin Trial (not ship yet) the multi IDP support restricted to the case where all IDPs are indicated in a single get() call. In particular, it will still be the case that any subsequent get() call will be rejected when there is a pending one.

This restriction makes a lot of the complicated UX problems go away, and we have found cases (companies owning multiple IDPs) where it would be beneficial, so we think moving forward with this will be beneficial. Any position with regards to this specific extension of the FedCM API would be appreciated. Thanks!

[bvandersloot-mozilla]

The speific extension outlines with a single get call is a reasonable one and addresses the concerns from above.