Review multibase vs base58 key representation about vc-di-eddsa HOT 11 CLOSED

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).

from vc-di-eddsa.

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.

from vc-di-eddsa.

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).

from vc-di-eddsa.

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.

from vc-di-eddsa.

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.

from vc-di-eddsa.

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

from vc-di-eddsa.

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

from vc-di-eddsa.

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.

from vc-di-eddsa.

@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.

from vc-di-eddsa.

@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.

from vc-di-eddsa.

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.

from vc-di-eddsa.