The purpose of the Federated Identity Community Group is to provide a forum focused on incubating web features that will both support federated identity and prevent untransparent, uncontrollable tracking of users across the web. While the community group will take privacy concerns into consideration, these concerns will be balanced against the need to explore innovative ideas around federated authentication on the web.
fedidcgGroup's public email, repo and wiki activity over time
Note: Community Groups are proposed and run by the community. Although W3C hosts these
conversations, the groups do not necessarily represent the views of the W3C Membership or staff.
Chairs, when logged in, may publish draft and final reports. Please see report requirements.
The recent W3C TPAC meeting brought together members of the Federated Identity (FedID) Community Group (CG) and Working Group (WG) (and interested observers) for discussions on our ongoing efforts in federated authentication and credential management. Despite facing some unexpected logistical challenges—a major power outage and persistent construction noise—we had productive sessions over the course of two days. ICYMI, here are some of the key takeaways from the meetings.
Day 1: CG-WG Process and Feature Demos
Day 1 was dedicated to reviewing our CG-WG processes and demos from people who have implemented FedCM, including Shopify and Google Identity. As part of our introduction, we took this time to clarify the working relationship between the Community Group and the Working Group, highlighting pathways for ideas to progress from concept to recommendation. We want people to have a better sense for what stage of maturity any particular issue or proposal is in the process; looking from the outside, that’s sometimes difficult to figure out! We also want a way for Developers to indicate that a feature is of sufficient interest and meets a need such that it should be made part of the web platform.
The community-driven aspects of our work continue to be a critical factor in the success of the Federated Credential Management (FedCM) initiative, and we saw that in the quality of the demos presented. Diving into those discussions (when we weren’t drowned out by the noise of jackhammers) made for an interesting and extended set of conversations, pushing some of what we wanted to discuss into Day 2.
As always, the key focus was on understanding how new proposals can enhance user experience without compromising privacy or introducing unnecessary complexity.
Day 2: Reviewing Proposals and Moving Forward
Day 2 saw us combining the canceled morning session with the afternoon time slot, but we made considerable progress on several important topics. We started with a demo and discussion around Lightweight FedCM, which is still in Stage 1. From there, we focused on multiple proposals specifically related to the main FedCM API that are currently in Stage 1, assessing their readiness to move to Stage 2 based on explainers, considerations of alternatives, and demonstration of developer need/fitness for purpose. Notably, the following proposals reached consensus for advancement:
These proposals are crucial to furthering the capabilities of FedCM, particularly in managing multiple identity providers, improving user interaction with federated login flows, and enhancing the overall flexibility of identity management solutions. We have asked the community to review these decisions and provide feedback via pull requests if there are any additions or corrections to be made. You can find more details and follow the discussions on the Status of FPWD-identified Issues page.
It’s worth noting that moving items into Stage 2 does not mean they are complete and ready for standardization. It means we have the shape of the idea sorted out enough to start writing specification text instead of just explainers; final approvals for a full Candidate Recommendation happen later in our process while entering Stage 3.
Discussions Beyond the Meeting: Login Status API
One of the topics that generated extensive discussion was the Login Status proposal, which carried on beyond the working session itself. The question was if and/or how to merge the Login Status API repository in the Privacy CG with the Login Status API repo in the FedID WG. There is now a dedicated GitHub issue (Login Status Issue #8) that outlines possible next steps. If you’re involved in this aspect of the project, please contribute your thoughts to help us build consensus around the best path forward. To summarize this one, we are keeping both the Privacy CG and the FedID WG repositories for now, as they are focused on slightly different things (verified login status vs self-asserted login status). The repository in the FedID WG will continue to be developed, but the editors are going to keep compatibility with the goals of the Privacy CG’s original work in mind.
FedCM Breakout Session: A Deeper Dive
At TPAC, we also held an in-depth breakout session focused on the implementation of FedCM by Shopify. This session explored some of the challenges and opportunities in deploying FedCM, particularly in environments with multiple identity providers and complex configuration needs. The discussion notes from this session are available here, and they provide a great overview of how we’re navigating the technical complexities that arise when implementing a federated approach to identity.
Looking Ahead
In addition to advancing specific proposals, we also discussed a procedural clarification aimed at streamlining how we reach consensus on pull requests and proposal advancements. During the meeting, we made provisional decisions on how editors and chairs could be empowered to make real-time consensus calls without always needing a follow-up call to the mailing list. This change could significantly improve our ability to respond quickly to emerging ideas and developments, while still ensuring transparency and accountability. We are currently seeking feedback on this proposed change—if you have concerns, please let us know.
Moving forward, we’re committed to driving progress in federated identity solutions that prioritize user privacy, security, and usability. We encourage all members to stay involved—whether by reviewing meeting notes, contributing to GitHub issues, or participating in future discussions. Your insights and contributions are vital as we refine and expand the FedCM specification and work toward broader adoption.
If you have feedback or wish to contribute, please engage with us through GitHub, where the minutes from TPAC have been posted:
Finally, we’d like to extend our thanks to everyone who participated in the TPAC meetings. Despite the challenges we faced, we were able to hold meaningful discussions that helped us advance critical proposals and processes. We look forward to your continued support and contributions!
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 web platform features and are indistinguishable from the browser’s perspective. From cookies to navigation-based tracking, establishing controls at the user agent (aka, browser) level that still allows authentication protocols like OAuth, OIDC, and SAML to function across all their permutations is a big undertaking.
One of the efforts underway to preserve the functionality of federated authentication is FedCM. FedCM is designed to help in federated authentication scenarios involving only two parties (or, more specifically, two origins). For those architectures that involve bouncing between multiple origins, also known as multi-hop scenarios, users may encounter a permission request to share data for each new pair-wise connection.
The Federated Identity Community and Working Groups, the groups responsible for standardizing FedCM, remain focused primarily on enabling authentication protocols, invoked in an embedded context, to function in the absence of third-party cookies. The work is (currently) focused on the use case of authentication actions between only two origins; for example, a user signing into a news site with their identity provider account. Adding additional origins takes us into the realm of navigation-based tracking mitigation, and that’s currently out of scope for FedCM. It’s worth noting that these groups are working towards consensus, but there is still quite a bit to do before we agree to the final specification.
Authentication actions between two origins will likely cover a large number of use cases, particularly in the world of social logins using Google, Facebook, or enterprise, university, or government services. For use cases where multiple identity provider services are chained together—something often found in higher education and the enterprise—initial versions of FedCM apply only if you are using the Continuation API within FedCM, which can help address some of these more complex use cases. For example, an organization may use an MFA solution that is different from their IdP. These solutions are typically integrated using federation protocols, which often involve redirects across additional origins. The Continuation API would allow these flows to continue in a pop-up window. This pattern could also be used for some multi-hop federation use cases.
Bindings
FedCM aims to be protocol agnostic, but that doesn’t mean that the protocols don’t have to evolve to take advantage of FedCM. Aaron Parecki (Okta) is currently working on a document that will describe an OAuth binding for FedCM. This type of binding is necessary to provide FedCM with the data it needs to present the choice to the individual regarding the authentication action.
A similar binding is necessary for SAML-based authentication flows. That work, however, is pending initiation as any further development of the SAML specification lacks a clear home; the OASIS Security Services Technical Committee (SSTC) responsible for maintaining the SAML protocol has been closed. The profile effort for SAML will need to happen in another standards organization, but grassroots efforts to define a SAML binding document could start today!
What FedCM Can Do Today
Any time the authentication process requires more than one hop to complete, regardless of protocol, FedCM is not the answer (yet). Implementors expecting FedCM to resolve navigation-based tracking will have to wait a long time while the community considers what will work best in this scenario. The community and working groups both recognize that breaking changes to URL navigation will break the web if not handled with extreme care.
The web is moving towards much stricter privacy controls. These controls require informing individuals whenever their data is being processed by a third party. If you think of that as a core requirement for the web, then the challenge shifts to the user experience of a new request for permission at each and every hop across origins. While most recognize that as a poor user experience, we have not thought of a better solution at this time.
Continuing the Conversation
If you are interested in engaging with new ideas and possibilities for FedCM, then please join the FedID Community Group. That’s where incubation happens! For more concrete development on specific areas intended for standardization, the FedID Working Group is the place to be. The two groups work closely together, and new participants are welcome.
The audience for this post is people who are unfamiliar with how privacy concerns may impact federated identity. That likely includes people from one of two groups: 1) people who are interested in privacy, but are new to the concept of federated identity, or 2) people who are familiar with federated identity, but are unaware of the changes being made to browsers because of the privacy concerns. The goal of the post is to provide an introduction to federated identity and why it matters, what the privacy changes are and their potential impact, and then describe how FedID CG is working to preserve federated identity in light of the privacy-related changes.
Federated Identity encompasses the technologies, standards, and use cases in which the user identification and user authentication services are separated from the service providing the resource a user is trying to access. The organizations providing the user identification/authentication services are generally referred to as Identity Providers, and the organizations that utilize their services are often referred to as Relying Parties. Federated identity makes it possible for a website, app, and/or API to outsource authentication to an external entity. In practice, users with an account with entity A can gain access to web apps B and C without having to create new usernames and passwords, if B and C outsource authentication. Sometimes referred to as Single Sign-On, or SSO, there is a distinction to be made between SSO and federated identity. SSO is a property of federated identity that makes it possible for a user to gain access to distinct web apps or API without having to reenter credentials. The broader use of federated identity is when the resources involved are located in different security domains and are owned by different organizations.
The types of organizations that use federated identity are as varied as the internet. It’s a common practice to use federated identity to streamline account management and access by allowing users to log in with an identity provider account (those “Log in with Facebook”, “Log in with Google”, “Log in with …” buttons.). It’s also commonly used by businesses to manage their employees’ access to company resources. Universities use federated identity to offer students multi-institutional academic programs, to provide shared access to educational resources, and for research collaboration. Federal institutions use federated identity to manage access to federal resources too – as do financial institutions. And for one final example, it’s also frequently used in Software-as-a-Service business models as well.
Federated identity significantly reduces the burden on users by limiting account proliferation. It streamlines the user experience, lowers the security risks associated with password re-use (e.g., credential stuffing attacks), decreases the raw number of access credentials that a user has to remember and manage, and facilitates inter-organizational relationships and management.
However, linking a user’s identity across systems also raises privacy concerns, especially when done across organizations/entities (and to a much lesser extent even when the resources are all owned by the same organization). While the objective of federated identity systems is to facilitate a user’s access to resources online, it was originally designed on top of web primitives (e.g. third-party cookies, top-level navigations, etc). These primitives can and are being abused to track users without their consent or full understanding.
In response to these concerns, user-agents are making changes to how they work with some of the fundamental primitives of the web to prevent the uncontrolled, hidden tracking of users. Since federated identity often utilizes these same primitives to exchange necessary information to complete authentication flows, we need to develop solutions that address these privacy concerns without breaking federated identity.
There are a variety of privacy-related interventions that user-agents are exploring. These include deprecating third-party cookies, controlling access to the client’s web storage, removing certain parameters from links (often referred to as link decoration), and restricting the capabilities of navigational redirects. Federated identity often relies on these same mechanisms, and so the changes being made to improve support for end-user privacy are having an effect on federated identity systems. Since the most immediate change is the deprecation of third-party cookies (having already been deployed in Safari and Firefox, and publicly planned for Chrome in late 2023), the Federated Identity Community Group (FedID CG) is currently focusing most of its attention on the impact of that change. The group is working to preserve federation when third-party cookies are deprecated.
The FedID CG meets every week to provide feedback on the proposals that are relevant to federated identity. The full charter for the group can be found here. If you’re interested in learning more, we are currently working on a draft report that will be published shortly. If you’d like to participate in the group, you can join FedID CG here. Please note that while a W3C account is required to join, you do not need to be a member of the W3C. If you don’t have a W3C account, you can sign up for one on the W3C account request page.
The Federated Identity CG is chartered to provide a forum focused on incubating web features that will both support federated identity and prevent untransparent, uncontrollable tracking of users across the web. If that sounds interesting to you, please join us!
We conduct all of our technical work in public, mainly in various GitHub repositories but also in periodic teleconferences and face-to-face meetings.
We try to keep the list of our current work items in our charter up-to-date. You can follow links from there to each work item’s GitHub repository, where you can see the latest text, and file or comment on issues.
The purpose of the Federated Identity Community Group is to provide a forum focused on incubating web features that will both support federated identity and prevent untransparent, uncontrollable tracking of users across the web. While the community group will take privacy concerns into consideration, these concerns will be balanced against the need to explore innovative ideas around federated authentication on the web.
This is a community initiative. This group was originally proposed on 2021-07-06 by Heather Flanagan. The following people supported its creation: Heather Flanagan, George Fletcher, Tim Cappalli, Vittorio Bertocci, Brian Campbell, Dan Moore, AJ Longstreet. W3C’s hosting of this group does not imply endorsement of the activities.