2C/ FEDCOM 101 / Sam G , Heather F
Session 1C
FedCM 101
Session Convener: Heather Flanagan, Sam Goto
Notes-taker(s): Heather Flanagan
Tags / links to resources / technology discussed, related to this session:
https://developer.chrome.com/blog/fedcm-shipping/
https://www.w3.org/community/fed-id/
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
What is FedCM? A way browsers can help you exchange identity attributes between parties while maintaining a high privacy bar. At its core, it’s a web platform high-level API (identity specific, but that comes with trade offs of more exclusivity vs less control). Trying to solve for the federation use case while preserving privacy.
Project has been underway for about 3 years (with various names). The initial focus was about the death of third-party cookies.
Safari and Firefox were ahead in many ways than Chrome in handling tracking prevention. The web is constructed in a fashion that has allowed tracking, and advertising networks are using the same mechanisms that the OIDF was using for some components of the protocol. Particularly impacted: front-channel logout. If the iFrame is cross-domain, those cookies count as third-party cookies.
How does FedCM know that there is a relationship between the RP and the IdP. The browser constructs that information from the UX by creating something that looks like an account chooser mediated by the browser. (Note this is actually a session chooser not an account chooser.) By establishing this relationship, things like front-channel logout will look. Since this is entirely mediated by the browser, the Googles and Facebooks won’t see it.
Any sophisticated of IdP will have multiple levels of sign-in which may make this complicated (e.g., step up authentication).
Is the granularity at the IdP at the IdP level or the account level? This is a different dialogue than WebAuthn provides, which is very much at the account level.
Browser checks in with IdP on what sessions are active to construct the UX. Browsers remove the ability for the IdP to know where you’re logging into until you consent.
The higher education use case brings complications because of the sheer number of IdP/RP relationships. Could the user bring their own preferred list? Or could there be a higher order of abstraction that says “we accept anything from this identity federation”? Bringing your own identity is a worthy goal.
The bootstrap component is going to be the hardest part - getting that first relationship recorded is critical.
There will be other areas where changes to prevent tracking will impact federation, particularly navigation-based tracking (aka, link decoration) and bounce tracking (aka, redirects).
If we can make FedCM compelling to solve some of the current pain points of federation, then both SAML and OIDC issues may be on the path to resolution sooner rather than later.
For consumers, Google expects that when Google exposes itself as a FedCM participant, that will encourage others to use FedCM as well, and then services like Dick Hardt’s Hello can take advantage of Google’s trailblazing.
Use case to explore: Tripit. They want to login with Google, but they need to be calling Tripit APIs. The site AS may have restrictions on what authentication methods are appropriate for a given client, which may in turn restrict what FedCM can show.
We haven’t talked about when the list isn’t sufficient for the identity the user wants to use (it shows one, but you want to switch to another identity). If you have three accounts, google, facebook, and yahoo, but are only logged into two, then the UX will say “there’s this other account you’re not logged into. Do you want to log into this other account?” This takes them to the account to log in, but that third IdP doesn’t know yet who the RP is. This doesn’t scale to the edu use case, but it’s what’s possible right now in the code. This then tells the browser the user is logged in and it will refresh the account list. After the user consents, the browser makes a post request to the IdP to the id-insertion endpoint. This is where the browser tells the IdP what the RP is. It has to prefill for the IdP. This is different from today’s NASCAR communication.
Where does the authorization screen get presented to the user? We’re separating authN from authZ; authZ is a secondary request. The consent the browser gathers is just to allow the authN. After the user consents, everything is game.
May be using consent in two different ways: an authorization server that says a client is acting a certain way, whereas FedCM is talking about the user saying “I consent for these actions to happen”.
Sometime authentication flows also call fraud detection.
Timeframe: Chrome will block them in 2024, Safari and Firefox already do.
