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?

#ActivityPub #FediDev #RFC9421

@[email protected] by "can't handle" do you mean "still reliant on cavage-12"?

🙋‍♂️

@[email protected] As I understand the migration path, it's like

1. Able to receive RFC 9421 in addition to draft-cavage
2. Able to send RFC 9421 in addition to draft-cavage
3. Send RFC 9421 by default, but be able to fall back to draft-cavage if needed

So by “can't handle” I meant step 1. 🙂 Although the unspoken step 4 is to remove draft-cavage support once everyone else has taken step 1, I'm ultimately also wondering when we'll get there.

@julian @[email protected] Honestly, I think it's going to be a while.

I think the term for step 3 is "double knocking", and it's called out in the HTTP Signature report for the Social CG:

https://swicg.github.io/activitypub-http-signature/

ActivityPub and HTTP Signatures

@evan @[email protected] @[email protected]  I think organizing a contribution event to refactor @peertube/http-signature and golang’s httpsig or gotosocial's fork of httpsig to support both cavage-12 and RFC9421 would go a long way to getting this done sooner as most of the software missing implementation depend on those libraries.

GitHub - Chocobozzz/node-http-signature: Reference implementation of Joyent's HTTP Signature Scheme

Reference implementation of Joyent's HTTP Signature Scheme - Chocobozzz/node-http-signature

GitHub
@mradcliffe The thing about double-knocking is that it requires two implementations (RFC 9421, draft-cavage-12). It also requires a persistent cache, so once you figure out which signature system the remote server supports, you only use that one -- you don't double-knock every time. It might not work as a library.

@evan Thanks for the response. I think how a given software does double-knocking is up to that software. It is not necessarily true that you have to store the result, but it is ideal. I am much too lazy to refactor a persistent cache and I just double-knock every time. :P

But to start, those libraries need to be able to support both signature implementations as those libraries are already in-use by the majority of software that has not implemented RFC 9421 yet.

@[email protected] ah, then no, NodeBB has no support yet. That's true though that there is a step-wise upgrade pattern.

Updating our HTTP Signature lib is part of our grant funded work so it'll get sorted out soon!

cc @[email protected] @[email protected]