The ActivityPub specs mentions the possibility to use a proxyUrl to make requests to remote servers:
Endpoint URI so this actor’s clients may access remote ActivityStreams objects which require authentication to access. To use this endpoint, the client posts an x-www-form-urlencodedid parameter with the value being the id of the requested ActivityStreams object.
I’ve been using this for the ActivityPods project and it’s working fine. Basically, all requests to remote servers are done through this endpoint. The request is forwarded to the remote server, adding a HTTP signature which signs the message with a public/private keys mechanism, that the remote server can easily verify the WebACL rights on the resource (the actor’s public key being attached to the its profile)
I’m wondering if there are security concerns which prevent to use this everywhere ? Isn’t it a simple and elegant way to authentify users accross as many servers as we want ? I find the Solid-OIDC spec difficult to implement, while with this proxy solution, users can create POD accounts however they like, and still be recognized by remote servers.
The only thing missing in the above ActivityPub spec is the possibility to handle POST, PUT, PATCH and DELETE methods. But it’s possible to adapt it for such cases, it’s just an API. However I would like to make sure I’m not missing something before implementing this solution…
That seems very close to what I demoed recently at the Solid Community Group last week. Doing HTTP Sig authentication via your POD proxy seems like the right idea to me. One could also do it via the client. But I agree with you it is a lot more efficient.
It would be interesting to get your feedback on the HTTPSig spec that I am writing up here (I will put some more work into this very soon, after having collected the experience from my recent work)