I would like to see a universal login option and remote authentication added so I don’t have to create and manage multiple accounts on multiple platforms. And preferably a passwordless remote authentication option. The Zot6/Nomad protocol does this, but it doesn’t seem very popular.
They both are about the same thing but have different replies. Since they are not on the same platform, I have to create yet another account on yet another server.
Federated islands talking to each other is nice, but a universal login that works on any website would be even better.
Agreed on the importance of this, @WisTex. Whatever people think of Twitter BlueSky (lotsa justified criticism), they identified this as a key requirement to be tackled first.
A very interesting read. It clearly is designed to mitigate the controversy regarding social media content moderation by allowing users to self-moderate based on flagged content. And it is designed for “big data” which isn’t a bad thing, but it adds a lot of complexity and overhead.
There are some major differences, such as using a DID, but they are using a lot of concepts from Zot/Nomad. It should be interesting to see what they come up with.
Also, their spec assumes you will be using it for social media services, which means it is not really a universal ID. Although, I am sure it could be adapted to work as one.
This is the Client-to-Server portion of the specification.
Unfortunately people started to build only Server-to-Server with own APIs and servers.
The idea is that you have a generic ActivityPub Homeserver (a “LD inbox” with defined semantics) and very diverse clients to feed it.
And then see
[edit: what Aaron describes in min. 11 ff. would even be much better if browsers care for Open Protocols, than the handle would be stored in the browser by registerProtocolHandler – but this needs political force against Apple and google and we are on the way, browsers are already named critical in the EU DSA …]
or
and in case it would be needed for account migration and such things, alsoKnownAs was specified but the state of DID is a bit uncertain.
Solid, which is similar to ActivityPub in the sense that it aims to build a decentralised web and that it uses linked data to achieve this, have a (draft) spec on Solid-OIDC, which essentially combines OIDC with the provision of a “Solid pod”, a resource server holding linked-data controlled by the user (to hold their user data). This allows single-sign-on and portability of data between apps (interoperability)
The ideas of the Solid Pod, linked-data inboxes and users controlling their identities seem to combine really well - however the main caveat with Solid (AFAIK) is that they are using WebACLs, whilst I’ve seen interest in ActivityPub to use capabilities instead