I agree that there are a lot of design flaws in the old protocol, but the problem is, there is no logical path forward for ActivityPub implementations to support both versions at once.
And what happens if it changes again?
Why did the new draft not acknowledge that it broke current implementations and provide this advice?
Why should we not just fork HTTP Signatures and introduce our own X-ActivityPub-Signature header?
It is possible to make changes without breaking the consumers you asked 6 months ago to write into the IETF letting them know about our usage. Instead, as a thank you to anybody who did that, we get hit with a draft that completely breaks us.
I’m bumping this from last year as we’re starting to see a lot more hs2019 in the wild and I’ve only seen one implementation besides our own that supplies the algorithm in the actor record.
I agree this may be the best option, but the sec LD context turns signatureAlgorithm into sec:signingAlgorithm so we accept both; even though one or the other might have an issue with LD-signature normalisation. I haven’t had the time to check this; so in the meantime I’ve instituted a fallback to look for sigAlgorithm at the top of the actor record with any context. I’m hoping I won’t need to use this, but have allowed for it just in case LD signatures start failing.
And just because tracking through the relevant specifications is a hard slog, we will fall back to rsa-sha256 if we couldn’t find anything in the actor record.
They key here is to be liberal in what you accept and conservative in what you generate.
I’m not yet certain what to do about the conflicts in ietf-httpbis-message-signatures and the implementation seems quite heavy so I personally plan to wait for it to evolve a bit more before supporting it.
We will switch “soonish” to sending hs2019; as it appears to be close to a critical mass of support. But I’d like to see a few more projects providing sec:signatureAlgorithm instead of just assuming that hs2019 == rsa-sha256. It does not. I think the only way that developers are going to get the message is if/when somebody switches their preference intentionally to rsa-sha512 and starts filing bugs.