Stick with Ed25519VerificationKey2020 and EcdsaSecp256k1VerificationKey2019 but fix some text and examples (alt 1)

[peacekeeper]

This is one out of 4 alternatives to address #12.

The alternatives are:

• Stick with Ed25519VerificationKey2020 and EcdsaSecp256k1VerificationKey2019 but fix some text and examples (alt 1) #31 <-- this
• Always use MultiKey for verification methods (alt 2) #32
• Always use JsonWebKey for verification methods (alt 3) #33
• Always use CesrKey for verification methods (alt 4) #34

I suggest we use this PR here to discuss which one is best, and keep the others clean.

[dhh1128]

I don't really have a strong opinion. As a user of KERI, the CESR alternative would be really nice. It may be a bit cleaner and terser than the other alternatives, because it is self-describing (implying that new key types could get added to it without updating our spec, simply because CESR picks them up). Multikey has that same characteristic, I guess.

The obvious argument in favor of one of the others is: it's what other DID methods use. But before I endorse that argument, I'd like to know how strong it is. Specifically, which of these other methods is currently used by all or most did:web implementations, and does that method support multisig? If the answer is no, then the interop arg falls apart, doesn't it?

Bottom line is I'm more curious than opinionated on this topic.

[peacekeeper]

My impression is that the DID/VC community is more and more moving toward JsonWebKey and MultiKey. The Data Integrity spec defines something called a "controller document", which is basically like a DID document except that it potentially also works with identifiers other than DIDs. And they use JsonWebKey and MultiKey. I expect that a future W3C DID (maintenance) WG will also update the DID Core spec to align with this. So I think the interop argument is strong enough.

Note that there is a way to instruct a resolver to return the verification methods in a format that the client prefers, using the transformKeys extension DID parameter. So we could make the JsonWebKey type the default in the interest of interoperability, but a CESR-aware client could also request a CesrKey type.

Neither JsonWebKey nor MultiKey support multisig (despite the latter's name, haha!). For KERI multisig, I want to try to use ConditionalProof, see #8. I will do a separate PR for that at some point.

[2byrds]

Great points @dhh1128 and @peacekeeper! Multi-sig is a core feature, so whatever we choose it must-fully-support multi-sig.

[2byrds]

Thoughts from our meeting today:

Sam noted:
Support for as many as possible is desired.
Should the default be the most expressive (CESRKey)?
Multi-sig is a core feature of KERI... it is 'multi-sig first'. So the default should be something that support multi-sig.
When it's single sig you could use the other representations.
We'd need to define how to list the keys in did:webs.

[peacekeeper]

Closing, since this was superseded by #39