Did-core: publicKeyJwk, publicKeyHex, publicKeyBase64, publicKeyBase58 missing from context.

[brentzundel]

@OR13 moved from CCG (https://github.com/w3c-ccg/did-spec/issues/152)

[OR13]

I suggest hosting the JSON-LD Contexts and their human readable documentation under this github repo, so that contributors can open a single PR to fix both human and machine readable spec's related to DID security.

Security and usability issues arise when documentation becomes out of date and JSON-LD context resolution spans many domains controlled by various 3rd parties.

[dmitrizagidulin]

Related: https://github.com/w3c/did-spec/issues/5

[awoie]

This issue is related to #55 . Support for ethereumAddress is also missing.

[tplooker]

Also related to #67

[selfissued]

The publicKeyHex, publicKeyBase64, and publicKeyBase58 structures are duplicative representations of the same information. Having more than one way to do things will inevitably create interop problems, as developers will only build the ones that they think they need at present. And these sets will differ between implementations and deployments.

It should be no surprise that I'd advocate replacing all of them with JWK, since it's already a widely-implemented JSON-based standard. That would increase interoperability and reduce unnecessary code fragmentation and bloat.

[msporny]

I suggest hosting the JSON-LD Contexts and their human readable documentation under this github repo

Tagging @OR13 since he could close this issue out by putting in a PR for an experimental Ethereum @context hosted in the /contexts/ directory of this repo... that is then added to the did-core-registry for publicKeyHex. We should have publicKeyJwk and publicKeyBase58 in the core context and not have publicKeyBase64 anywhere (as it's used in publicKeyJwk and we don't have to define it for its use there)

[OR13]

I'm a bit confused about what goes in what repo now... shouldn't the context and schema definitions go in the registry repo?

[OR13]

Blocked by: https://github.com/w3c/did-core-registry/issues/3

[OR13]

Blocked by: https://github.com/w3c/did-core-registries/pull/20

[OR13]

JWK is unblocked: https://github.com/w3c/did-spec-registries/blob/master/contexts/did-v1.jsonld#L119

[OR13]

publicKeyHex blocked, but we will probably just define that in the next did spec registries updates.

[rhiaro]

I'm not sure of the consensus around which of these will be defined in the DID Core spec. I think publicKeyJwk and publicKeyBase58 for sure? Any not in the Core Spec will be added to the Registries (linking to external specs and contexts). I can PR to add the agreed ones to the Core context and to the spec (#281) when there's a definitive answer.

[msporny]

I think publicKeyJwk and publicKeyBase58 for sure?

Correct.

The only issue with publicKeyBase58 might be pointing to a normative spec. We can get around that by not making any normative statements on what the expected encoding is. We may want to try to say something like using the "Base58 Bitcoin alphabet"... or referring to the I-D at IETF.

Any not in the Core Spec will be added to the Registries (linking to external specs and contexts).

Yep, exactly.

[kdenhartog]

I found that publicKeyHex was already defined in the did-spec-registries, so wasn't sure what the best approach for context definitions would be. Looking to get it added to the CCG security-vocab as well soon.

[OR13]

Yes, we need publicKeyHex to be defined in security-vocab jsonld and the html documentation which the jsonld contexts reference.. we have an open PR for the HTML we need context update in the W3C CCG

[OR13]

Suggest closing, we have this in the spec registries.

[OR13]

recommend opening a new issue remove 'publicKeyPem`.

[OR13]

closing, opened https://github.com/w3c/did-spec-registries/issues/126