-
Notifications
You must be signed in to change notification settings - Fork 95
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
publicKeyJwk, publicKeyHex, publicKeyBase64, publicKeyBase58 missing from context. #23
Comments
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. |
Related: #5 |
This issue is related to #55 . Support for |
Also related to #67 |
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. |
Tagging @OR13 since he could close this issue out by putting in a PR for an experimental Ethereum |
I'm a bit confused about what goes in what repo now... shouldn't the context and schema definitions go in the registry repo? |
Blocked by: w3c/did-extensions#3 |
Blocked by: w3c/did-extensions#20 |
publicKeyHex blocked, but we will probably just define that in the next did spec registries updates. |
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. |
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.
Yep, exactly. |
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. |
Yes, we need |
Suggest closing, we have this in the spec registries. |
recommend opening a new issue remove 'publicKeyPem`. |
closing, opened w3c/did-extensions#126 |
@OR13 moved from CCG (w3c-ccg/did-spec#152)
The text was updated successfully, but these errors were encountered: