Update did-v0.11.jsonld to match the current spec #156
Conversation
Add missing properties to context. Absence of these properties severly impacts interoperability when relying on https://www.w3.org/ns/did/v1 And per the current spec: https://w3c.github.io/did-core/#public-keys `Public keys of all types MUST be expressed in either JSON Web Key (JWK) format using the publicKeyJwk property or one of the formats listed in the table below.`
OR13
changed the title
|
IPR integration is bugged, my accounts are linked, it will not re-authorize. |
|
Absence of these property definitions currently prevents adoption of |
|
In the meantime, if you are blocked by this, feel free to add the WIP sidetree extension context, which defines these properties with proper documentation: https://docs.element-did.com/contexts/sidetree/sidetree-v0.1.jsonld |
add sidetree context because of w3c/did-core#156
There was a problem hiding this comment.
Just realized that publicKeyJwk is misspecified here. And we should perhaps move to a different version to make new changes anyway as that has been the practice to date. publicKeyJwk needs to specified like this:
"publicKeyJwk": {"@id": "sec:publicKeyJwk", "@type": "@json"}
In order to be express that its value is a JSON literal.
There was a problem hiding this comment.
Major issues with this PR: 1) People have shipped did-v0.11.jsonld in software so we shouldn't change it, we should bump the version to v0.12.jsonld and make changes there, 2) publicKeyJwk is specified without specifying all of the possible values as terms or making it a JSON Literal, and we need to discuss what the right thing to do is before making a change to the context, and 3) publicKeyHex was specifically called out as something that the group didn't want to support IIRC... only publicKeyPem, publicKeyJwk, and publicKeyBase58 are allowed.
Here's what we need to make progress on this PR:
- Someone needs to do an analysis on the entire JWK registry and ensure that there are no canonization issues with values associated with items in the registry. If there are no JCS canonization issues, then we should use
"@type": "@json". If there are JCS canonization issues, then we will need to express all possible JWK values in the context as Linked Data. - The DID Core Registry needs to be put in place, and we may be able to add publicKeyHex there, but expect that there may be objections based on the previous discussion that rejected publicKeyHex as a valid interoperability option.
| @@ -50,6 +50,8 @@ | |||
| "publicKey": {"@id": "sec:publicKey", "@type": "@id", "@container": "@set"}, | |||
| "publicKeyBase58": "sec:publicKeyBase58", | |||
| "publicKeyPem": "sec:publicKeyPem", | |||
| "publicKeyJwk": "sec:publicKeyJwk", | |||
| "publicKeyHex": "sec:publicKeyHex", | |||
There was a problem hiding this comment.
| "publicKeyHex": "sec:publicKeyHex", |
publicKeyHex was not agreed to in the public key discussions... only publicKeyBase58 and publicKeyPem were allowed. publicKeyHex may have to use the extension registry.
|
I'll wait for a way to fix this in did core. |
Add missing properties to context.
Absence of these properties severely impacts interoperability when relying on https://www.w3.org/ns/did/v1
And per the current spec: https://w3c.github.io/did-core/#public-keys
Public keys of all types MUST be expressed in either JSON Web Key (JWK) format using the publicKeyJwk property or one of the formats listed in the table below.