At the start of March this year I started working on ensuring FedCM supported decentralized ecosystems, such as AT Protocol, funded by a grant from Bluesky Social PBC. Part of doing this work requires communicating updates on progress to keep everyone informed. I'm a bit behind on getting these updates out, as my chronic illness has been particularly bad over the summer this year, which has significantly impeded my ability to write these updates, but I'd like to share with you the progress we've been making on FedCM for decentralized ecosystems.

Getting Started

I started ramping up to work on FedCM a few months before the grant came through, which was mostly trying to catch up with where things were at, and trying to understand processes and securing the invited expert status with the W3C Working Group for FedID who oversee FedCM.

Once the grant was announced, I made a rather strong outreach push in March to make sure people were aware of my grant and presence, through attending both the regular FedCM meetings and also reaching out to other communities to have meetings with them to better understand what they'd need from FedCM, and how I could help them achieve their goals. These meetings included the:

There was some concern from people on various social media platforms about the grant, so I ended up spending a significant amount of time on community relations and published an article on how standards are made, based on my knowledge of participating in various standards organisations over the years. This sort of knowledge is known to people within the standards world but sounds completely foreign to people outside of the standards world.

To be clear: the FedCM grant from Bluesky explicitly requires me to work with projects outside of AT Protocol, and Bluesky does not have any final say in my decisions on the FedID Working Group. Those are my decisions and my decisions alone. I will however solicit feedback from various stakeholders and try to make sure that there is some alignment between the various stakeholders in order to elevate all of our voices and needs rather than just a specific stakeholder's needs.

The Fediverse & ActivityPub

There is a noted gap in my outreach with regards to ActivityPub and the Fediverse, as I currently do not have a point of contact for the Social Web Working Group or Community Group, and personally I've stopped my own active involvement with the community group, so cannot represent their needs directly.

I have tried to encourage collaboration, but haven't received significant interest yet, or members believe that they are better off representing themselves without collaborating. Maybe that will change in the future, TPAC is coming up and would be one of the places that people could learn more about FedCM.

There is also a fairly significant divide between where the Fediverse is at with regards to account management and identity, in contrast to other ecosystems such as Solid, IndieAuth, and AT Protocol, where identity is a fundamental concept. In the Fediverse, you typically don't have separation between your identity and the functionality of your software. Commonly this looks like having a Mastodon account, and it is just a Mastodon account, it cannot be a Pixelfed or other account at the same time.

This may change in the future, but also means the usefulness of FedCM in this ecosystem is limited to pre-filling handles, with only some applications benefitting from credentials being issued.

Meetings

Each meeting is typically an hour long, with usually some follow up afterwards. I did miss a few meetings unfortunately due to some issues with the W3C calendar not syncing with my own, as well as the aforementioned health issues. I've attended the following FedCM/FedID meetings over the past few months (each is a link to the meeting notes):

There have been a few notable points for discussion during these meetings. The relevant ones for decentralized ecosystems are listed below with some more information. And yes, standards work involves a lot of meetings.

I also started working with Sam Goto, who works on the Chromium team, to try to figure out the UX flows for FedCM within the decentralized web ecosystem, though there was a bit of confusion between what was achievable today and what wasn't. We've since picked up our initial discussions and had a series of workshops on the FedCM UX, more on that below.

What is FedCM Core?

One of the big decision points within the FedCM specification at the moment is defining what a "FedCM Core" would look like, as the FedCM API surface is quite large. This "core" would ensure more consistent adoption of the specification by browser vendors, specifying what must be implemented in order to be considered to have implemented FedCM.

This currently affects decentralized ecosystems, as identity provider registration has not yet reached stage 2, and this means that it cannot yet be included within FedCM Core.

One of the key requirements for decentralized ecosystems is being able to register with the browser as an identity provider, such that applications can match based on provider "type" rather than hard coding an explicit list of provider configuration URLs. That effectively changes an application from being locked to specific providers to being open to an ecosystem of compatible providers.

Moving Identity Provider Registration to Stage 2

At the June 2nd FedCM meeting, we had discussion about whether Identity Provider Registration could move to stage 2. There was a little bit of a disconnect between myself and the Chromium team, as I hadn't correctly understood what was required to move to stage 2, and I hadn't seen any open issues at the time that looked like had blockers for stage 2.

