Draft refactored dereferencing algorithm outline - #331
Conversation
peacekeeper
left a comment
peacekeeper
left a comment
There was a problem hiding this comment.
change from DID to DID URL as an input to a resolution request
I'm strongly -1 to this change. I think it would break A LOT of existing DID implementations and infrastructure and would not be backward compatible.
It's completely incomprehensible to me why people want to make this change??
We should keep the clear separation between "resolving a DID" and "dereferencing a DID URL" that we have always had.
|
Yes @peacekeeper I am aware you are strongly against this change. This PR is not about the change from DID to DID URL as the input to DID Resolution. We are trying to get consensus on the high level outline for refactoring the dereferencing algorithm so things can start moving forwards again. Can you review and provide feedback on this outline please. I do want to have time on a call to discuss and make a final decision on DID vs DID URL as DID Resolution input. I think there are good arguments for changing to DID URL, e.g. the client does not need to understand the query parameters that are method specific or how to parse them. I also think there are ways to make this change while still being backwards compatible. A DID is a kind of DID URL after all. As you have been unable to join calls recently, we may end up having to make this decision without you. I would prefer to discuss it first. |
|
+1 to merging this. For the record, I think it is a mistake to advance the spec in the manner the group has decided, as it leaves the spec in an inconsistent state. Hopefully we can resolve quickly that the public drafts are coherent again. |
I think this change would make most DID 1.0 resolvers non-conformant, because they expect to resolve a DID, not a DID URL. If you pass a DID URL with a path and query into a DID 1.0 resolver, I'm pretty sure that most of them will break. Same for most of the DID methods.
Could you then maybe remove the language from the PR that talks about "resolving DID URLs" so we can review just the proposed new outline without such substantive changes? |
|
I thought I had already done that. If you get a chance could you propose changes |
| <h1>DID URL Dereferencing Algorithm</h1> | ||
|
|
||
| <section> | ||
| <h1>Prepare to resolve DID URL</h1> |
There was a problem hiding this comment.
| <h1>Prepare to resolve DID URL</h1> | |
| <h1>Prepare for resolution</h1> |
Maybe this @peacekeeper
There was a problem hiding this comment.
@peacekeeper really looking to get this merged. Would appreciate your input since you are the only one objecting to the contents of this PR
There was a problem hiding this comment.
I'm sorry but this PR still suggests "resolving DID URLs" in several places, this would be a breaking change that I think is really not acceptable...
There was a problem hiding this comment.
Well I would appreciate it if you would propose changes to all the places. I think it is only this one.
The rest are saying prepare DID URL for resolution. That might mean extract the DID and resolve the DID. Or it might mean resolve the DID URL. It is ambiguous at this moment. Intentionally so.
I just want to get the scaffold in for the refactored algorithm so we can move forward to the details of defining the actual algorithm steps.
The WG needs to discuss DID vs DID URL for resolution. I understand your concern that this is a breaking change. The intention of this PR is not to make or imply that we have made this decision.
Co-authored-by: Ted Thibodeau Jr <tthibodeau@openlinksw.com>
|
Hmm, I am confused what has happened here. Now the PR is showing every line has changes against it. It definitely didn't when I submitted it :( |
|
Okay. So I fixed the PR although could do with some advice around line endings. The line endings of main are LF (but maybe I did that in my formatting). My PR also had LR, but when I applied the suggestions, for some reason github changed them to CRLF. Do we have a preference? Feel like LF is right looking online, so no idea why the code suggestions should have changed this. Anyway, it is clean now. @peacekeeper I intend to merge this PR on Monday at the latest. I understand you are unhappy about the DID vs DID URL distinction, I have tried to fix that. When we decide on DID vs DID URL for DID Resolution we can come back in and clarify the text further. |
|
I object to this merge, there was no consensus on this. This PR blurs the lines between DID Resolution and DID URL Dereferencing, which is highly problematic. I request that the PR be reverted. |
|
To clarify (once again) the problems I see with this PR:
Saying or suggesting that DID URLs are "resolved" is a major breaking change that is not compatible with DID 1.0, see: https://www.w3.org/TR/did-1.0/#did-resolution |
|
This was discussed during the #did meeting on 28 May 2026. View the transcriptw3c/did-resolution#331Otto Mora: Uh-huh... Joe Andrieu: Oh, sorry... Otto Mora: the Kim just enabled queue, uh… Okay... Will Abramson: Open... Otto Mora: Take it open. Okay, there we go... Joe Andrieu: Oh, thank you. Cool. Um... Otto Mora: Mm-hmm... Will Abramson: Uh, yeah, that makes sense to me, too. Uh... Otto Mora: Yep... Will Abramson: Welcome... Otto Mora: Uh, Marcus?... Markus Sabadello: Yeah. So again, I I think I I would agree to 3, 3, one. If it really separated the the topic of Ddrl versus the admit, maybe that would be the the easiest way forward to just remove the 1 1 or 2... <Zakim> manu, you wanted to ask Markus if he'd object if we took the term "DID URL" out of that PR? Markus Sabadello: phrases that say something like, prepare the DDRL for resolution, or… A lot of things like that Otto Mora: Mano? Mm-hmm... Manu Sporny: Yeah, I was just gonna ask Marcus that. So what if we, instead the proposal is remove the term did URL from the merge text from PR 331. I would imagine we should be able to achieve consensus. Undoing that, and then we move on to the DID URL versus DID input to DID resolution. Does that feel like a? Password... Will Abramson: uh... Otto Mora: Yes... Will Abramson: And just not reference the inputs at all... Markus Sabadello: Both, I think it would be fine. I think that would be fine. There was a second place somewhere in the in the language. I, I don't remember now, but there were two, two sentences that there was another one. So if we change them... Otto Mora: Okay, so... Will Abramson: Uh, yeah, I'll just type something up, and let's see... Otto Mora: Okay. Will, I don't know, do we run a proposal with specifically noting... Will Abramson: I think... Markus Sabadello: Uh… yeah, it was... Will Abramson: Mm-hmm... <markus_sabadello> - "prepare the DID URL for resolution" <markus_sabadello> - "preparing the DID URL and any accompanying DID Resolution Options for a resolution request" Otto Mora: Okay... Joe Andrieu: Is that a yes to me, Otto? Sorry... Otto Mora: Uh, Joe, go ahead, yeah, sorry, go ahead. Uh, I see... Joe Andrieu: Yeah, I think the language as it is currently should be okay with what you want, Marcus... Otto Mora: Well... <JoeAndrieu> +1 Will Abramson: Yeah, I mean, that was my perspective too, but I think, you know, like, if this is gonna solve the problem, I'm happy to remove DigURL from it, and we can always add it back in, right, when we make this decision, which… I'm running out of time. I just want to make the decision to move forward, so... Otto Mora: Mm-hmm... Will Abramson: Is everyone okay with the text that I'm emoted? Update PR331 to remove reference to dig URL. I'm stuck. 5.1... <TallTed> I hope someone has the time to spare to review and polish these robotic IRClogs/minutes, as they'll be indecipherable to many as they stand (e.g., "prepare the DDRN", "preparing the DTRL") Otto Mora: Mm-hmm... Will Abramson: Okay... <ottomorac> Proposal: Update PR331 to remove reference to DID URL from Step 5.1.1 prepare for resolution Otto Mora: Uh, yeah, okay, so I'll just propose all... <manu> +1 <Wip> +1 <ottomorac> transcriber-bot, pause <JoeAndrieu> +1 <swcurran> +1 <smccown> +1 <markus_sabadello> 0 don't like how it removes the dereference() abstract function, but wouldn't object anymore if the relevant updates are made <TallTed> +1 <ottomorac> +1 RESOLUTION: PR331 to remove reference to DID URL from Step 5.1.1 prepare for resolution <ottomorac> transcriber-bot, resume Otto Mora: Uh, yes, Will... Will Abramson: Yeah, I just wanted to speak to Marcus's zero just briefly that, you know, I mean, I thought we had made a decision about that, but either way, like, I wasn't intending to make any of those decisions in this PR. This really is about, like, taking a step in the direction towards resolving this did URL be referencing... <swcurran> YES!! Will Abramson: So, um, that's all. Uh, I see we've got 6 minutes left. Do we think we are able to run a proposal about DID versus DID URL today? Like, would anyone be opposed to us doing that? Do you think there's more conversation that we should be having? Otto Mora: Uh, Marcus, is that the queue?... Markus Sabadello: I really don't think this has been sufficiently discussed. I think, everybody's trying to explain it patiently, but I also feel like, for example, Manu's second explanation, I think, was very different from the from the first explanation... Otto Mora: Mm-hmm... Manu Sporny: Uh, they were two different reasons, Marcus. They were not meant to go together, um... Otto Mora: Uh, Ted... TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Just quickly, it's totally legit, Marcus, for you to open an issue which we can hold open until... Otto Mora: Yeah, I mean... <manu> +1 to what TallTed said -- there's still time for Markus to understand the arguments for this path. Otto Mora: re-emphasize and say, yeah, like, uh, we will have one last conversation around this first thing on the next meeting, uh, of the larger group, and then early on in the next. Let's see any other comments Will Abramson: However… Yeah, I guess I'm on the queue. I mean, I wanted to say, too, like, I agree with Otto. I do want to make this call this week, and I'm sorry that we didn't quite have time for it, but it does feel rushed to do it in the last few minutes of the call... Manu Sporny: We're not going to be here... Joe Andrieu: Well… yeah... Will Abramson: Oh, yeah, of course... Joe Andrieu: Sorry, Will... Will Abramson: Got it... Otto Mora: Mmhm... Manu Sporny: I'm very frustrated by all of this, just to get it on the record. It's super frustrating. We're not going to make this decision for another two weeks again, you know... Will Abramson: But it is 2 weeks out... Otto Mora: Yep. But, yeah. Yeah, I think it should be on the Thursday call, just to enable larger... |
7 participants
Okay, here is an initial attempt at the refactored algorithm outline based on the discussion in the WG call. Noting that we did not quite get through all of it.
My sense from the discussion is:
Steps 1 prepare to resolve and steps 2 execute resolution request have broad consensus.
Modulo the change from DID to DID URL as an input to a resolution request that I know at least @peacekeeper disagrees with. Whilst I do want to get to a WG decision on this matter and move on, I have tried to separate this issue from the high level refactor this PR proposes.
Step 3 Determine Retrieval Strategy also felt like we had good agreement on as a high level step. @peacekeeper noting that you have mentioned you do not like term "Retrieval Strategy". We could change the name and I am open to proposals here. Although dereferencing does involve retrieving a representation of a resource - I dont think its a bad name.
Step 3 involves handling the path and query components of a DID URL. We are going to need to dive into the details of step 3 later on - hopefully Thursday - to unpack what this actually means.
Step 4 Retrieve the resource. This is where #326 diverges with the current spec text most clearly. The current spec does not attempt to retrieve the resource at all, it just returns the URLs to the resource and leaves retrieval out of scope. As noted this implies that retrieval involved HTTP GET on a URL, which is not always the case. It does not create space for extensions to define custom retrieval strategies for their use case. We noted that all services should define how to retrieve the resource identified by the serviceEndpoint, rather than leaving it implicit.
We also discussed, and agree, that it is not the DID Resolution specs responsibility to define how to retrieve resources of different types. The client either knows how to retrieve a resource according to some strategy and can do so, or they do not. I tried to capture that in Step 4.
Step 5 Use the Resource. We ran out of time for this one, and I think it is the step that has the least consensus. At least I know the name is throwing some people off. This step is not really defining how someone should use a resource, but that the resource is available within the application. It also handles the fragment processing part of dereferencing if present.
I tried to capture that Step 5 may either return the resource or use it within the application context.
I haven't yet specified precisely the inputs and outputs of the different steps, although I think the text does make it pretty clear.
I also haven't wrote a new intro to the DID URL Dereferencing section or attempted to define inputs and (optional) outputs to the algorithm as a whole.
There are also some terms that @jandrieu used in #326 that I think would be useful to include that I have not yet included. E.g.
Happy to add these in, but wanted to get a sense check from the group. We can discuss on Wednesday.
Preview | Diff