-
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. |
I think this can be closed, since |
Closing, per discussion on today's DID WG meeting. |
This was discussed during the did meeting on 10 October 2024. View the transcriptDID Resolution Issue/PR Processingburn: Contact the chairs if anyone would suggest an improvement markus_sabadello: let's start with new issues <markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close markus_sabadello: first with pending close issues burn: note that, in the agenda email, we listed these issues. <TallTed> I strongly recommend such searches be ordered by "least recently updated" to keep the churn active, e.g., https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3Apending-close+sort%3Aupdated-asc burn: the point is, we'll review these quickly today, but the expectation is that you are too look for these in the agenda and speak up or comment in the issue if you have an objection <markus_sabadello> w3c/did-resolution#57 markus_sabadello: Proposal to rename one of the resolution functions burn: any objections to closing? markus_sabadello: I'll close them after the call <markus_sabadello> w3c/did-resolution#30 markus_sabadello: Issue 30, several years old. Has to do with dereferencing discussion at TPAC <markus_sabadello> w3c/did-resolution#29 markus_sabadello: also several years old, about the definition of the term did resolver. <markus_sabadello> w3c/did-resolution#21 markus_sabadello: Issue 21 about removing the term DID Reference from DID core to DID Resolution. <markus_sabadello> w3c/did-resolution#11 markus_sabadello: All methods must have a name of at least three characters. decentralgabe: If we mark it pending close and give it a week, that would address the older participants burn: requirements vary from group to group. In past groups, we've made the point to actively reach out by email and ask for engagement. Then you can comment that in the issue. burn: you have 10 more minutes if you like <markus_sabadello> https://github.com/w3c/did-resolution/issues?q=is%3Aopen+is%3Aissue+label%3A%22good+first+issue%22 markus_sabadello: one other thing. A few issues are tagged as "Good First Issue" <markus_sabadello> w3c/did-resolution#23 markus_sabadello: Issue 23 is about result of dereferencing <manu> JoeAndrieu: Looking at the backlog. There is an opportunity here to make a distinction -- how we talk about a DID with and without a trailing slash... but I don't know if that helps us. I need to look at this in more detail, it's five years old, we can close it, if problem still exists, we can raise a new issue again. <manu> markus_sabadello: I think this might be obsolete by now? <manu> JoeAndrieu: Yeah, sounds like it might be. <manu> markus_sabadello: We will have until next call to look at it or raise a new issue if this comes back. <manu> JoeAndrieu: Sounds good to me. manu: I'm wondering what is the ... I'm fine with closing it. I'm wondering where did we land? markus_sabadello: that's right the resolution response might contain a did document, but dereferencing might return something else manu: i think it's already addressed (as opposed to an older issue that isn't valid) markus_sabadello: this was from when we didn't have a did resolution result, we were just returning DID documents <JoeAndrieu> +1 manu: +1 markus_sabadello: also to be aware of, from discussions at TPAC, when we talked about path, query, and fragment parts. <markus_sabadello> w3c/did-resolution#85 markus_sabadello: There are two open issues for new DID parameters with certain functionality <markus_sabadello> w3c/did-resolution#90 markus_sabadello: The first introduces version-type the second XYZ as parameters burn: ok, you have about another 5 minutes if you'd like markus_sabadello: ok. I'm wondering if we can merge that pull request <markus_sabadello> w3c/did-resolution#89 markus_sabadello: or if anyone has new thoughts about the discussion we had about primary resource and secondary resource manu: I think it is unfortunate that the initial wording was primary and secondary resource, as that is so abstract it is confusing. <TallTed> +1 to manu's suggestion manu: maybe we can call it derereferencing a DID? or a #fragment markus_sabadello: there is something that right now is called a primary resource. manu: yes. that was my thinking. Name the types of things you can dereference. markus_sabadello: this needs to be extensible. we can't imaging all the things they dereference to. <manu> JoeAndrieu: I would like to try my hand at writing this PR, don't know when I'm going to get to it, but want to help. |
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: