So we've been quiet on this one, but @samuelgoto knows that we've been working out what to do with it for some time.

We're broadly supportive of doing this work, even though we've identified a number of issues that mean that this is not an unreserved recommendation.

Overall, being able to restore some amount of user control over the cross-site flow of information about them is one of our most important efforts. This covers a number of different facets, but we think that something like FedCM could be an important part of the overall strategy.

A major complaint we hear about FedCM is that it is taking a generic capability and replacing it with a far more narrow and limited one. We think that - given how widely sites exchange information about user activity - this is justified and even necessary. Adding some friction to cross-site information flow is appropriate, especially if it means that users will be better able to observe and control those flows.

I say "better" here advisedly. There are a number of aspects to this work that will need to be worked out carefully over time. While we see an opportunity to make cross-site information flow explicit - and permissioned - we see a number of challenges:

• Improving user comprehension about the way in which information flows manifest on the web remains a challenge. For instance, the ability for sites to turn a one-off cross-site interactions into a persistent linkage between a user's identity on each site is hard to explain and understand. How use of FedCM will change how people conceptualize their online identity is something will need time and research to better understand.

• The appropriate level of friction in choosers and consent flows remains a point of contention. IdPs and RPs value low friction interactions as that leads to lower rates of attrition, but highly efficient interaction models have the effect of leading users toward actions that might not be in their best interests had they been given ample time to consider the full implications of a choice. Again, time and experience might better inform our choices here. For now, we plan to look very carefully at UX designs and how choosers are presented.

• We ultimately want to be able to offer options where IdPs are not in a position to track users through their use of identity information. The current design always involves notifying the IdP of all login attempts. This has a number of advantages from a security perspective. The IdP is able to audit logins and present users with information about their activities. Also, the IdP is in a better position to block access to identity information for bad RPs. Ultimately, we would like to be able to offer users at least the option of a more private choice here, but we recognize the practical security benefits of the current design.

We also don't yet have complete confidence in some details of the design:

• The ability to request identity from one of a set of identity providers is something we consider very important. The NASCAR problem tends to provide RPs an incentive to choose fewer IdPs, which in turn leads to less choice for users. The FedCM API offers an opportunity to improve this situation, but we are not yet confident that it will properly manage this situation.

• The retention of identity information in the browser for presenting in a chooser presents an interesting caching problem. Fetching the information on demand can result in leaking information to an IdP about visits to RPs, even when the user chooses not to use the identity provided by the IdP. However, if information is only registered once - when the identity is registered with the browser - that information could be stale when it comes time to present it. The best way of managing this problem remains an open question. The Chrome team have presented a number of heuristic-heavy options that are design to optimize for interaction efficiency, but we remain unconvinced of the value of seeking such efficiency (see above). There is some room for browser-specific innovation here, so we intend to watch this issue closely.

• How the browser presents identity information, including IdP branding, is a difficult balance. The UX we are talking about has privacy and security implications for users. Giving sites control over its presentation might be used to confuse or mislead people. At the same time, this API represents a significant regression in terms of how identity providers are able to interact with users. In place of arbitrary content in a large viewport (often an entire window, though sometimes a frame), IdP interactions will be mediated through browser UX. Balancing these concerns will require some careful UX design.