Closed awoie closed 3 years ago
Another example: I want to use EcdsaSecp256k1VerificationKey2019
for JWTs (alg=ES256K
), for LD-Proofs (EcdsaSecp256k1Signature2019
) and EthereumEip712Signature2021
(not defined yet). I know that people are using this today but is this use case officially supported by the spec?
Updated If it is it would be great if we can add non-normative language--I could create PR, just let me know if you believe this makes sense.
@awoie feel free to pull from:
https://or13.github.io/best-linked-data-suites-2020/ https://w3c-ccg.github.io/lds-ed25519-2020/
While DID Core does not define the VM Type of Signature Type, it certainly could explain more about them no normatively.
Also related:
Essentially, DID Core DOES NOT describe verificationMethod suites... but it does define their general shape, and verification relationships... I think this is a happy compromise.
The issue was discussed in a meeting on 2021-03-30
The spec does not define the term Verification Suite and Verification Suite Definition. IMO, this should be at least added to the Terminology section.
Ok, that sounds like a good change to make, would you mind raising a PR to do that? If you don't get around to it in the next couple of weeks, I can do it.
I guess, we might think about creating a registry for Verification Suite Definitions which does the actual mapping.
@awoie there is a LD Cryptosuite Registry here: https://w3c-ccg.github.io/ld-cryptosuite-registry/
I expect that's where the mapping will happen.
Can I still use the same verification method type of Ed25519VerificationKey2018 for JWTs and LD-Proofs, or would I have to make changes to the registry?
That all depends on the type of Signature... for LD Signatures, let's say EthereumEip712Signature2021
says that you can use verification keys of type Ed25519VerificationKey2018
using publicKeyBase58
OR verification keys of type JsonWebKey2020
using publicKeyJwk
to verify... then yes, you can do that... but only because the signature spec says what sort of verification key material you can use (and it's flexible about it). I don't suggest you do that, however, as the code becomes more complex, harder to maintain properly, harder to audit, etc.
If you want to verify a JWT using a Ed25519VerificationKey2018
or JsonWebKey2020
, you could do that too, but you'd need to write a spec that tells someone how to issue a JWT and verify a JWT using those external key types. It's not a hard spec to write, but again, I'd advise against it because the JWT world is the JWT world... and they have their own way of expressing keys and verifying signatures.
https://w3c-ccg.github.io/lds-jws2020/ https://w3c-ccg.github.io/lds-jws2020/browser-test/
Here is the spec that tells you how to use JWTs:
https://tools.ietf.org/html/rfc7519 https://tools.ietf.org/html/rfc8812 https://www.w3.org/TR/vc-data-model/
Essentially DID Core allows you to use things other than JOSE... but you can still use JOSE...
@msporny thanks for the clarification. That works for me. I can create the PR to update the terminology section.
The issue was discussed in a meeting on 2021-05-04
The spec does not define the term Verification Suite and Verification Suite Definition. IMO, this should be at least added to the Terminology section.
Hmm, thinking about this a little more ... sometimes the best thing to do is remove new terminology and reuse existing terminology. In this case:
"Verification Suite" -> "Cryptographic Suite" "Verification Suite Definition" -> "Cryptographic Suite Specification"
Then the only term we need to define is "cryptographic suite", which is something that defines "verification methods" and "verification material". The upside there is that it ties everything together quite nicely while removing some language complexity in the spec. I'll raise a PR to do that now.
PR #732 has been raised to address this issue. This issue will be closed once that PR has been merged.
@awoie can you please confirm that PR #732 addresses the issue you raised?
@msporny thanks, the PR LGTM.
PR #732 has been merged, @awoie has confirmed that the change addresses his concern, closing.
From section 5.2.1 Verification Material:
The spec does not define the term Verification Suite and Verification Suite Definition. IMO, this should be at least added to the Terminology section.
Further, and this is where I got confused, the DID Spec registry contains for example an entry for
Ed25519VerificationKey2018
. This is great because I actually like Ed25519 signatures and I don't want to add my own registry entry but I want to use the key for JWTs and LD-Proofs. The registry says that the normative definition ofEd25519VerificationKey2018
is in Ed25519 Signature 2018. Can I still use the same verification method type ofEd25519VerificationKey2018
for JWTs and LD-Proofs, or would I have to make changes to the registry? I guess, we might think about creating a registry for Verification Suite Definitions which does the actual mapping.