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.
Group'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.
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.
fedidcg
Recent Comments