search

TBD54566975 / web5-rs

Apache License 2.0
6 stars 4 forks source link

Consider enabling optional verification methods #231

Open KendallWeihe opened 1 month ago

KendallWeihe commented 1 month ago

Originally spurred from here, please read the full comment exchange for context https://github.com/TBD54566975/web5-rs/pull/190#discussion_r1607415559

enmand commented 1 month ago

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

decentralgabe commented 1 month ago

what's the use case?

KendallWeihe commented 1 month ago

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 commented 1 month ago

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.