It was decided that we weren't ready to move forwards with Identity Provider Registration, as we needed more iteration on the user experiences that we intended to deliver through this proposal.

Realising that there was more work to do here, Sam and I set up a series of meetings to workshop what we'd want from the user experience of FedCM for decentralized web ecosystems, specifically focusing on the differences between the different modes of FedCM. We've now shared the early mockups of that work, where we've looked at the identity provider registration UX and at how we can support the full range of modes that FedCM supports when using identity provider registration.

Within FedCM, there are essentially two modes for the user experience: Active Mode and Passive Mode. In Active Mode, the user experience is blocked by a prompt to select an account or cancel the flow, always resulting in a credential being returned. In Passive Mode, the user experience does not block the user from interacting with the page, probably the most well known flow here is the overlay in the top right of the page, which lists accounts you can sign in with and is able to be dismissed. Also available in Chrome at the moment is form input autocomplete and a URL bar pill, both of which provide different user experiences.

Screenshot of the active mode dialog for FedCM showing a list of accounts that all share the same type, but come from different providers.
Passive mode for FedCM showing a small list of accounts which is dismissible and does not block interaction with the underlying page.

In a nutshell, there are essentially three main issues at play when it comes to centralized vs decentralized FedCM:

  1. 1.

    Whether the relying party wishes to use active mode1 or passive mode for the FedCM integration, and how that affects or interacts with the user experience of these flows

  2. 2.

    The issue of single identity provider versus multiple identity providers in these flows, and whether we need to adjust those for multiple identity providers which is implicitly the case for decentralized FedCM.

  3. 3.

    For identity provider registration, we realised we needed to address how the user consents to the registration, as allowing any website to silently register as an identity provider could pose safety or security risks.

After a lot of hard work, we think we've worked out most of the user experience flows to support both multiple identity providers and decentralized ecosystems, and will be expanding on that more soon.

We've also talked with others in the decentralized ecosystems who have been trying to figure out their authentication and authorization journeys, such as Devin Ivy at Bluesky who has written some thoughts about atmospheric logins on his blog.

What do we want to get out of the FedCM integration?

There is another question here, which is related to what type of result you want from the FedCM API when integrating as a relying party (application).

For some applications, they will want to receive back a credential that then allows them to interact with further APIs provided by that ecosystem, this is the case for AT Protocol and Solid.

For other ecosystems, issuing a credential would actually carry a security risk and be unnecessary, as the applications aren't designed to work with multiple providers (see the Mastodon example above), so retrieving back an identity without a credential would be preferred. For this use-case, FedCM has the Fields API which is in a bit of a state of flux and I'm trying to clarify this further at the moment.

Essentially the Fields API allows a relying party to receive the identity and related fields that the person using the browser has allowed to be disclosed to the relying party. For instance, you might request the identity, email address, profile picture associated with the selected account, but the person responding to that request may only allow you access to the identity and profile picture, and not other data like the email address. That is selective disclosure within the control of the person completing the FedCM flow, mediated by the browser.

Currently the Fields API may not be part of FedCM Core, despite it being merged into the FedCM specification. I'm currently trying to clarify what exactly this means for the specification.

Additional APIs and features

One major change to FedCM last year was to enable returning structured data from the identity assertion endpoint, avoiding the need to send encoded JSON within the token response which was already JSON itself. This means that the identity assertion endpoint (for those familiar with OAuth, this is kind of like the token endpoint for FedCM), can return back not just an access token but also a refresh token and other metadata about the token without needing to decode the credential as a JSON value.

Continuation API

We have gained a new API which is not quite as well known as the other FedCM APIs yet, which is the Continuation API. An identity provider would use this API for when they don't wish to complete the identity assertion endpoint request and instead return a response that says, "In order to continue to do this, you need to visit this URL."

This is very relevant in OAuth-based identity systems, where an authorization server may require authorization from the account holder prior to granting an application access.

It can also be used in cases where the identity provider may wish to require an additional challenge during the FedCM flow, for instance, requiring a second-factor authentication code or passkey before completing the flow.

There is more documentation that is being written on the Continuation API, and hopefully I'll have an update when that is live.

What's next?

The ask that I have for the decentralized web community is: if you would like to integrate FedCM into your project, please do let us know how you envision that integration working, you can reach out to me on my various social platforms and request a meeting with me if you need more information.