HTTP Signatures in ActivityPub - non normative & best practice

Last updated in 2017, the ActivityPub wiki provides provides a hint about the implementation of HTTP signatures in S2S communications. There are various ad-hoc implementations in bookwyrm, pagure or go-fed. It is unclear how the compatibility between them can be verified: that would require an embedable test environment similar to the go-fed testsuite.

For some reason (maybe because the message below references it), the http signature draft spec is the “cavage” variant although there is a more recent version that is is not authored by an individual. It is unclear what the differences are.

Signing requests using HTTP Signatures

Server to server federation is authenticated using HTTP Signatures in conjunction with the signing key from the actor’s publicKey field. The keyId should link to the actor so that the publicKey field can be retrieved. At minimum, the digest field should be included in the set of headers being signed.

https://www.w3.org/wiki/SocialCG/ActivityPub/Authentication_Authorization#Signing_requests_using_HTTP_Signatures

There is a plugin for DRF that would nicely abstract the logic from the fedeproxy logic, but it has not been updated in seven years and is therefore unlikely to work out of the box with the more recent versions. Another option would be to do something similar to pagure and use requests-http-signature to abstract some of the logic.

It should be possible to re-use the key storage in GitLab and not implement an endpoint to get the public key.

curl https://lab.fedeproxy.eu/api/v4/users/dachary/keys | jq .

It is however not possible to ask GitLab to generate the key nor to store the private key.

In Gitea, accessing the user public key requires an access token.

The django request object has a header attribute that should be all the verify method needs.