[Bug] 0x prefix on publicKeyHex

[John Henderson]

This is not so much a bug as a question 😄

Current Behavior

When resolving example DIDs (e.g. did:ethr:0x03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479 using the dev universal resolver (https://dev.uniresolver.io/), verificationMethods like this one are resolved:

{
      "id": "did:ethr:0x03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479#controllerKey",
      "type": "EcdsaSecp256k1VerificationKey2019",
      "controller": "did:ethr:0x03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479",
      "publicKeyHex": "0x03fdd57adec3d438ea237fe46b33ee1e016eda6b585c3e27ea66686c2ea5358479"
}

The publicKeyHex here has a 0x prefix.

Expected Behavior

Reading the W3C security vocab (https://w3c-ccg.github.io/security-vocab/#publicKeyHex), the publicKeyHex values doesn't start with the 0x prefix. This is also the case in the signature spec (https://w3c-ccg.github.io/lds-ecdsa-secp256k1-2019).

Is it better to include the 0x prefix in the publicKeyHex values or is it better to not include it?

[Mircea Nistor]

I think in this case we are looking at a bug. Great find, thank you!

The property name is publicKeyHex, which implies that the value is a hex string. It should not require a 0x prefix for disambiguation.

Also, I guess publicKeyHex is now deprecated, so another representation should be encouraged anyway.

[Mircea Nistor]

Fixing this would be a breaking change since some implementations might rely on a 0x prefix.