Need to decide on what hash algorithm to use when hashing suffix data

[thehenrytsai]

Need to decide on what hash algorithm to use when hashing suffix data when multiple hash algorithms are supported, the case overlooked in current implementation is that a long-form DID can be registered any time in the future.

[csuwildcat]

Question: aren't there already values within the suffix data that indicate this, and if not, should we consider just adding a version string to the create suffix portion that is required, to provide you with specific instructions that are unambiguous?

Ironically, this may be a great example of why a DID Method should have the ability to shift a user's DID representation to a new form using canonical/equivalent ID references.

[sandrask]

@thehenrytsai @csuwildcat Should we use the multihash code that is used for recoveryCommitment (part of suffix data)?

[OR13]

prefer to have the behavior fully defined in the spec, with RECOMMENDED text.

[sandrask]

@thehenrytsai @csuwildcat @csuwildcat @troyronda According to spec all hashes have to be calculated using the same currently supported multi-hashing algorithm (https://identity.foundation/sidetree/spec/#hashing-process). Does this mean that you should reject create request with hashes that are calculated with different algorithm? For scenario that we discussed today (long-form DID that may get anchored year later) this issue may not be limited to generating unique suffix only. In addition, all hashes in one operation request should be generated with same multihashing algorithm (except for reveal value).

[thehenrytsai]

Having a version property was discussed as a viable approach, absence of such a property can imply version 1.

[decentralgabe]

Handled in spec.