RFC 9421 HTTP signatures in 2026
-
Now that RFC 9421 has been published and is no longer a draft, I think it would be a good idea to write a FEP (or other document) with implementation recommendations, to ensure interoperability between AP servers. The RFC describes how to create and verify signatures, but it’s still up to us to define things like the required fields to be signed, which algorithms are likely to work, and how to discover servers that support it.
I believe HTTP signatures are still useful even with FEP-8b32 object signing, because they prove the authenticity of the origin server. That can be used to implement federation policies on private networks (not connected to the wider “fediverse”), or as a basis of trust before even parsing the AP object body. FEP-8b32 proofs validate the activity object itself and remain with the object as it traverses the network; HTTP signatures validate each link at the transport layer.
Also, I think it’s fine & good for the popular servers (mastodon, misskey, gotosocial, …) to wait for smaller servers to shake out interoperability first. It’s easier for the small servers to iterate and debug. Once we have something working, the more popular servers can implement our consensus requirements with a higher confidence it will “just work”.
Silverpill, in a separate thread, pointed me to a list of tootik’s HTTP signature requirements (here: https://github.com/dimkr/tootik/blob/d6fecfefd80a445b27f589250bb19ebcd95acee2/FEDERATION.md#http-signatures) and I think they make a good starting point, so I’ll kick off discussion with a lightly modified version:
- require ed25519, recommend rsa-v1_5_sha256 also
- required signed fields: @method, @target-uri
- if a query is present, require: @query
- for POST, also require: content-type, content-digest
- advertise support using FEP-844e on the server actor
- signatures must use public keys from FEP-521a (“assertionMethod”)
- signatures must have a “recent” (one hour?) “created=” time, since this is a transport signature
- signatures may use the server actor key if a FEP-8b32 object proof is present
I’ve implemented a first draft of this in squidcity, and I’m excited to try it out with other small servers to see what works.
-
Now that RFC 9421 has been published and is no longer a draft, I think it would be a good idea to write a FEP (or other document) with implementation recommendations, to ensure interoperability between AP servers. The RFC describes how to create and verify signatures, but it’s still up to us to define things like the required fields to be signed, which algorithms are likely to work, and how to discover servers that support it.
I believe HTTP signatures are still useful even with FEP-8b32 object signing, because they prove the authenticity of the origin server. That can be used to implement federation policies on private networks (not connected to the wider “fediverse”), or as a basis of trust before even parsing the AP object body. FEP-8b32 proofs validate the activity object itself and remain with the object as it traverses the network; HTTP signatures validate each link at the transport layer.
Also, I think it’s fine & good for the popular servers (mastodon, misskey, gotosocial, …) to wait for smaller servers to shake out interoperability first. It’s easier for the small servers to iterate and debug. Once we have something working, the more popular servers can implement our consensus requirements with a higher confidence it will “just work”.
Silverpill, in a separate thread, pointed me to a list of tootik’s HTTP signature requirements (here: https://github.com/dimkr/tootik/blob/d6fecfefd80a445b27f589250bb19ebcd95acee2/FEDERATION.md#http-signatures) and I think they make a good starting point, so I’ll kick off discussion with a lightly modified version:
- require ed25519, recommend rsa-v1_5_sha256 also
- required signed fields: @method, @target-uri
- if a query is present, require: @query
- for POST, also require: content-type, content-digest
- advertise support using FEP-844e on the server actor
- signatures must use public keys from FEP-521a (“assertionMethod”)
- signatures must have a “recent” (one hour?) “created=” time, since this is a transport signature
- signatures may use the server actor key if a FEP-8b32 object proof is present
I’ve implemented a first draft of this in squidcity, and I’m excited to try it out with other small servers to see what works.
@robey there's a task force for HTTP Signature in the SocialCG:
https://swicg.github.io/activitypub-http-signature/
It would be cool to do a revised report, or a new report, for supporting the published version of HTTP Signature and especially for smooth transition from draft-cavage-11.
Ciao! Sembra che tu sia interessato a questa conversazione, ma non hai ancora un account.
Stanco di dover scorrere gli stessi post a ogni visita? Quando registri un account, tornerai sempre esattamente dove eri rimasto e potrai scegliere di essere avvisato delle nuove risposte (tramite email o notifica push). Potrai anche salvare segnalibri e votare i post per mostrare il tuo apprezzamento agli altri membri della comunità.
Con il tuo contributo, questo post potrebbe essere ancora migliore 💗
Registrati Accedi