The Federated Credential Management API (FedCM), a specification currently under development through the W3C’s standardization process, was originally scoped to make sure federated authentication would still function in a world where third-party cookies didn’t exist. The problem statement as defined during a workshop in 2021 stated it this way:
Non-transparent, uncontrollable tracking of users across the web needs to be addressed and prevented.
Many applications and services need to work through the browser to support SSO/federated login, and yet federated login and tracking tools use the same features and are indistinguishable from the browser’s perspective.
One of the ongoing challenges, however, is that people who implement and design federated authentication services don’t think of those services just in terms of cookies. As soon as you start talking about federated authentication, those people also think about all the different web primitives like website redirects and long URLs.
Balancing a Specification: Focus vs Practicality
Let’s step back for a moment and think about creating a technical specification. If you ask me (and it’s my blog, so I get to say) a good specification is focused on a very specific problem. If you try to solve too many things in one spec, you’re going to limit innovation, miss important use cases, or create something too complicated to implement.
That said, if you don’t consider how a spec will actually be implemented, it probably won’t be of any practical use. Solving for one piece of the larger architecture without any idea as to how the other pieces will be treated is as bad as creating too broad a spec.
A spec can and should allow for extensions as people find new use cases that need a solution, or profiles that tighten the spec down where required. But at its core, the problem being solved should be clear and specific.
That’s the challenge facing FedCM right now: staying within the scope of a very specific problem when people are Very Concerned about what else will need to change to prevent non-transparent, uncontrollable tracking of users across the web.
The FedCM Specification
Coming back to FedCM, the Federated Identity Community Group in the W3C just published a blog post that talked about some of the problems FedCM doesn’t solve. (Full disclosure: I held the pen on that post as one of the co-chairs, with input from several members of the group.) FedCM originated from the need to preserve the functionality of third-party cookies when used in a federated authentication scenario. But there are more web primitives than cookies used for federated authentication. Should the specification consider those as well? Is it worth implementing at all if it doesn’t solve (or at least offer some direction) on how to handle the other web primitives (like redirects) that are also used for tracking on the web?
I think it comes down to a subtle lack of alignment and/or understanding of the problem being solved. Is FedCM supposed to solve for the deprecation of third-party cookies or is it supposed to solve for tracking across the web? When we first started, it was clearly just solving for the third-party cookie problem. Over time, however, there is confusion even within the groups working on the spec whether they are aiming for the larger problem.
Implementation Decisions
So, what are implementers to do? They could implement the specification (which, to be clear, is NOT a standard and does NOT have consensus yet in the groups working on it) to get ahead of what the browser vendors are doing, but have to deal with breaking changes as the spec evolves. They could wait and suddenly find out that their federated authentication infrastructure is breaking because they missed the latest changes as the specification gets closer to standardization.
Adapting to an Evolving Web
If there was an easy answer, we wouldn’t be talking about standards and tech. There are too many competing use cases, threat models, business considerations, and architectures to take into consideration. My only advice is to get involved in the standards process if you can or pay attention to developer sites (like this one or this one) and the people involved. The way the Internet and the web works is always evolving; designing your business or service to adapt to change is the only way to be successful.
I want to help you go from overwhelmed at the rapid pace of change in identity-related standards to prepared to strategically invest in the critical standards for your business. Follow me on LinkedIn or reach out to discuss my Digital Identity Standards Development Services.