Support resolve() and resolveStream() functions #331
Conversation
There was a problem hiding this comment.
Minor nits, otherwise, LGTM.
I was expecting there to be language around how resolve() and resolveStream() are related. Specifically, that resolveStream() is expected to utilize resolve() under the hood without stating anything normative about that. We can add that language in later as it's editorial.
| <a>DID resolver</a> implementations MUST NOT alter the signature of these | ||
| functions in any way. <a>DID resolver</a> implementations MAY map the |
There was a problem hiding this comment.
DID resolver implementations MUST NOT alter the signature of these
functions in any way.
I understand the intent here but I imagine it may trip up implementers ... at least until we get more specific by using, for example, Infra. Then it may be ok to say this. The fact that we already have a normative statement saying that resolvers must implement this function could also be seen as enough and could avoid issues here.
There was a problem hiding this comment.
I think this sentence originally came from @jricher . I'd be fine with removing.
There was a problem hiding this comment.
+1 to just remove it -- since I was also thinking about how there may be some implementations that could provide additional optional parameters, for example, that would not run afoul of any interoperability concerns here. We don't need to be this prescriptive.
There was a problem hiding this comment.
The goal is to ensure interop. If you have additional functions (which might be how you handle optional parameters) then that's fine.
Co-authored-by: Manu Sporny <[email protected]>
| -> ( did-resolution-metadata, did-document, did-document-metadata ) | ||
| </code></p> | ||
|
|
||
| <p><code> | ||
| resolveStream ( did, did-resolution-input-metadata ) <br> | ||
| -> ( did-resolution-metadata, did-document-stream, did-document-metadata ) | ||
| </code></p> | ||
|
|
||
| <p> | ||
| The input variables of this function MUST be as follows: | ||
| The input variables of these functions MUST be as follows: |
There was a problem hiding this comment.
I would recommend splitting the definition of these functions into separate subsections with different descriptions about their inputs and outputs instead of trying to put everything in one block as they are here. This is possible to do as an editorial change after this PR is merged, but the issue shouldn't be lost.
There was a problem hiding this comment.
Agreed, let's do this in a separate PR given that this has taken so long to get into the spec. Let's set down the base, editorial changes will be easier after that's done.
Co-authored-by: Manu Sporny <[email protected]>
|
Normative, lots of WG debate in special topic calls, lots of requested and applied changes, we have consensus with no objections, merging. |
Replaces #322 and #323. Builds on #296 and #297.
During the 2020-06-18 DID WG Topical Call on DID Resolution contracts we had consensus that we should have two abstract functions for DID resolutions - one called
resolvethat returns a DID document as the abstract data model, and one calledresolveStreamthat returns a DID document as a byte stream in one of the conformant representations.After merging this, we can add a few remaining improvements that have been discussed, such as compatibility with the Infra standard, and definition of metadata structures.
Preview | Diff