Particularly wedded to MD5, or something more modern/secure okay? SHA-2?

I wonder if we can align with the W3C's Subresource Integrity specification. Perhaps we add an "integrity" member to the manifest? And then use algo+hash as in the spec?

{
            "type": "LinkedResource",
            "url": "fonts/STIXGeneral.otf",
            "encodingFormat": "application/vnd.ms-opentype",
            "integrity": "sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd"
        }

Can you give some details? Do you store a hash for each resource separately, or one global hash (some sort of a merkle tree)?

B.t.w., this should probably be a 'core' manifest feature and not audio specific.

Can you give some details? Do you store a hash for each resource separately, or one global hash (some sort of a merkle tree)?

See https://github.com/blackstoneaudio/audiobook-spec/blob/master/draft.yaml

@GarthConboy We use MD5s because they are cheap to compute, and they are used for download validation not security. Same purpose as 'eTag' keys in S3 or equivalent.

We use the word 'md5' as the key, but anything equivalent (hash, checksum, etc) would be fine, as long as we know what it is. For us the string value would be an MD5. For others it could be anything.

@dauwhe That seems very reasonable to me.

@iherman We store a hash for each resource separately see https://github.com/blackstoneaudio/audiobook-spec/blob/cfd468bb27b890b0e4a59a3345e806221a702fce/draft.json#L59

We do also store a 'hash of hashes' which we use as a sort of 'version' see https://github.com/blackstoneaudio/audiobook-spec/blob/cfd468bb27b890b0e4a59a3345e806221a702fce/draft.json#L11

Is there anything in schema.org that we could use for that?

I don't think that we should be tied to any specific algorithm, which potentially means:

• identifying the algorithm that we use (URI)
• plus providing the value of the hash (string)

Please use the Subresource Integrity syntax. The last thing we need to add to the web platform is yet another way to compute, store, and parse hashes. Use the platform, use existing mechanisms rather than inventing new ones.

Also, just because your current use isn't thinking about security doesn't mean future uses wont. Adding weak hashes is doing a disservice to future users.

@HadrienGardeur

Is there anything in schema.org that we could use for that?

I haven't found any... :-(

I am fully on board with using the algo+hash syntax from the Subresource Integrity spec, per Dave's suggestion.

One question looking at how to integrate this: given that we aren't restricted to an HTML attribute, how do we handle the ability to define multiple hash expressions for each resource? Do we:

1. restrict wpub to a single hash expression to keep things simple;
2. use spaces to delimit each to remain consistent with SRI; or
3. allow an array of values, where each value is one hash expression?

I think [1] is too limited. [2] has the advantage of being consistent with SRI

"integrity: "sha384-dOTZf16X8p34q2/kYyEFm0jh89uTjikhnzjeLeF0FHsEaYKb1A1cv+Lyv4Hk8vHd
              sha512-Q2bFTOhEALkN8hOms2FKTDLy7eugP2zFZ1T8LCvX42Fp3WoNr3bjZSAHeOsHrbV1Fu9/A0EzCinRE7Af1ofPrw=="

Not sure about [2] vs [3].

Not sure about [2] vs [3].

Ya, this is the particularly tricky thing to answer. We don't have to use whitespace to delimit, but SRI is defined with that expectation. It feels like we should seek input from that spec's authors.

I guess I lean towards [2] both because of consistency, and because it's way easier to type a space then create an array in JSON. Consider users over authors over implementors over specifiers over theoretical purity ;)

I agree with @dauwhe's reasoning. In addition, if you use a json array, then you either have to always use an array (even for one value, which is likely to be the most common case, putting an additional burden on authors), or give users the burden of testing for string vs array values.

Keeping it entirely consistent with SRI also makes it easier to copy values between the manifest and an attribute should the need ever arise. It also allows the wpub manifest spec to simply refer to the SRI spec and avoid re-specifying something potentially introducing inconsistencies as each spec evolves.

This issue was discussed in a meeting.

• RESOLVED: add the optional integrity property for linked resources, using the subresource integrity format

@llemeurfr asked, during the meeting (quoting the minutes):

Laurent Le Meur: … I’m worried that some user agents might not be able to deal with any algorithms that is expressed
… is there a closed list of algorithms?

The SRI recommendations says in 3.2:

Conformant user agents MUST support the SHA-256, SHA-384 and SHA-512 cryptographic hash functions for use as part of a request’s integrity metadata and may support additional hash functions.

Though we refer to SRI normatively, i.e., we inherit this list, it is probably worth calling this out in our document as well.

Cc @mattgarrish

Though we refer to SRI normatively, i.e., we inherit this list, it is probably worth calling this out in our document as well.

I'd prefer to avoid duplicating the requirement, if that's what you mean. We can refer across to the list, of course, but once we replicate the statement we put ourselves in the position of falling out of synch.

@mattgarrish I agree, and I did not mean to repeat the list. Just put a note in the text that there is such a list, with a reference to the Rec.