cross-posted from: https://lemmy.world/post/10918621
Reason: wrong community
Work in Progress: Adding more details on the motivation
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!
As far as I know, most activitypub traffic is server to server. There are few, if any, activitypub clients - they use APIs instead. So there’s a Lemmy API, a Mastodon API, etc that apps use.
ActivityPub as a client-server protocol. Very few servers implement it, and seemingly even fewer apps support it.
The problem with writing these apps is that the AP spec indicates that OAuth bearer tokens are a supported method of authentication, but doesn’t specify how you would get those tokens. You can use the Mastodon API to generate an OAuth2 token, but then an app would need to specifically implement “Mastodon oauth” (and the callback URL would need to be supported on the server as well).
Of course there are alternative methods (HTTP Basic, client certificates, you name it) but there’s no way of knowing what kind of authentication a server requires if you just enter a domain. I suppose you could do standard OpenID lookups to find the addresses of simple OAuth login flows, but the ActivityPub spec mandate that, so everyone is free to implement their own special auth flows.
Maybe is because I am not native but I did not get it
Like, to me looks like a further reason to transition to a serverless authentication
I don’t think anyone maintaining ActivityPub actually monitors this community. You should try looking over at https://www.w3.org/wiki/SocialCG and see if you can find the right place to talk about your proposals.
Been thinking about something simmillar. As long as i have a private key on my own machine with total control of my shit im happy. Seperating the identity from the server solves so many issues.
