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: Script output: Base String: Signature:
I am just in the process of pulling out my implementation of Signing HTTP Messages to its independent repository . But I can check that the signatures work in JS and Java for ...
After asking around, I've updated the code to run a SHA-512 hash on the input base string before feeding it to the signer, to have some things to compare to. This results in the following signature instead, with all other parameters being the same: This simple change is in URL
After even further investigation, I'm still not sure whether the pre-hash is really the right approach here or not.
Would having other implementations help decide this? (I have not gotten round to it trying an implementation) What is it that is making you undecided? (Perhaps knowing that could help me give you an answer by implementing)
Other implementations are always welcomed. What's getting me right now is that I can't see if it's necessary or expected with Ed25519, as it would be with other signature schemes like RSA or ECDSA.
To my knowledge, the pre-hash variant of Ed25519 is not very well supported relative to the "pure" variant.
In Java I found the following: In the Java Web Crypto API I found a proposal to from Feb 2020. I found an issue in Chrome's Blink-dev which linked to an issue . From that it seems that there is no built in implementation in Browsers. It seems people have been building their own implementations in JS. There are implementations such as aimed at URL But I can't tell which are well built, or not. So that means that on the JS side there is quite a lot of work to do. So that is something to keep in mind when developing ...
/cc NAME -- I know we've had this discussion w/ a number of vendors, where did we end up -- what seemed to be the most "used by default" approach for EdDSA w/ Ed25119?
This code from the RFC shows that there's an internal hash in the algorithm applied to the message: URL This is true whether PH(M) is a SHA function or an identity function, so I'm now really not seeing the value in having PH(M) be an additional hash.
I got NAME first signature above to work in Java with this commit: URL That did not require me to set any hash.