[Universal DID Operations] Issues/comments related to the proposed HTTP bindings

[mwherman2000]

Reference: https://github.com/WebOfTrustInfo/rwot8-barcelona/blob/master/topics-and-advance-readings/Universal-DID-Operations.md

@peacekeeper I've documented several DID resolution use cases (and their proposed HTTP bindings) here: w3c/did-resolution#32

Issues

1. To be complete, I recommend that your paper also highlight the current state with respect to DID Document resolution and dereferencing because there represent good patterns for the additional capabilities you are proposing.
2. Although your proposal make sense for a programmatic API, I feel strongly that the proposed HTTP bindings are much more complex that they need to be or should be.
   I believe we should strive to keep the DID Document algebra as concise as possible.
3. For example, the method and options parameters for the create() method should be simply encoded into a single did parameter IMO. Let's not create additional, more complex syntax where it is not necessary. See did-url Use Cases: did-url Syntax Examples (and corresponding HTTP Binding Examples) w3c/did-resolution#32 (comment)

[peacekeeper]

Thanks for your feedback. As I noted in w3c/did-resolution#32, my initial reaction is that I think it's important to have a clean separation between DID (URL) syntax, and the operations that can be performed on them, just like e.g. the HTTP operations (GET, POST, PUT, etc.) are not part of an HTTP URL, but rather part of a protocol that operates on HTTP URLs. But I'd like to talk to you to understand better your rationale.

[mwherman2000]

@peacekeeper I've separated the proposed DID URL syntax for each use case from the HTTP bindings in w3c/did-resolution#32 ...although they remain closed related ...as one would (hopefully) expect. There is no need to have multiple syntaxes/languages for performing the same operations ...especially for simple operations like dereferencing.