Consider using multibase, multihash, and multicodec.

[msporny]

There are a number of areas in the specification that could benefit from the use of multibase, multihash, and multicodec:

https://tools.ietf.org/html/draft-multiformats-multibase-01
https://tools.ietf.org/html/draft-multiformats-multihash-00
https://github.com/multiformats/multicodec#multicodec

The suggestion here is to do one or more of the following:

1. Change all expression of binary data from hex to multibase.
2. Change all expression of cryptographic hashes to multihash.
3. Change all expression of public keys to multicodec.

Veres One already uses these formats for the expression of these data types, including ed25519 public keys. Sovrin, and a few other ledgers, use ed25519 public keys. Bitcoin and Ethereum use secp256k1. If we can get alignment on how to express public keys, it becomes possible to anchor and use public keys in an interoperable way across blockchains.

For example, in a did:peer document, if you had this as a encoding for a public key:

did:peer:11-z279wDK5GK3nSaqQmnHJxG6LRQ7CuZpvWpEcty2qfT6Cjz9g

You could easily also use it on Veres One (note that nothing changes with the key encoding for the ed25519 public key at the end... it's literally just a search and replace):

did:v1:nym:z279wDK5GK3nSaqQmnHJxG6LRQ7CuZpvWpEcty2qfT6Cjz9g

Same with Bitcoin and Ethereum, you could, in a did:peer DID Document, express a secp256k1 key like so:

did:peer:11-z1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER

and then lift and use that in BTCR or an Ethereum-based transaction, like so:

did:btcr:z1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER
did:ethr:z1LGpGhGK8whX23ZNdxrgtjKrek9rP4xWER

[dhh1128]

All of these standards were used in an earlier version of the spec. We took them out because they seemed to clutter up the DID value significantly (adding a half dozen digits that never varied) without providing a lot of value.

I would be happy to put them back in, if those working on the spec find their benefits worth the clutter. What do others think?

[msporny]

This topic just came up today over here (in the main DID spec): https://github.com/w3c-ccg/did-spec/pull/270/files

[msporny]

adding a half dozen digits that never varied

For public keys, it should be 2-3 bytes that don't vary, if you only use one public key type.

For hashes, it would be 2-5 bytes that rarely vary, if you only use one hash type.

The benefit that you gain for those additional bytes is full forward compatability with future formats... remember when everything was going to be base64... until it wasn't and then everything was base64url, and then it wasn't and now its base58 and base16... until... :)

[dhh1128]

I wouldn't have any problem changing the internal representation of keys in this spec to use the multiformats exclusively. A peer DID doc can have many different key types, and using one repr for all of the values makes a lot of sense.

But I think you (@msporny ) are advocating the use of multihash and multibase in the DID value, not just multi formats in key representations. Correct?

I wonder if we should separate those two recommendations and consider them independently. The one about keys inside the DID doc would be trivial to push through. It's only the use of multiformat inside the DID value itself that I think is debatable.

[msporny]

But I think you (@msporny ) are advocating the use of multihash and multibase in the DID value, not just multi formats in key representations. Correct?

Nope, not exactly :). I'm suggesting multicodec encoded keys that are multibase encoded in the DID value. You'd use the same representation in the DID Document for public keys. So, the key format in the DID (if your DID value is public-key based) is the same exact format as the publicKeyMulticodec value in the DID Document. So, all public keys would be MULTIBASE(MULTICODEC(PUBLIC_KEY))

From the original issue:

The suggestion here is to do one or more of the following:

1. Change all expression of binary data from hex to multibase.
2. Change all expression of cryptographic hashes to multihash.
3. Change all expression of public keys to multicodec.

[swcurran]

I think we should use these approaches. I think the forward compatibility benefits far outweigh the space costs.

[mavarley]

Hi @msporny
I'm with @dhh1128 in that updating the format of the keys in the DID Doc to support multibase/code/codec would be an appropriate change and help with interop.

The DID Value itself is currently a hash of a JSON 'genesis doc', not a key (and I don't believe there is a desire to change this to a representation of a key) - so maybe that becomes a multi-hash for interop and future proofing reasons (I'm also a bit confused if you are also suggesting the DID value become a key representation...?)

The other challenge is the DID Value already has a concept of a number and an encoding prefix (currently '11'). This not only defines the format of the bits, but also how to get those bits (take a genesis version of a DID Doc of a certain format and run the hash algorithm).

Would modifying the prefix of the DID Value to be just the 'numalg', then applying multi hash to encode the bits be the middle ground? So a peer did would be:

did:peer:1-z279wDK5GK3nSaqQmnHJxG6LRQ7CuZpvWpEcty2qfT6Cjz9g

or does it become did:peer:1-MULTIBASE(MULTIHASH(genesis doc)) ?

[OR13]

did:key takes this approach as well, I'm happy to help make it a recommendation in the spec... its very useful to be able to recover a public key from a fingerprint.

[dhh1128]

I think we've largely resolved this issue, now that peer DIDs fully align with did:key when the algorithm for numeric basis == 0. We've also updated the DID value for numalgo == 1 per Manu's suggestion. However, there are some minor details to work out in how keys are represented inside DID docs, so I don't want to entirely close the ticket yet.

However, the ticket has to be moved to its new repo home at decentralized-identity/peer-did-method-spec#10. Therefore the issue is being closed here and resurrected in a more limited form to track to closure.