Episode 109 - GluuFederation/identerati-office-hours GitHub Wiki
Title: Federation Challenges of BlueSky and Mastadon
- Host: Mike Schwartz, Founder/CEO Gluu
- Guest: Aaron Parecki, Director of Identity Standards at Okta
Channels
Description
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?
Homework
More links from the show:
Follow aaron on Mastodon: https://aaronparecki.com/@aaronpk or BlueSky: @aaronpk.com
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.