Keeping track of discussions:
(Cross-posting. And eyeing matrix ↔ github/discourse/slack integrations.)
FWIW, I’m looking for a mechanism that allows the RP to pass to the browser their TOS and PPs, so having a URL with a JSON could help.
We don’t want to make FedCM oauth-specific, so it is possible we’d make this a separate/independent URL.
Also just wanted to drop a link here to an issue we’re discussing on the IndieAuth spec to update its client_id to a link to a JSON document, rather than the current version that expects to parse Microformats on the client_id URL. Update client information discovery method · Issue #133 · indieweb/indieauth · GitHub
Now that I have a working FedCM Idp and RP for LastLogin, I spent a few hours looking into making a Discourse plugin (thanks for your excellent tutorials @angus!).
I’ve decided learning Ruby+Rails+Ember.js+Discourse architecture is probably not a super productive use of my time currently. I thought it might make sense since forum.indiebits.io is the largest community I have direct admin control for, and it already supports LastLogin as an IdP, but there’s probably a route to what we need that would require less person-hours.
If anyone else decides to develop a FedCM plugin for Discourse, I’ll gladly offer IndieBits as a place to test it.
Thanks @apitman. While learning how to build Discourse plugins can be rewarding, I agree it might not be the best use of your time on this issue. Once the basic spec settles a bit more I will make sure a FedCM plugin for Discourse is made 
Here’s the talk introducing the Client ID Metadata Documents I-D at IETF 120 yesterday: https://youtu.be/s0u-ORqr8to?list=PLC86T-6ZTP5j9uBe9CSYa7zlVRl7NwPyN&t=4961
I’ve been experimenting with this too and I’ve finally got around to putting some of my experiments online.
If anyone’s looking for an RP to test against, feel free to give mine a try: https://login.mythik.co.uk/
If you’re interested in FedCM, you might find some of its other features interesting, too. More details here.
Bumping this thread.
We made significant progress improving the decentralized features of FedCM a few months ago, but the folks at Google still feel like we need more evidence of RP/client interest:
It’s a chicken/egg problem for sure, but making some sacrifices now could yield huge benefits down the road if we can actually get this thing shipped.
Does anyone have ideas/resources/connections that might be able to help get some major RP software and/or services on board for testing?
I made some updates to my free login service LastLogin. You can now use it to log in to any client/RP that implements FedCM+IndieAuth as described here, without needing their own domain first.
Anyone willing to implement an RP now has an IdP they can test against in LastLogin.
Steps to try it out:
@angus would you be willing to take another look at implementing a Discourse plugin for this? I think with the improvements we made to the API, it’s in a state pretty similar to what it will be if it ends up going through.
What’s badly needed now is for clients/RPs to prove this is something they were deploy. Having a Discourse plugin would enable us to campaign many communities to enable FedCM support and try it out.
The production-ready current implementations have settled on FedCM+IndieAuth. This would involve you implementing the client/RP side from this document: FedCM for IndieAuth - IndieWeb.
You can use https://lastlogin.net to test your client against.
I wrote summary of the FedCM/IndieAuth development:
We got a positive response from the Bluesky team. Discourse would be another major player to help make our case.
Big shoutout to @apitman for being the Indie’s Champion in all of this by engaging in spec discussions and producing real demos in favor of Small Web use cases 
@thisismissem given that you’ve successfully shipped OAuth-related work on a major Ruby codebase, would you perhaps have the bandwidth to take a crack at a FedCM RP plugin for Discourse?
Email me, I guess? emelia@brandedcode.com
Keep in mind my work on Mastodon and the Fediverse is supported by the community and this likely isn’t able to be covered by that so would fall under freelance work for me.
Yeah I think all of us outside Google are working on FedCM on a volunteer basis, but as I said if you don’t have bandwidth for that no worries!
The answer then would be to email me a description of the work, and relevant links, and then we figure out something. Discourse is not something I currently contribute to, and is well outside of the scope of things I normally work on, so it cannot fall under the community funding that I have for Mastodon + the Fediverse.
@thisismissem I was talking to @samuelgoto and he mentioned the idea of implementing FedCM in Mastodon and convinced me it would actually be a much better target than Discourse. Would that change the equation at all for you?
The essence of the motivation behind this from Mastodon’s perspective is:
Every time you’re on someone else’s instance and want to like/follow, rather than having the forsaken “Take Me Home” flow, you could instead have a FedCM login popup that says “Sign in with <your home server account>”. If you click it, the server would be provided all the information it needs to build a redirect URL without you needing to type anything. There might even be a way pass enough of a credential that the request could be processed on the other server, without needing a redirect at all (less sure about that, and it would be more work).
The only action that’s required on your home server is that FedCM will create a popup that asks if the user wants to register it as an IdP, and they have to acknowledge to enable this functionality.
One awesome thing about this is that if we defined a simple FEP for it, it could also work with other apps.
Another nice thing is that FedCM is progressive enhancement. If the user’s browser or instance doesn’t support it, nothing happens. AFAIK this is one of the primary reasons for not implementing protocol handlers: (Use web-based protocol handlers to make following across instances easier · Issue #19679 · mastodon/mastodon · GitHub)
The goal is to implement FedCM in Mastodon, that’s why I co-wrote the OAuth Client ID Metadata Documents internet draft for the IETF OAuth WG; That came out of a discussion I had with Aaron Parecki in May this year about OAuth, OIDC, FedCM and IndieAuth.
I’ve also been quietly participating in the FedCM WG for it’s design.
However, there’s a number of big Mastodon OAuth changes necessary before we go forwards with implementing FedCM, e.g., expiring access tokens, refresh tokens, improvements to the OAuth Application model, improvements to the OAuth Authorization UI, a userinfo endpoint (modeled on OIDC’s).
Additionally we should probably add support for DPoP for the use case of cross domain authentication, i.e.,
This sounds promising! I knew about your work on client metadata but didn’t realize the relation to FedCM.
It does sound like a lot of work for one person. In terms of getting this all implemented, is funding an issue?
Something like this seems like a perfect funding target for the newly minted Social Web Foundation. The follow/react flow is one of the worst UX shortcomings of the Fediverse compared to centralized social media.
Funding is certainly part of the issue, along with the fact that I’ve other projects on-going as well, such as the FediMod FIRES grant I’m currently working on (well, once I get back from sick leave in November). I don’t just work on the Mastodon project, and not just on the OAuth implementation within it.
But yeah, OAuth Client ID Metadata Documents came from Aaron noticing my work on Mastodon’s OAuth setup, where I’ve been trying to pull it closer to standards and removing a lot of the common weird gotchas (e.g., not officially supporting multiple redirect URIs and the lack of discovery), and then going “How can we get FedCM and IndieAuth into Mastodon?”
In that conversation, the big issue was for FedCM you need a client identifier, but in a system that only has dynamic client registration for applications, how do you provide a single client identifier across all authorization servers when each mints their own? That’s where borrowing from Solid’s OIDC specification for client_id as a URI makes a lot of sense, but we couldn’t just use Solid OIDC because it didn’t exist in the context of OAuth, so we needed to lift that up to the OAuth / IETF as a specification.
IndieAuth had solved this by requiring parsing of HTML, which is awkward and slow compared to just parsing a JSON document, so once we started OAuth Client ID Metadata Documents, IndieAuth moved to adopt those.