Streaming resolution

[clehner]

DID Core includes two functions for resolving a DID: resolve and resolveStream. 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: https://github.com/w3c/did-core/issues/380#issuecomment-680938740

DID Resolution defines the resolve method in Resolving a DID. It also defines a DID Resolution Result data structure for the result of the resolve method. But there is no mention of streams. Should resolveStream 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 call resolve, 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 for resolveStream 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.

[peacekeeper]

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 resolveStream() could be used for "streaming" in the sense that you could process parts before receiving the whole content. Maybe there are use cases for that, not sure, but the main idea of the two functions was that resolve() would return the DID document's abstract data model, and resolveStream() would return a concrete representation.

I think I would like to propose to rename resolveStream() to resolveRepresentation() to make this clearer.

Then when we get into the HTTP(S) binding, I think it would be logical to say that this applies to the resolveRepresentation() function, since you always get a concrete representation of the DID document via HTTP(S). We can update the DID Resolution spec accordingly.

What do you think about the above?

[clehner]

@peacekeeper That makes sense.