Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
-
RE: https://mastodon.social/@bagder/116359048796181736
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
Hi @julian @fedify,
#complexity benefits the big players. That's huge harm to diverse #federation. Challenge it, refuse it, stop it. -
RE: https://mastodon.social/@bagder/116359048796181736
Could be potentially nice for fediverse server testing, as more implementations make the jump to final RFC 9421 HTTP signatures.
On the flip side, ever more complex curl invocations (here: Accept header plus signature fields plus key file, presumably) suggest use of more specialized CLI tools, such as provided by @fedify, or at least scripts/aliases.
Speaking of RFC 9421, which notable fediverse implementations can't handle it yet? Anyone keeping track?
-
@evan Great work!
-
@evan Great work!
@julian I started a conversation on public-swicg about doing a new version of the HTTP Signature report.
https://lists.w3.org/Archives/Public/public-swicg/2026Apr/0013.html
-
@julian I started a conversation on public-swicg about doing a new version of the HTTP Signature report.
https://lists.w3.org/Archives/Public/public-swicg/2026Apr/0013.html
@evan while perusing the spec, I realized that an implementation doesn't really need double knocking at all.
Any implementation can just stuff two Signature headers in there, one for the cavage v12 version, and one for RFC9421, and requests should still be valid.
Can anyone trust cavage HTTP signature verifiers to not break on this: no, probably not...
-
@evan while perusing the spec, I realized that an implementation doesn't really need double knocking at all.
Any implementation can just stuff two Signature headers in there, one for the cavage v12 version, and one for RFC9421, and requests should still be valid.
Can anyone trust cavage HTTP signature verifiers to not break on this: no, probably not...
-
Hi @julian @fedify,
#complexity benefits the big players. That's huge harm to diverse #federation. Challenge it, refuse it, stop it. -
-
-
Hi @evan
regarding 'keeps things simple' - have you looked into #RFC9421?
(Looking at you, Innerlist https://doi.org/10.17487/RFC9421)All this #complexity for what benefit?
P.S.: I don't consider #ActivityPub to be simple in the first place, so hard to keep it simple that way.
-
Hi @evan
regarding 'keeps things simple' - have you looked into #RFC9421?
(Looking at you, Innerlist https://doi.org/10.17487/RFC9421)All this #complexity for what benefit?
P.S.: I don't consider #ActivityPub to be simple in the first place, so hard to keep it simple that way.
Yes, I just finished implementing it.
I agree, HTTP Message Signatures aren't simple.
Sticking with one spec as long as possible and swapping to the other when you need to is the simplest strategy to manage that transition.
-
@mro @julian @fedify for server-to-server authentication, I think there are other mechanisms that could be simpler.
My friend @blaine says that if you get to PKI, you've gone too far, and you need to look for other options.
For pump.io, I used two-legged OAuth, which was pretty nice. I kick-started it with a dialback mechanism:
https://datatracker.ietf.org/doc/html/draft-prodromou-dialback-00
I also think mutual TLS would be a good option.
-
-
-
@julian@fietkau.social @fedify@hollo.social @evan@cosocial.ca
If you send me the part of send signature code that would bee neat
#Thankss -
@julian@fietkau.social @fedify@hollo.social @evan@cosocial.ca
If you send me the part of send signature code that would bee neat
#Thankss -
Here's the code that does the double-knock. Between the caching, rate limit throttling, and double-knocking it's a real bear to read, though.
https://github.com/evanp/activitypub-bot/blob/main/lib%2Factivitypubclient.js#L90
-
@evan you mean, if you cache the one that worked? Sadly I don't have that available to me directly in GoActivityPub... Of course one might add support for that, but there isn't a straightforward way to introspect which knock worked for a specific request. Maybe something I need to add to my todo list...
-
@evan you mean, if you cache the one that worked? Sadly I don't have that available to me directly in GoActivityPub... Of course one might add support for that, but there isn't a straightforward way to introspect which knock worked for a specific request. Maybe something I need to add to my todo list...
-
Hi @evan
regarding 'keeps things simple' - have you looked into #RFC9421?
(Looking at you, Innerlist https://doi.org/10.17487/RFC9421)All this #complexity for what benefit?
P.S.: I don't consider #ActivityPub to be simple in the first place, so hard to keep it simple that way.
P.P.S. My latest blog post about #ActivityPub fediverse contains a "Back to (potentially radical) simplicity" call-to-reflection (among other subject matters) .. https://social.coop/@smallcircles/116368803389082089
Solution is.. difficult, but simple, yet not easy.
Hello! It looks like you're interested in this conversation, but you don't have an account yet.
Getting fed up of having to scroll through the same posts each visit? When you register for an account, you'll always come back to exactly where you were before, and choose to be notified of new replies (either via email, or push notification). You'll also be able to save bookmarks and upvote posts to show your appreciation to other community members.
With your input, this post could be even better 💗
Register Login