I have this proposal for ActivityPub
NOTE: This proposal is based on https://www.w3.org/TR/activitypub/#authorization and https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization consulted on 06 January 2024.
- Considering that the entire section on safety considerations is presented as non-normative
- Given that "at the time of standardisation there are no strongly agreed mechanisms for authentication. " as per the above reference
- Assuming that the ultimate goal is to have a decentralised, persistent and verifiable identity.
Premise: The following proposal represents a radical and potentially disruptive change to the current ActivityPub specifications. In particular the following parts:
- ActivityPub clients authenticate to a server using OAuth 2.0 bearer tokens.
- Related OAuth considerations
It is also important to note that the following proposal can coexist with current OAuth authentication.
The proposed encryption algorithm (ED25519) can and should be updated in the event of a vulnerability or major upgrade.
Suggestion
I have no idea how to write a document like this correctly, and I am probably doing it wrong, but my only goal is to stimulate discussion.
The proposal is as follows.
ActivityPub clients authenticate against a server using ED25519 signatures In general, bearer tokens can be easily replaced by signatures in almost every aspect. Advantages:
- Servers don’t need to store anything other than a session token.
- Authentication is decentralised and context independent
- Your key is your identity: no server breach can expose your data
- There are mature libraries like node-forge (for nodeJS and TS) and many others that allow easy implementation of authentication.
I have tried to think about possible downsides, but the goal of this post is to stimulate discussion, please keep it respectful, but of course criticism and additions are welcome!
Nice post, thanks. What I feel is missing is the reason for the proposal. Currently, I have no context of what it should replace or improve or what the motivation of the suggestion is. I think you should add a section of “how is the situation currently” and “what should be improved and why”.
Will do, thanks! The main reason is to solve the following “problem”: in a decentralized protocol like ActivityPub I (personally) find very weird that accounts are bound to a central instance. I have like 6 “thecookingsenpai” accounts across instances (I of course use only one of them but you get the idea) and if by disgrace lemmy.world collapses overnight I could not log in with my account elsewhere.
How are the accounts bound to a central instance when you have accounts on many instances? Sorry if I don’t understand…
My account https://lemmy.world/u/thecookingsenpai is not the same as https://lemmy.ml/u/thecookingsenpai or any other instance. Thus, each account is bound to the instance it was created on, although it can interact with other instances
(aka if lemmy.today disappears you would have no account to log in with)
Wrong community. OP, please repost in !fediverse@lemmy.world
I’m a developer and I use OAuth 2.0 for work but half of this is Greek to me. You should post in a developer forum instead of general Ask Lemmy.
True, I just wanted to be more generic before going technical (this is very vague from a tech point of view so i was testing how the idea could be reacted)
You should explain the problem you’re trying to solve instead of diving into your proposed implementation.
Will add, you are totally right
You need to start with an elevator pitch. Like 2 sentences in simple words saying what the problem is that you’re trying to fix, and what your proposed solution is. Like for the fediverse it would be something like this:
It sucks that a place like reddit can totally change how their website works after millions of people spent so much time and energy making it a great place. But with the fediverse, communities are distributed among many different websites, so no single website can destroy the community later after people built it up.
Woah, nope. Thanks, digging in it!
