Cryptographic Key "Support" vs Key "Validation"

[Tweeddalex]

Hi all! Wanted to raise an issue regarding the classification of "supporting" a particular key / cryptographic primitive.

Taking a look at the "non-ledger" DID Traits (did:web, did:webvh, etc), it shows that they support all of the cryptographic curves/algorithms. I guess I have a bit on an issue with this, because what this is saying is that you can insert any arbitrary key into these DID Documents, but there is not any additional validation against those keys.

With something like did:cheqd, we also support all the key types in the same way as did:web, did:webvh (as they can be added into a DID Document arbitrarily), but then there's a subsection of key types that are additionally validated against by the ledger, ensuring consensus on whether the verificationMethod is valid.

I didn't want to write that did:cheqd supports all of the different cryptographic primitives/curves, because although it can facilitate the key types, it doesn't natively validate against them. But then equally, I don't think that did:web, did:webvh should be shown as supporting all of these keys as they don't natively provide any validation mechanism.

So maybe there is an additional qualification we can add here, to differentiate between keys "supported" and keys that the infrastructure of the method conducts "validation" on? Would be keen to get people's thoughts here.

@peacekeeper @jceb @ottomorac

[ankurdotb]

You raise a good point, but in seeking the clarification itself you've raised an interesting statement that could be interpreted in two ways (which I think reinforces the point).

I didn't want to write that did:cheqd supports all of the different cryptographic primitives/curves, because although it can facilitate the key types, it doesn't natively validate against them.

That's not true. :) did:cheqd does validate if they are valid keys, but only in some scenarios and not others. Here's an explainer:

1. Keys that are listed under authentication or controller properties: It does validate any keys defined in verificationMethod that are referenced in either authentication or controller (if the controller is just a DID reference like did:xxx, not did:xxx#key-1, we fallback to the authentication section). By "validate" I mean the ledger code checks whether the key mentioned is a valid Ed25519 (EdDSA) or Secp256k1 (EcDSA) key. Ledger code also checks if it's a valid representation, e.g., JsonWebKey2020, Ed25519VerificationKey2018.
2. Keys that are listed or defined in any other section of the DID Document: The ledger code checks if these are valid JSON syntax and structure, but doesn't otherwise check if they are valid keys. For example, some developers define in-line keys in assertionMethod to define BBS+ keys that are used when issuing credentials, but not to control the DIDDoc itself. The ledger code does not test if these are valid BBS+ keys.

So the point you're making is if the kind of validation a DID method does is like Scenario 1 above is that "support" or "validation" vs Scenario 2.

I would propose the following:

1. If it's like Scenario 1, that should be called "Which cryptographic curves/key types/suites/representation does the DID method allow publishing with validation?" (N.B. "curves", "key types", "suites", and "representation" mean wildly different things but I'm lumping them together here since sometimes people use it interchangeably. The DID traits criteria should probably pick a precise definition and explain it, with examples, because people tend to use it interchangeably.)
2. Scenario 2 should be called "Which cryptographic...does the DID method support publishing in DID Documents (without validation)?" This covers DID methods that allow stating/publishing a key, without active checks.

The reason for having a distinction between 1 and 2 above is that some DID methods might not even allow for publishing anything besides actively validated keys (e.g., in Scenario 2, the developer would not be able to publish a definition of a BBS+ in a DIDDoc section, because the DID method doesn't allow it.)