Closed OR13 closed 4 years ago
Some of the contexts may be in flux at the moment. Here are some that might help:
Not sure where publicKeyHex comes from. I don't think the plan was to put properties for every key type into the main did context, but perhaps general ones should go there.
publicKeyBase58
is in the v0.11 of the DID Context.
For any (the others in the list) not defined in the main context, the ld cryptosuite registry (related issue) needs to be updated with the contexts they can be found in.
I can PR against security/v2 and/or the DID context to add them if someone tells me which ones should go in (maybe all of them until they have another home established? maybe that's a bad idea?).
Also worth mentioning the context URL in the DID spec has changed to https://www.w3.org/2019/did/v1
which currently doesn't resolve to anything and won't for a while probably.
Bumping this issue.
The fact that publicKeyHex
is missing from the did spec as a valid publicKey
format is preventing us from adding did:elem to the universal resolver
Could we add it to v0.12?
Edit: publicKeyHex
is in the examples of the v0.13 spec: https://w3c-ccg.github.io/did-spec/
@rhiaro @gjgd Yeah, we'll need to add publicKeyHex
to the DID context
Closing as this has been moved to the DIDWG repo.
Per the spec, https://w3c-ccg.github.io/did-spec/#public-keys
I was expecting to see publicKeyPem, publicKeyJwk, publicKeyHex, publicKeyBase64 to be present here:
https://w3id.org/did/v1, which resolves to https://w3c-ccg.github.io/did-spec/contexts/did-v1.jsonld
This causes errors when signing DID Documents which contain publicKeys with properties missing from the context, for example:
The property "publicKeyHex" in the input was not defined in the context.