Review multibase vs base58 key representation

[OR13]

@dlongley I recall you may have objected to the idea of publicKeyMultibase vs publicKeyBase58.

Would love to hear your thoughts.

My initial thoughts are that publicKeyMultibase might be easier to align with IPLD in the future.

[peacekeeper]

Is Example 4 correct?

If you have

"publicKeyBase58": "dbDmZLTWuEYYZNHFLKLoRkEX4sZykkSLNQLXvMUyMB1",

then shouldn't that be equivalent to

"publicKeyMultibase": "zdbDmZLTWuEYYZNHFLKLoRkEX4sZykkSLNQLXvMUyMB1",

?

But the example currently seems to show two completely different key pairs.

[dlongley]

I don't mind publicKeyMultibase ... I'm just worried about people needing to support all your base. If we do publicKeyMultibase, someone is going to start using things other than base58 and this will lead to annoying interop problems. We need some kind of brakes on what gets supported.

For example -- we could say that the linked data key type can say which bases are supported (ideally just one).

[OR13]

Agree, I think throwing an error in the library when an unsupported base is detected is the best solution.

And let the signature suite itself define the supported bases, so that support for a suite automatically causes libraries to support popular bases.

[peacekeeper]

But again, Example 4 shows two different keys, even though they both have the id https://example.com/issuer/123#key-0, right?

If someone confirms that, I could try to fix the example(s).

[OR13]

IIRC they are supposed to be the same key encoded 2 different ways, or that was my intention.

the z tells you its base58btc multicodec. My intention was to provide examples that showed how to upgrade an Ed25519VerificationKey2018.

It looks like I did the math wrong.

[OR13]

its also possible that the prefixing shifted the base58 encoding of the binary, and thats why the character strings look different.

[OR13]

the desired behavior is to show both encodings for the same binary key material.

[clehner]

Hi @OR13, @peacekeeper,
I notice this encoding issue also.

The example publicKeyMultibase and privateKeyMultibase values are doubly-encoded with multibase/base58btc. Decoding them yields what I think are the correct values, that is the original base58 strings with "z" prepended.

[OR13]

@clehner I suspect the test vectors are incorrect, I built them a long time ago, and AFAIK nobody has tested them until you :)

Please open a PR to correct them, I am also unsure if the byte prefix for private key is correct... be careful.

[clehner]

@OR13 opened: #10. I find the VC test vector correct after fixing the multibase encoding. The VP I had to regenerate.
The private key is 64 bytes, a common encoding of a Ed25519 private key, where the last 32 bytes is the public key.

[msporny]

Looks like publicKeyMultibase won. There are no plans to keep publicKeyBase58 going AFAIK:

• https://w3c.github.io/vc-data-integrity/#dfn-publickeymultibase
• https://w3c-ccg.github.io/di-eddsa-2020/#multikey

Closing.