sha2 needs to reflect the actual JWS payload in signatures

[AndreusUltimus]

Are you just blatantly abusing JWS to get a signature?

In ALL of the tests of signatures, the exact same "sha2" hash value is used. The JWS provided by the test client completely ignores the JWS payload.

Which begs the question: why are you providing/mandating a hash at all? It is standard practice, which could be specified in the spec, to require the JWS payload to be hashed before computing the signature. This complicates the protocol (by requiring the "sha2" property and the -Experience-API-Hash header) or uses a bloated protocol (JWS with the encoded payload, which itself is a copy of information that should be in the non JWS payload), or hacks the protocol to ignore the middle portion.

By the way, and in several places in the xAPI-Spec, specifying SHA2 is insufficient information. WHICH SHA2 hash is/should-be used?

[adl-trey]

Morning Andrew,

Attachments each have their own hash, but the X-Experience-API-Hash header isn't present on the statement payload itself. Per the spec:

The multipart/mixed content type is used for requests that could include Attachments.

There's also a fairly wordy bit in the transmission section of the spec. Notably, those multipart/mixed parts:

MUST include an X-Experience-API-Hash parameter in each part's header after the first (Statements) part.

So there isn't really a question of "which hash do I use", as anything that has its own hash also has its own section of the multipart request (including statement signatures themselves).

[AndreusUltimus]

So, I retract my previous irritation. Turns out I was just dealing with the subtleties of the payload signature sign/verify process.

I also withdraw my comment about the sha2 algorithm, turns out I'm bad at noticing when the search results are paginated (search this repo for "sha2" and you get a lot of copies of the test attachment sha2, which is hardcoded and copied everywhere, and not until page 2 do you get the sha2 computed for the "signature" test attachment, which is computed live and not pre-generated).

HOWEVER. My comment about "which sha2 algorithm" still holds. Not all attachments will contain a hash algorithm; what does it mean for a PDF or PNG file? It is only accidentally meaningful for the signature attachments, which must internal to the JWS structure choose a hash.

Note also that in the tests, the "sha2" property is hard-coded to use SHA-256, ignoring the options.algorithm property used for signing:
helper.js, line 908 as of writing