Consider enabling optional verification methods

[KendallWeihe]

Originally spurred from here, please read the full comment exchange for context #190 (comment)

[enmand]

I'll split those changes out of that PR for now so the decision doesn't block it

[decentralgabe]

what's the use case?

[KendallWeihe]

what's the use case?

@decentralgabe refer to the linked comment in #190 for full context. If you disagree with the proposal then please voice your concern.

[decentralgabe]

expounding on my prior comment there are two schools of thought

1. Let's support the specs
2. Let's support a subset of the specs that is sensible

For Web5, we've gone with approach 2. We're exploring whether approach 1 makes more sense.
I have in mind, at least one case, where 2 is a requirement: in the VCDM we do not want to support JSON-LD processing. It is unnecessary for our use cases, adds significant complexity, and security risk (without very careful implementation). We have JSON Schema that serves our needs. Now, when I originally implemented the ssi-sdk I implemented JSON-LD processing to take approach 1. The feature was not ever used - to my knowledge. This does not mean it won't ever be useful, though it was not worth the time or effort to implement it prematurely, nor did it break usage of the data model without LD processing.

This leads to me to my current thinking which is a hybrid of (1) and (2): let's implement the specs to be as useful as possible. This means if there are usecases that can be served (either by us at TBD or the community at large) by implementing features of the specification, we should do it--or at least take these feature requests under strong consideration. Barring that, creating optionality for the sake of conforming to the spec, I believe, creates more risk than benefit.

Directing this line of reasoning toward this issue I will ask: do we have a use case for a DID Document without a Verification Method? I cannot think of one where it would be useful. In fact I think it would be more confusing to resolve a DID, see it has no Verification Methods, and not be able to do anything with it.

---

One alternate approach: support creating DIDs with Verification Methods (required), but resolving/serializing/deserializing without.