Code change:
algorithm FIPS186-4 using curve P-256 with the signer's private signing key and the signature input string (create-sig-input).  The hash SHA-256 RFC6234 is applied to the signature input string to <del> create the digest content to which the digital signature is applied. The resulting signed content byte array is the HTTP message signature output used in sign. </del> <ins> create the digest content to which the digital signature is applied, ("M").  The signature algorithm returns two integer values, "r" and "s".  These are both encoded in big-endian unsigned integers, zero- padded to 32-octets each.  These encoded values are concatenated into a single 64-octet array consisting of the encoded value of "r" followed by the encoded value of "s".  The resulting concatenation of "(r, s)" is byte array of the HTTP message signature output used in sign. </ins> To verify using this algorithm, the verifier applies the "ECDSA" algorithm FIPS186-4 using the public key portion of the verification key material and the signature input string re-created as described in verify.  The hash function SHA-256 RFC6234 is applied to the signature input string to create the digest content to which the <del> verification function is applied.  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  The results of the verification function are compared to the http message signature to determine if the signature presented is valid. </del> <ins> signature verification function is applied, ("M").  The verifier extracts the HTTP message signature to be verified ("S") as described in verify.  This value is a 64-octet array consisting of the encoded values of "r" and "s" concatenated in order.  These are both encoded in big-endian unsigned integers, zero-padded to 32-octets each.  The resulting signature value "(r, s)" is used as input to the signature verification function.  The results of the verification function indicate if the signature presented is valid. Note that the output of ECDSA algorithms are non-deterministic, and therefore it is not correct to re-calculate a new signature on the signature input and compare the results to an existing signature. Instead, the verification algorithm defined here needs to be used. See security-nondeterministic. </ins> Use of this algorithm can be indicated at runtime using the "ecdsa- p256-sha256" value for the "alg" signature parameter. 3.3.5. <ins> To sign using this algorithm, the signer applies the "Ed25519" algorithm RFC8032 with the signer's private signing key and the signature input string (create-sig-input).  The signature input string is taken as the input message ("M") with no pre-hash function. The signature is a 64-octet concatenation of "R" and "S" as specified in RFC8032, and this is taken as a byte array for the HTTP message signature output used in sign. To verify using this algorithm, the signer applies the "Ed25519" algorithm RFC8032 using the public key portion of the verification key material ("A") and the signature input string re-created as described in verify.  The signature input string is taken as the input message ("M") with no pre-hash function.  The signature to be verified is processed as the 64-octet concatenation of "R" and "S" as specified in RFC8032.  The results of the verification function indicate if the signature presented is valid. Use of this algorithm can be indicated at runtime using the "ed25519" value for the "alg" signature parameter. 3.3.6. </ins> If the signing algorithm is a JOSE signing algorithm from the JSON Web Signature and Encryption Algorithms Registry established by RFC7518, the JWS algorithm definition determines the signature and

Related discussion:
text: Adds text to clarify algorithms in several places: encode ECDSA signature as raw bytes, mark ECDSA and RSAPSS as non-deterministic note non-determinism of ECDSA and RSAPSS in examples, add security consideration of nondeterministic algorithms. Add ed25519,
NAME and NAME : this PR updates the text around non-deterministic algorithms and how to match them, please take a look. It also is more explicit about encoding the ECDSA signature as a raw byte array (as was indicated on the list).
It's been a very long time since I added the RSA signature test vectors to the appendix of the HTTP Signatures spec. We should replace them with more modern examples. My suggestion would be to use ed25519 examples, or secp256r1 (P-256) examples. The former would need a , which would be a good thing.
We should add new examples, not remove ones that are there and are functional. All of the test vectors in the spec have been re-generated from scratch in the latest draft, so none of the older tests should still be in the draft at this point.
Additional tests for HMAC and ECDSA were added in
Keeping this issue open as a call for adding support for Ed25519 and others.
Ed25519 support seems to have been implemented in the wild by libraries like URL and URL Tagging an implementor: NAME could you help define the parameters for Ed25519 support in the core spec?
You can do HTTP message signing with profile and key management using (a Rust programming language with Lua scripting) and its Content Management System, (aka Lighttouch). The crypto implementation is in its and , and database is in . has a refined basic example to see how it works. I'm working on a web site for URL with installation instructions, a getting started guide, organized documentation links, and example projects. If you need any help, I'd be happy to answer your questions.
I've implemented what I think is a reasonable version of Ed25519 using pynacl and added it to the demo generation script, if someone else can confirm this code and its results that would be best. I had to do a lot of unpacking of the key values by hand because support wasn't natively there in the libraries I could find. URL NAME perhaps?