Populates the algorithm Signature Parameter based on which Signer is used.

[JackSullivan]

Currently the code uses a hardcoded value for the default signer, which means that attempting to use RsaSha256Sign as a signer produces an invalid authorization header. This PR attempts to fix that by adding a name method to HttpSignatureSign and implementing it with the name literal string passed to the macros. This is the correct value for rsa-sha signing, but may not be correct for hmac. I'm happy to make changes as necessary.

[paulyoung]

I thought the motivation for introducing hs2019 was to hide the algorithm from the signature.

[thomassa]

@paulyoung is right: that's what it says in https://datatracker.ietf.org/doc/html/draft-cavage-http-signatures-12

That draft has been replaced by a series of others. The latest is from early May 2023 and it no longer mentions algorithm hs2019, but instead uses meaningful algorithm-names, thus no longer trying to conceal the choice of algorithm.

Therefore this pullreq might be useful if/when this repository is updated to implement the latest draft of the standard (or ideally the final version, once the standard is no longer a draft).

[paulyoung]

@thomassa, in case you’re interested –

I was using @dskyberg's fork and then made some further additions.

[paulyoung]

@thomassa, in case you’re interested –

I was using @dskyberg's fork and then made some further additions.

I think the most interesting commits are:

• Use time provider when validating date
• Don't compute a digest when the body is empty
• Consider leeway when comparing created and expires