snarfed
commented
8 months ago Initial draft text below. Please review and revise!
The ActivityPub standard mentions authentication (and authorization), but mostly omits any specific needs or use cases for them. Over time, two clear uses for authentication have emerged in the fediverse.
The first is proving and verifying that a given user created a given piece of data or performed a given action. This is the classic attribution problem in identity-based networks. (Note that this is separate from authorization or access control, ie determining whether a given user is allowed to access a given piece of data or perform a given action.)
At a baseline level, this works. HTTP Signatures attached to ActivityPub inbox delivery requests can effectively verify the actor - or at least the server - who sent them. However, these HTTP Signatures are ephemeral. They only authenticate HTTP requests, not actual data. We'd often like to authenticate objects and activities in ActivityPub outside of inbox delivery requests, eg during inbox forwarding, or after they were initially created. HTTP Signatures can't do this.
The second use case for authentication is access control, specifically whether to serve an ActivityPub GET request for a given AS2 object or activity. Fediverse users and servers routinely block other remote users and servers, and they then try not to serve requests for data from those users. They generally use HTTP Signatures to identify the remote user making the request. This technique is known as authorized fetch.
Fediverse servers prevent interactions from blocked users/servers via the first use case above: they use HTTP Signatures to identify the remote user, then check if they're blocked. This works, more or less.
However, as a mechanism for controlling access to data, HTTP Signatures are only minimally effective, at best. Data that's truly non-public, eg direct messages and followers-only posts, are only delivered to the intended recipients, which their servers then control access to. This matches the fediverse's server-centric security model.
Otherwise, for public data, HTTP Signatures and authorized fetch are not an effective way to block access to specific users or servers. Fediverse servers generally serve public data over the web freely, for anyone to see without logging in or fetching via ActivityPub or HTTP Signature. We've also seen techniques for circumventing authorized fetch by laundering requests from blocked servers with signatures from other "clean" (non-blocked) server domains.
The conclusion seems to be that HTTP Signatures do serve real current use cases in the fediverse, somewhat, but they're limited, and not (yet) a solid basis to build a complete authentication and authorization solution on top of.
My bias is that they provide decent basic client authentication for inbox delivery, to match the SSL-based server authentication. Authorized fetch, on the other hand, I think adds only minimal privacy/blocking support, at best. 😁