-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Streaming resolution #57
Comments
Hello @clehner sorry for the late response, you bring up some very good points here. The DID Resolution spec is unfortunately lagging behind a bit and we need to update it to reflect the latest version of DID Core. The idea behind the two functions was not so much that I think I would like to propose to rename Then when we get into the HTTP(S) binding, I think it would be logical to say that this applies to the What do you think about the above? |
@peacekeeper That makes sense. |
DID Core includes two functions for resolving a DID:
resolve
andresolveStream
. They return a DID document (abstract representation), or a DID document stream (concrete representation), respectively, along with document metadata and resolution metadata structures. More info: w3c/did-core#380 (comment)DID Resolution defines the
resolve
method in Resolving a DID. It also defines a DID Resolution Result data structure for the result of theresolve
method. But there is no mention of streams. ShouldresolveStream
be defined here too?If
resolveStream
is defined, should there be a corresponding resolution data structure and/or HTTP(S) binding?Currently, if a client or proxy wants to call
resolveStream
with a HTTP(S) DID resolver, they would have to callresolve
, decode the JSON resolution result, and re-encode the document as a JSON byte stream (unless their JSON parser provides pointers into the original data). This would be not very stream-friendly: the caller would probably have to buffer the resolution result before returning the metadata and stream, even if using a streaming JSON parser, since the "didDocument" value may arrive before the "didResolutionMetadata" and "didDocumentMetadata" values. A HTTP(S) binding forresolveStream
could provide a nicer streaming interface. For example, resolution metadata and document metadata could be encoded in HTTP response headers, and the document stream provided in the HTTP body. Or,the body could contain a delimited concatenation or multipart encoding of the encoded resolution metadata and document metadata followed by the document stream. Perhaps the DID Resolution Result data structure could be reused, with the "didDocument" omitted for the DID document provided subsequently as a stream.
The text was updated successfully, but these errors were encountered: