FedCM (was WebID)

[samuelgoto]

Request for Mozilla Position on an Emerging Web Specification

• Specification Title: Federated Credential Management API
• Specification or proposal URL:
  • explainer
  • specification
  • TPAC2021 presentation (good introduction)
• Caniuse.com URL (optional):
• Bugzilla URL (optional):
• Mozillians who can provide input (optional):
  • Since we started, we've discussed this proposal with a few mozillians:
  • stpeter (general point of contact)
  • @martinthomson (overall guidance)
  • tvyas, johannhof (early privacy discussions)
  • danmills, rfkelly, arthur (on mozilla personas)

Other information

Various other reviews:

• WICG thread
• Federation and Browsers Workshop
• Intent To Prototype
• Intent To Experiment
• FedID CG
• early TAG review
• Ready For Trial
• spec TAG review
• WebKIt's Position Thread

[martinthomson]

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.

[bvandersloot-mozilla]

More than two years out: I think this merits an update.

Much of Martin's comment is either still true or seems quite prescient looking back.

We still believe that "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. [...] something like FedCM could be an important part of the overall strategy" and that "[a]dding 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."

However, some of our reservations on the initial positive position have not been addressed and some new issues have arisen.

• The appropriate level of friction in choosers and consent flows remains a point of contention, still. The current FedCM API is designed with a lot of consideration for click-through rate optimization, which is a chief concern of social-login providers. The design choices required to maintain the "one-click" constraint have negatively impacted privacy and the ease-of-deployment of the API.

• Deciding appropriate levels of friction are further complicated by the degree of user annoyance associated with social logins now. This is particularly a problem with the "passive mode" that is a core behavior of the API as specified, where without user interaction the browser is specified that it must show an account chooser to the user.

• We believe that user understanding of identity flows on the web may be made made worse by the UI enabled by this specification. In particular, the browser UI that Chrome has shipped looks nearly identical to the Google Identity One-Tap widget when third-party cookies are available. Displaying a user identity where it has not yet been linked could easily convince a user that this information is already available to the site they are on, especially in browsers where third-party cookies are already disabled and that haven't shipped FedCM.

• Overall we have seen a trend of FedCM covering more use cases by integrating more identity provider logic into the API with more fields and features. We have been advocating for an approach of addition by subtraction and using a lighter touch from the browser to facilitate user consent to the information flow between sites and getting out of the way. The Lightweight FedCM proposal is our effort to push forward on that approach, and may eventually be a subset of the full FedCM proposal.

[RByers]

Thanks for your comments Ben! I just wanted to chime in on a couple points where I think there is some miscommunication or misunderstanding.

The current FedCM API is designed with a lot of consideration for click-through rate optimization, which is a chief concern of social-login providers.

The reason this is of interest for social login providers is that it's a chief concern of the publishers those providers serve. In Chrome we are focused on trying to help the diversity of publishers preserve their independent business models along with the trend of increasing privacy, rather than increasing the economic pressure for centralization in publishing towards a small number of 'walled-gardens' which users stay signed into. How best to manage this tension between concentration and privacy is a legitimate point of debate and browser competition, but it's incorrect to frame this as a tradeoff between the interests of users and that of social-login providers. Google Sign-In, for instance, benefits from sign-in rates only insomuch as it means there is more content available on the web for users to search for. Earning FedCM adoption from social login providers is an important goal for Chrome for these reasons, but I totally understand that it may not be an important goal for other browsers.

This is particularly a problem with the "passive mode" that is a core behavior of the API as specified, where without user interaction the browser is specified that it must show an account chooser to the user.

We've just filed this as a bug in the spec, passive mode should not require any UI be shown. For example, Chrome's 'cool-down' behavior already suppresses the UI when we believe it's what the user wants and we're exploring ways to expand this to better align the experience with user preferences. Personally I'm excited by the opportunity FedCM provides to make social login less intrusive while preserving the business value for publishers.

Displaying a user identity where it has not yet been linked could easily convince a user that this information is already available to the site they are on

This is a legitimate point of browser design disagreement that has come up many times in other contexts (eg. fenced frames). Chrome believes that the value to users of composing information across contexts (while preserving privacy in the implementation) exceeds the risk of user confusion. But in the FedCM context this is entirely a choice for the UA. As I understand it, Firefox was already implementing FedCM with UI that was clearly part of the browser, not part of the page, right? There is nothing in the FedCM spec which encourages the UI to appear as part of the web page, or that prevents the UA from getting additional confirmation from the user before showing an account list.

The Lightweight FedCM proposal is our effort to push forward on that approach, and may eventually be a subset of the full FedCM proposal.

Thank you, we agree with you here. Lightweight FedCM offers some unique advantages and we're excited to pursue this with you, with a plan to ship it in Chrome once we have evidence of adoption interest. While we don't expect it will meet the needs of social login providers (and so likely see much lower usage), we're hopeful that it will prove to address needs in other important scenarios. In addition I hope we can agree that the 'active' mode of FedCM avoids much of the concerns you've highlighted and continues to be a good area for standards collaboration even if Firefox has no immediate plans to ship it.

[maceip]

as a web developer and web user who isnt employed by or equity owner it an adjecent web tech / ads / privacy org I would respectfully ask you to get this into mozilla browsers.

and also -- given how important and meticulous web standards folks are, this might be the right place to ask: how / where are you measuring "how are we doing" with web standards?