Consider using ordinary hashes to identify DID documents

[vdods]

Currently DID documents are identified using the selfHash field (produced during the self-sign-and-hash operation on the DID document). This has the advantage that the DID document contains its own unique content-derived identifier, and that the specific hash function used to generate that identifier is represented and therefore discoverable in the DID document.

However, the verification procedure is more complex than just feeding the bytes of the (canonical form of the) DID document into a hash function, as is the common approach to content-addressing (e.g. in IPFS).

Consider changing this in the following way:

• The root DID document would still be self-signed-and-hashed, because the self-hash forms part of the DID itself.
• Non-root DID documents would only be self-signed (and no longer self-hashed).
• "The" unique identifier for each DID document would simply be a representation of the hash of the DID document under some pre-defined hash function (footnote 1). I would suggest using multiformats to represent this, as it has a large table of possible hash functions, has a reasonable spec, is extensible, and is used by IPFS.
• Instead of using of the selfHash query parameter in the kid field in JWS signatures (and other proofs), use the hl query parameter. The DID resolver would then hash the document using the pre-defined hash function, and compare the value against the value given in the hl query param.

Advantages of this change:

• Hash of a DID can be computed without knowledge of the DID document's data model, and therefore is amenable to generic hash-computing software.
• This is more in line with the generic use of the hl query parameter for DIDs. Though the specific format of that field is not specified. I would suggest using multiformat here for well-definedness and extensibility.
• IPFS uses multiformat hashes to address content on its network. This would (more easily) enable an IPFS-based VDR implementation. Note that even if self-hashes were used, there would still be a way to use IPFS (footnote 2).
  Disadvantages:
• This requires storing the unique identifier (i.e. hash) of the DID document separately, instead of having it be a self-contained and self-verified piece of data, as in the current, self-hashed situation.
• In order to have a unique hash identifier for a DID document, a specific hash function must be used. This is not extensible as the self-hashing scheme is (the entity doing the self-hashing gets to decide which hash function to use). This choice of hash function is a new parameter in the DID method, and must either be chosen uniformly, or determined from some other context (added potential for confusion).

Footnotes

1. Mike Lodder suggests using SHA3-256 or BLAKE3 for the pre-defined hash function. Each of these produces reasonably short hash values (256), and they're not length-extension-attackable. SHA3-256 is more widely available, but BLAKE3 is faster.
2. In order to serve self-hashed data on IPFS -- call this data D -- you would replace the self-hash slots of D with the appropriate placeholder (see https://github.com/LedgerDomain/selfhash#self-verifying) and (canonically) serialize the data that will be put on the IPFS network -- call this file F. The hash of this file is by construction the same as the self-hash. To restore D from F, you would need to replace the self-hash slots of F with the CID (hash of F which is the identifier on IPFS).

[bumblefudge]

SHA3 might make it into webcrypto API (and thus be verifiable IN BROWSERS without polyfills!):
w3c/webcrypto#319 (comment)

(big slow "might" tho)