Unify cryptographic hash expression formats

[msporny]

The specification currently contains a section related to the integrity of related resources. There are two approaches that the WG is considering: digestSRI and digestMultibase.

This issue tracks the benefits and drawbacks of using either approach, or both approaches simultaneously, in the hope of unifying the approach taken across all specifications produced by the Working Group.

[msporny]

The following is an attempt to summarize the arguments for and against the three options the group is contemplating:

Option A: Use digestSRI

This option chooses to use the same subresource integrity syntax that is used in the Subresource Integrity specification, which re-uses the primitives in Content Security Policy Level 2.

Benefits

• The syntax is already defined in SRI and CSP2.
• The algorithm header is human readable.

Drawbacks

• No support for SHA-3, which is being strongly advised for new protocols by government standards bodies such as NIST.
• No support for hash algorithms other than SHA-2.
• Encoding is not URL safe (uses base64 instead of base64-url-nopad) so digest values cannot be expressed in URLs.
• Not upgrade-able to newer hash algorithms without revising SRI, which this group has no authority over, and which hasn't been updated since 2016 (and is not likely to be updated anytime soon).

Option B: Use digestMultibase

This option chooses to use the newer Multibase-encoded Multihash syntax defined by Data Integrity.

Benefits

• Defined in Data Integrity, which this Working Group has control over (so we can modify it as needed)
• Supports both SHA-2 and SHA-3
• Usable in URLs (via base64-url-nopad)
• Self-describing, so automatically binary-compressible via compression formats that work with Multibase such as CBOR-LD
• Ability to support "newer" hash formats such as Blake, Skein, and other variable hash length schemes
• Useful outside of Verifiable Credentials (provides a generalized primitive for use elsewhere)
• Encodeable in ways that makes it easier for humans to read (base58-btc encoding)

Drawbacks

• Requires use of new libraries and conversion software.

Option C: Allow use of both digestSRI and digestMultibase

This option allows developers to choose to use either digestSRI and/or digestMultibase.

Benefits

• All benefits of Option A and Option B.
• Allows issuers to choose the option that best suits them.

Drawbacks

• All drawbacks of Option A and Option B.
• Requires verifiers to implement both options because some issuers will choose digestSRI while others choose digestMultibase.

[msporny]

PR #1490 has been raised to address this issue. This issue will be closed if PR #1490 is merged.

[msporny]

PR #1490 and #1492 has been raised to address this issue. This issue will be closed if PR #1490 or #1492 is merged.

[msporny]

PR #1492 has been merged, resulting in PR #1490 being closed, closing.