Episode 109: Federation Challenges of BlueSky and Mastadon

Federated social networks are trying to solve some interesting dynamic trust challenges. On a monolithic social network, re-posting a person's message is easy--both the author and re-poster have identities on one central system. But how do I re-post a message to my feed, if the author's account resides on another federated node? Dynamic client registration presents a part of the solution. But how can we avoid duplicate client registrations?

#Speakers

• Host: Mike Schwartz, Founder/CEO Gluu
• Guest: Aaron Parecki, Director of Identity Standards at Okta

#Homework

• BlueSky OAuth Client Implementation
• Mastadon Thread about DCR challenges
• OAuth Client ID Metadata Document Draft
• IETF 121 Slides
• IETF 122 Slides

#Takeaways

• It's the mobile and web clients of end users that raise issues for dynamic client registration in Bluesky and Mastodon federations. These are in general untrusted public clients, registering without a software statement (or other token) to convey trust.
• Use of a metadata URI for the purpose of client identity makes sense--this way the client can specify where it stores its keys, and other metadata (what scopes it needs).
• Bluesky uses very advanced OAuth features, like DPoP and asymetric client authentication.
• If these are untrusted clients, they don't have a lot of long term value. Without a software statement presented during registration, there is not any information you can trust. It's hard to map any meaningful policy to client data--so if you never use the client info for security, you should aggressively vaccuum inactive clients.