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.
Feed RSS
Gli ultimi otto messaggi ricevuti dalla Federazione
-
@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.
-
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 alsorequired signed fields: @method, @target-uriif a query is present, require: @queryfor POST, also require: content-type, content-digestadvertise support using FEP-844e on the server actorsignatures must use public keys from FEP-521a (“assertionMethod”)signatures must have a “recent” (one hour?) “created=” time, since this is a transport signaturesignatures may use the server actor key if a FEP-8b32 object proof is presentI’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.