Define sidetree context

[OR13]

Related: decentralized-identity/sidetree#362

I propose we create sidetree json-ld context defintions, and host them here... similar to the discussion regaring BTCR contexts...

We should make a single sidetree context, to encourage sidetree method implementers to help eachother... For properties like recoveryKey which might be useful to other methods, we should define them first in the sidetree context, and then move them to to did core, only if requested.

recoveryKey is not needed for interop.... but defining a sidetree context will be a good way to show the community how to handle extensions correctly.

Examples:

https://docs.element-did.com/contexts/sidetree/sidetree-v0.1.jsonld

https://docs.element-did.com/contexts/sidetree/sidetree-v0.1

[OR13]

Add support for publicKeyHex, used by the protocol: https://github.com/decentralized-identity/sidetree/blob/master/docs/protocol.md#add-public-keys

[OR13]

Defined here: https://identity.foundation/sidetree/docs/spec/#context

@msporny I would like to set an example for external definitions that are included in the registry, whats the best way for me to do that? use publicKeyHex as an example, and link to the DIF context for it?

[msporny]

@msporny I would like to set an example for external definitions that are included in the registry, whats the best way for me to do that? use publicKeyHex as an example, and link to the DIF context for it?

Yeah, that would probably be a good place to start -- "DIF Context" sounds a bit iffy... do you mean DIF Vocabulary? In either case "DIF Context" or "DIF Vocabulary", I suggest DIF doesn't have just one of those, but multiple... in the event that DIF expands its scope of work/WGs greatly, you don't want to be stuck with just one JSON-LD Context or Vocabulary at DIF.

Let me know when there is a PR to look at, happy to do a review.

[selfissued]

Per the decisions on the key representation calls, there's not a need for publicKeyHex in the DID specification or registries, as it semantically duplicates both JWK and publicKeyBase58. Please don't create PRs to reintroduce publicKeyHex when it is unnecessary and hinders interop.

[peacekeeper]

My recollection of the key format calls is NOT that we agreed that JWK and publicKeyBase58 would be the two supported formats, but that in fact we agreed that for each key type we would support JWK and one additional format (whichever is most popular/common for the given key type).

Currently the DID Core spec says in 7.3. Public Keys:

• RSA: publicKeyJwk or publicKeyPem
• ed25519: publicKeyJwk or publicKeyBase58
• secp256k1-koblitz: publicKeyJwk or publicKeyBase58
• secp256r1: publicKeyJwk or publicKeyBase58
• Curve25519: publicKeyJwk or publicKeyBase58

We have NOT made a final decision what the two supported formats for each key type would be. See the following note in the spec:

The Working Group is still debating whether the base encoding format used will be Base58 (Bitcoin) [BASE58], base64url [RFC7515], or base16 (hex) [RFC4648]. The entries in the table below currently assume PEM and Base58 (Bitcoin), but might change to base64url and/or base16 (hex) after the group achieves consensus on this particular issue.

I am under the impression that in the communities that use secp256k1-koblitz and secp256r1, hex encoding is more common than Base58 encoding. I have argued this during one of the key formats calls (see minutes here). Therefore I would be in favor of adding publicKeyHex to the registry, and to update the DID Core spec to make that the second supported format for those key types.

[OR13]

publicKeyHex is now supported as an extension. the relationship between did-core and did-core-extensions is not well established yet, but its specifically designed to solve problems like this... if someone continuously objects to something going into did core, it can go in extensions, or they can define their own context...

Given the heavy use of publicKeyHex by the bitcoin and ethereum communities... and its presence in the did core spec for years... it's seems like a really bad idea to not add it to he extensions.... but I agree with @selfissued it does not belong in did core.

[OR13]

https://github.com/decentralized-identity/did-spec-extensions/blob/master/parameters/initial-state.md

[OR13]

irrelevant