Explain verification suite definition and explain reuse of verification method type/material

[awoie]

From section 5.2.1 Verification Material:

A verification suite definition is responsible for specifying the verification method type and its associated verification material. For example, see JSON Web Signature 2020 and Ed25519 Signature 2018. For all registered verification method types and associated verification material available for DIDs, please see the DID Specification Registries [DID-SPEC-REGISTRIES].

• 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 of Ed25519VerificationKey2018 is in Ed25519 Signature 2018. 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? I guess, we might think about creating a registry for Verification Suite Definitions which does the actual mapping.

[awoie]

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.

[OR13]

@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.

[OR13]

Also related:

• CR Feedback: Support of publicKeyMultibase #707
• Remove all schema requirements from the registries by WG call did-extensions#264

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.

[iherman]

The issue was discussed in a meeting on 2021-03-30

• no resolutions were taken

View the transcript

5.4. Explain verification suite definition and explain reuse of verification method type/material

See github issue #712.

Kyle Den Hartog: Manu, I'm good with that. If we plan to put something in here than I agree publicKeyMultibase makes more sense.

Brent Zundel: raised by Oliver, currently assigned to manu.

Manu Sporny: just assigned 8 minutes ago. Orie_ ?

Orie Steele: It's very related to the previous issue, regarding VM suites and VM material.
… Essentially, Oliver is surprised we are not discussing VM suites in DID Core. We have discussed this at length.
… I don't think there is a need to describe verification methods in DID Core.

[msporny]

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.

[OR13]

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...

[awoie]

@msporny thanks for the clarification. That works for me. I can create the PR to update the terminology section.

[iherman]

The issue was discussed in a meeting on 2021-05-04

• no resolutions were taken

View the transcript

7.4. Explain verification suite definition and explain reuse of verification method type/material

See github issue #712.

Manu Sporny: Either Oliver will do it, or I will.
… I'll add him as an assignee.

[msporny]

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.

[msporny]

PR #732 has been raised to address this issue. This issue will be closed once that PR has been merged.

[msporny]

@awoie can you please confirm that PR #732 addresses the issue you raised?

[awoie]

@msporny thanks, the PR LGTM.

[msporny]

PR #732 has been merged, @awoie has confirmed that the change addresses his concern, closing.