You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a series of places where implementations can (and currently do) make choices with regards to (a) whether and (b) what prompts are shown to the user.
For example, in Chrome's implementation, in passive mode, the browser reserves the right to automatically ignore the FedCM request if the user has dismissed it in the past (we call this cooldown), and does that in an exponential back-off. The browser also reserves the right to change the UX, and experiment with things like (a) different UX formulations from account choosers, like quieter and smaller url bar pills and (b) heuristics for triggering.
For example, in another implementation, one could choose to use an IdP chooser (rather than an account chooser) to avoid incurring into timing attacks, and still comply to the specification.
In the Create an IdentityCredential algorithm, the spec doesn't make it clear that some of these choices can be made, or is sometimes too opinionated that these necessary need to look like an account chooser, such as in the request permission to sign-up algorithm.
We should clarify where these choices can be made and make sure that the spec reflects some of these choices that were made in implementations.
The text was updated successfully, but these errors were encountered:
There are a series of places where implementations can (and currently do) make choices with regards to (a) whether and (b) what prompts are shown to the user.
For example, in Chrome's implementation, in passive mode, the browser reserves the right to automatically ignore the FedCM request if the user has dismissed it in the past (we call this cooldown), and does that in an exponential back-off. The browser also reserves the right to change the UX, and experiment with things like (a) different UX formulations from account choosers, like quieter and smaller url bar pills and (b) heuristics for triggering.
For example, in another implementation, one could choose to use an IdP chooser (rather than an account chooser) to avoid incurring into timing attacks, and still comply to the specification.
In the Create an IdentityCredential algorithm, the spec doesn't make it clear that some of these choices can be made, or is sometimes too opinionated that these necessary need to look like an account chooser, such as in the request permission to sign-up algorithm.
We should clarify where these choices can be made and make sure that the spec reflects some of these choices that were made in implementations.
The text was updated successfully, but these errors were encountered: