Support other encodings of Multibase

[conr2d]

The current spec of did:key uses base58-btc encoding only from multibase. It would be great to allow use of other encodings like base64 to make the most of multibase & multicodec, even if the canonical (or recommended) representation of did:key is base58-btc.

By the way, I am interested in participating in did:key method development. Is there any place for open discussion?

[dmitrizagidulin]

@conr2d

It would be great to allow use of other encodings like base64

Sure! So, multibase allows for all sorts of encodings, including base64. So, nothing's stopping you from using that (except maybe library support - some did:key libraries don't expect base64) - it would just mean that the first letter is m, instead of base58's z.

By the way, I am interested in participating in did:key method development. Is there any place for open discussion?

At the moment, these Github issues are the main place! :)

[conr2d]

@dmitrizagidulin Thank you for the comment. As you mention, there is nothing to ban using other encodings technically, but the specification of did-key-method v0.7 requires base58-btc.

It consists of the did:key prefix, followed by a Multibase [MULTIBASE] base58-btc encoded value that is a concatenation of the Multicodec [MULTICODEC] identifier for the public key type and the raw bytes associated with the public key format.

The ABNF for the key format is described below:

did-key-format := did:‌key:<mb-value>
mb-value := z[a-km-zA-HJ-NP-Z1-9]+

Alternatively, the encoding rules can also be thought of as the application of a series of transformation functions on the raw public key bytes:
did-key-format := did:‌key:MULTIBASE(base58-btc, MULTICODEC(public-key-type, raw-public-key-bytes))

It would be good if using other encodings is explicitly permitted by the following version of specification. :)

[msporny]

It would be good if using other encodings is explicitly permitted by the following version of specification.

Yes, we've been considering whether or not to allow this for some time. Like all design decisions, there are trade-offs:

Allowing multiple multibase encodings allow for flexibility, which allows the design to work for use cases we haven't considered yet.

Disallowing multiple multibase encodings make implementations simpler, as did:key does not have to deal with the variation in base-encoding patterns.

So, the tradeoff right now is implementation complexity vs. implementation flexibility, and you can't have both simultaneously.

We used multibase such that if we needed to use a different base-encoding in the future, we had the mechanism to do so. I'll also note that did:key has a version field, so we always have the option to use a different base-encoding in the future. However, given that we're trying to create a global standard, we will most likely want to minimize the number of choices that implementers have in front of them. Implementing ONE base-encoding is better than two, three, and so on. Just because we have the flexibility does not mean we have to use it right now, especially since there is a trade-off.

[conr2d]

@msporny Got it. IMHO, it would be good if base64 is supported at least. Because base58 is not performance-oriented encoding, but for mitigating human error. For machine communication, base64 has better performance, and built-in functions for base64 conversion are provided in web environment.

[msporny]

@msporny Got it. IMHO, it would be good if base64 is supported at least. Because base58 is not performance-oriented encoding, but for mitigating human error. For machine communication, base64 has better performance, and built-in functions for base64 conversion are provided in web environment.

Well, which variation of base64? There are at least eighteen variations... :)

If we ended up supporting the base64 family (for public keys that are larger than ~128 bytes in size), then I expect we'd use base64url with no padding (RFC4648))... but given that the only public keys we're dealing with these days are RSA keys, and given that new systems tend to not deploy RSA, we might not want to support RSA in did:key (though if we do end up supporting it, I expect the key encoding would be base64url for those keys... OR, we say we decide that we don't care about the performance impacts of a legacy cryptographic scheme that is being phased out).

[conr2d]

Sorry for leaving a comment too late. I agree with you. Not to make the specification too complicated, supported encodings should be chosen carefully. Base64url with no padding could be one best choice.

[msporny]

Sorry for leaving a comment too late. I agree with you. Not to make the specification too complicated, supported encodings should be chosen carefully. Base64url with no padding could be one best choice.

Some other places this discussion is happening:

w3c/vc-data-integrity#93
https://w3c.github.io/vc-di-eddsa/#multikey
https://w3c.github.io/vc-di-ecdsa/#multikey
https://w3c.github.io/vc-di-bbs/#multikey

[msporny]

@conr2d Now that we've answered your questions, I believe we're ready to close this issue. We do support other encodings of Multibase, as evidenced in the other standards-track specifications. While did:key isn't standards track yet, once it is, it will almost certainly refer to those other specifications.

In other words, did:key supports other encodings of Multibase, so I believe we can close this issue now.

I'm going to close it, feel free to re-open it if you do not agree.