-
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
Add public key examples using JWKs #171
Comments
Example did document:
The linked data signature key types might seem new, they are not registered anywhere yet... We have this blog post about this stuff: https://medium.com/transmute-techtalk/linked-data-proofs-vs-jose-why-not-both-1594393418cc Waiting for the registry stuff to get settled before trying to update it. |
Here is an example from the did core registry: https://w3c.github.io/did-core-registry/#ecdsasecp256k1verificationkey2019 |
We should take the referenced examples from the core registries and add them to the core spec, since it's well known that developers often code to the examples. |
I will write a PR updating the examples to include JWK representations. |
There's currently only one JWK example in the spec, which is for an Ed25519 key. It would be good to also add examples for RSA and P-256 keys. |
Here is an example DID Document, which could be used to add more examples:
|
@OR13 Do we want those types on JWKs to be |
@kdenhartog I think you, me, @tplooker, @csuwildcat and potentially also @selfissued want them to be defined that way.... I know @msporny does not.... There is nothing stopping us for creating an extension that adds support for all JOSE, and sharing those definitions across |
If you're doing this to avoid having the difficult discussion that the group needs to have regarding this cryptosuite, please don't... it's an abuse of the standardization and registry process, especially given that people will probably start using this mechanism without knowing all the ways that it can blow up in their face, especially if you guys decide to allow all sorts of terrible optionality. Remember, that what you're calling "JsonWebKey" above is a verification method, not the expression of public key material. That is, it's a part of a (DID Document, verification relationship, verification method) tuple. It is the "verification method" part of that tuple, of which public keys are one type. Dating the type with at least a year is a best practice in case you want to constrain future key types (or even this key type). Thinking that you're never going to have to change the rules associated with the verification method is poor planning. With all of this crypto stuff, assume that you're making a mistake and give yourself space to fix the error in the future... date stamping the time gives you a way to do this easily. |
Sorry, I missed the date part... I totally meant for it to be If the goal of the some of them are prohibited, others are optional, some are recommended.... the whole document has a last updated date... which if it were 6 years ago... would seem to indicate that you should not trust any of it.... the first thing I check on a repo is how many contributors, and how often are new versions published. |
This needs a special topic call so we can settle on what the examples look like. We need at least @kdenhartog, @OR13, and @selfissued on that call. |
We had special topic call, we now just need to make sure that the verification method section of did core contains a couple JWK examples... ready for PR... examples in the thread. |
Pending discussion around naming, this will happen in next couple of weeks... we will get JWK examples into the spec. |
This will be fixed by #377 |
Recommend closing. |
No comments since marked pending close, closing. |
Given that programmers often program to the examples, please add multiple example public keys to the examples that use JWK representations. For instance, these could be added to the "Various public keys" examples at https://w3c.github.io/did-core/#example-12-various-public-keys and https://w3c.github.io/did-core/#example-13-various-public-keys.
(At the same time, the publicKeyHex example could be removed, as there doesn't appear to be working group consensus to include it.)
The text was updated successfully, but these errors were encountered: