Conversation
Signed-off-by: Stephen Curran <[email protected]>
Signed-off-by: Stephen Curran <[email protected]>
|
Let me attempt to highlight the key differences between this proposed approach and the approach taken in #311. Maybe it will be useful. The Path handling part of derefencing in this PR:
In #315 the approach is different and revolves around determining a retrieval strategy. It also implies that only a single resource will be retrieved I believe. Retrieval strategy is determined in a prioritized ordering.
Trying to keep this high level so we can get to the technical differences here. Differences I see are:
Personally, I feel if a DID URL defines a
My sense is that there are legitimate cases when a DID URL is targeting multiple resources. Or at least multiple services, for example the serviceType parameter I thought was for selecting all services of a specific type not just one.
Probably there are some more, but these were the main ones I noticed. Hoping this can help us have more constructive conversations about these two proposals and move towards consensus. |
|
This was discussed during the #did meeting on 02 April 2026. View the transcriptDID Path PR \[2\] (15 min)<ottomorac> w3c/did-resolution#316 Otto Mora: Yes, let's do our best to just get this done. Um Stephen Curran: Yeah, it's 316 now... Otto Mora: Okay... Stephen Curran: The attempt at resolving the conflict was a disaster... Otto Mora: Does it need one... Stephen Curran: Um, I think, Will, you just said it looks like there's a place where I say a list of service objects one more time, or is it more… more than that?... Will Abramson: Uh… yeah, well, definitely that needs to be fixed. That's a mistake just in the current approach... Stephen Curran: Yeah... Will Abramson: Yeah, I guess... Stephen Curran: Oh, absolutely. I... Will Abramson: Um… uh... Otto Mora: Mm-hmm... Stephen Curran: So, in, in looking at the 2, I think, um, Jose, while, while the repositioning. of Joe's, um... Otto Mora: Mm-hmm... Joe Andrieu: Okay, so I believe that's our next, uh, agenda item. It may have been easier if we had done that agenda item first, but... Otto Mora: Okay, so let me just try to suggest something, okay?... Manu Sporny: Um, right, so, uh… High-level comment first. Um... Otto Mora: Okay, uh, let… we'll jump in here... Will Abramson: Yeah, sorry. Yeah, I wanted to speak to one thing that I maybe disagree with in Stephen's PR specifically... <Zakim> TallTed, you wanted to say that a URL refers *semantically* to a single resource. Something like "today's complaints" may redirect to `.../2026/03/15.foo` and `.../2026/04/15.foo` in March and April Otto Mora: Mm-hmm. Okay, uh… Good... TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, this will be fairly quick, um... Otto Mora: Mm-hmm... <Zakim> JoeAndrieu, you wanted to say the amount of time we've spent arguing a PR is not an argument for accepting it Otto Mora: Uh, yes, so, uh, we have Joe. Joe, go ahead Joe Andrieu: Um, yeah, I agree with what you just said, Ted. Um, I didn't mean to say that the... <manu> +1 to what Ted is saying -- you can have one URL that leads to multiple options. <manu> no, that's wrong Joe Andrieu: resource returned is the same every time you evaluate and dereference a URL, but rather that one resource is returned. For any given dereferencing. Um <manu> https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/300 Joe Andrieu: I think that's just how it works. Uh, to Manu's comment, I'm actually… I don't… I'm really confused, because I did, in fact, outline very specific technical things that I don't believe this does <pchampin> a resource is not returned; a representation of the state of the resource is returned Joe Andrieu: Um, and you just said you don't think I understand the spec, but, um, I think it should be service-as-service type first. I think there are precedence issues. Um, I don't think we should be returning multiple resources, and I think we should have some sort of path handling type that any path handling <manu> No one is saying that, Joe Joe Andrieu: that we should accelerate the adoption of that PR. The argument itself over this that has taken a long time should be an indicator that we're not there yet Otto Mora: Mm-hmm. Mm-hmm. And just one more thing, so the concern around the link resources, that's... Joe Andrieu: Um, I do still have that concern. I haven't read this, and I know that Steven was trying to find a way to make it extensible, and so I don't know if he has managed to cross that gap or not... Otto Mora: Okay, so just one thing on that, it might be useful, like, um... <ottomorac> w3c/did-resolution#260 (comment) Otto Mora: Alex from, uh, Checked did… I just put it in the Zoom, but I also put it here in the IRC <ottomorac> "Reading the updated §6.4.1 algorithm, Step 8.1: "If the DID Method specifies its own path handling algorithm, use that algorithm, skipping the rest of these steps", is exactly the right design for DLR-implementing DID methods. They define their own path handling and bypass PathService entirely. This confirms the layering is sound." Otto Mora: Yeah, he posted this bit here, I'll just paste it Joe Andrieu: Right, so we should clarify, did linked resources is not linked resources... Otto Mora: Okay. Perfect. Uh, Steven... Stephen Curran: So much to respond to. Uh, Will, on your point on the service types and service, if you specify those in a URL, I'm happy to do that... Otto Mora: Okay. Uh, Manu?... <manu> https://datatracker.ietf.org/doc/html/rfc7231#section-6.4.1 Manu Sporny: Uh, on the multiple choices thing, what Steven said, I'll also point out that RFC 7231 allows there to be a response for… that there are multiple choices for a given URL... Otto Mora: Okay, and then... <Zakim> JoeAndrieu, you wanted to point out that dismissing my concerns because Manu disagrees doesn't address my concern. Otto Mora: gets to see the changes proposed by Joe. So, Joe, like, uh, yeah, go ahead Joe Andrieu: Um, yeah, Manu, I think we've just done that twice now, so I'm getting extremely frustrated with what feels like abuse of process to keep demanding that I say something that I've already said... Otto Mora: Uh, Steven, uh, Manu, and then I think let's just close off. Conversation... Stephen Curran: I'd like to move on, I think, um... <JoeAndrieu> I will list my concerns in the PR when I can get to that Otto Mora: And yeah, I think maybe then this also be a topic of… a special topic called the… Uh, yes, madam... Manu Sporny: Yeah, just to try and clarify, Joe, I am not dismissing your concerns... Joe Andrieu: Manuel, I have to interrupt, I've said it now twice, you just didn't like what I said... Manu Sporny: What? No, I don't know what you said, Joe. I literally… I don't… in my... Joe Andrieu: Look at the transcript, Manu, I iterated 3 things that I felt I was concerned about, and you're saying I'm not saying anything. You are misrepresenting what… how I am contributing... Stephen Curran: What... Otto Mora: Okay, okay, so, so, folks, we're really not gonna get... |
Signed-off-by: Stephen Curran <[email protected]>
|
Addressed @wip-abramson 's issues:
|
|
I'm still not convinced that the PathService addition is desirable. Do we really want to add this additional complexity to the algorithm, just so that we can write instead of ? I think it's a feature, not a bug, that dereferencing of a DID URL path is completely method-specific, just like resolving the DID document is method-specific. I also see a risk in this proposal that dereferencing of a DID URL path via HTTPS-based PathService is dependent on non-decentralized DNS and web infrastructure, whereas dereferencing of a DID URL path via the DID method would fully inherit the "decentralization" principles of DIDs. But as I said before, I think this PR doesn't really break anything and is backwards-compatible. It feels nicely specified now. I also agree with @tweeddalex ' analysis that PathService and DID-Linked Resources can be complementary. So even though I personally don't like this very much, I don't object... |
| Resolution</a> based on either: | ||
| <ul> | ||
| <li>[=DID service endpoints=] selected from the <a>DID | ||
| Document</a> using the `service` or `serviceType` query | ||
| parameters; or</li> | ||
| <li>a URL generated from a <a>DID URL</a> that contains a path | ||
| component.</li> |
There was a problem hiding this comment.
| Resolution</a> based on either: | |
| <ul> | |
| <li>[=DID service endpoints=] selected from the <a>DID | |
| Document</a> using the `service` or `serviceType` query | |
| parameters; or</li> | |
| <li>a URL generated from a <a>DID URL</a> that contains a path | |
| component.</li> | |
| Resolution</a> based on one of the following: | |
| <ul> | |
| <li>A [=DID service endpoint=] selected from the <a>DID | |
| Document</a> using the `service` or `serviceType` query | |
| parameter.</li> | |
| <li>A URL generated from a [=DID URL=] that contains a path | |
| component.</li> |
| `pathAlgorithm` attribute is not present, it MUST be | ||
| treated as if set to `relative-ref-2026`.</li> |
There was a problem hiding this comment.
| `pathAlgorithm` attribute is not present, it MUST be | |
| treated as if set to `relative-ref-2026`.</li> | |
| `pathAlgorithm` attribute is not present, then processors | |
| MUST act as if it were set to `relative-ref-2026`.</li> |
There was a problem hiding this comment.
This appears to be a severe example of indent changes due to tabs being used instead of spaces. Please don't use tab indents!
| <a>DID URL</a> path that the object matches, or zero if | ||
| no match is produced. Then eliminate all objects that | ||
| produced no match, and all but the objects that | ||
| produce the longest match. |
There was a problem hiding this comment.
| produce the longest match. | |
| produced the longest match. |
| characters) of the longest case-sensitive prefix of the | ||
| <a>DID URL</a> path that the object matches, or zero if | ||
| no match is produced. Then eliminate all objects that | ||
| produced no match, and all but the objects that |
There was a problem hiding this comment.
| produced no match, and all but the objects that | |
| produced no match, and all objects but those that |
I think we discussed before that this would create problems with query parameters. There would be no way to distinguish between "parameters for the resolver/dereferencer" and "parameters for the service endpoint". |
This sounds interesting, can you give an example what the DID URL(s) and DID document would look like in this case? Not urgent, I'm just curious.. |
|
For a cheqd case, an AnonCreds schema on Cheqd has a URL |
|
Hit submit too fast on that last note. There are other options. For example, where is no path for the resource to be referenced, the full path in the DID URL might be matched so there is nothing added to the |
The linkedResource extension is not did-method-specific. Any controller could add a linkedResource to any DID method that supports adding arbitrary properties to the DID document (as all should for extensibility reasons, but in practice some restrict the properties allowed), including did:webvh. So if a linkedResource points to an on-chain resource--or an embeded resource--it needs to be processed, even if the DID method itself has some alternative path handling approach. If a controller of a did:webvh DID adds a linkedResource, that should be respected even if did:webvh has a proprietary path handling algorithm. (Replace with any DID method). IMO, what is in parameters and the DID document should prevail over anything "did method specific", which should be a fallback for those DID methods who support features not covered by parameters or properties. |
Your algorithm already does, it just doesn't carry it through. You state that you gather objects whose properties indicate they are path handlers, but then later, you refer to that set as "services" but linkedResources isn't a service, so those later steps in the algorithm are mispecified. You can probably just say "objects", which will bring into focus any assumptions we might have about those objects, e.g., we can't assume they have an endpoint value.
Define a type parameter that any object can add that indicates it is a path handler, e.g., a linkedResource would need to add the single annotation so the type definition (based on the example in the registry https://www.w3.org/TR/did-extensions-properties/#linkedresource ) looks something like {
...
type=["pathHandler","hashgraph"]
}
When the DID URL only has a path (no query part) , I fully expect linkedResources to continue to work as it does today, which is DID method independent.
Respectfully, the text makes is clear that DID method customization is considered first. That means that any new DID method can override the path handling, regardless of the DID URL and any properties. 7.1) If the DID Method specifies its own path handling algorithm, use that algorithm, and skip the rest of these steps.
The biggest problem with relative ref is the dependencies on 3986 which I don't feel have been fully understood. I'm up for removing relative ref altogether, but we would have to define a new path handling algorithm to replace 'Relative Ref 2026' which is at the core of your proposal. IMO, that's probably the right call anyway, as the 3986 algorithm doesn't do what I think most people in this work think it does. |
|
To add to that last comment, I think a path handling algorithm that does what Stephen wants is going to be much simpler than the 3986 definition. In particular, if all we want to do is to treat the start of a path in the DID URL as the signal for interpreting the rest of the path (and do a mash up that retains the base path as specified in the service), then we don't need to support queries nor do we need to defer to the overly complicated 3986. A simple concatenation of paths, ignoring queries is much much simpler. If desired, we could even specify that queries in the DID URL are ignored by the path handling, always preserving any query part in the base path. When we invoked 3986 in relative ref, I think we brought in more trouble than we knew. |
|
@jandrieu -- re: your comments here about Linked Resources and DID Method specific. Sorry I wasn't clear in the comments, but I agree with almost everything you have in that comment. In the example, I was trying to show that a PathService, could have a non-HTTPS I don't agree that a DID Method specific mechanism is necessarily a fallback. If the DID URL references an on-chain resource, where the DID URL is the ONLY identifier for that resource (that's the point of the DID URL), then it should take precedence. |
I can use Your PR makes this a dead end and breaks current functionality of
I'm compelled to repeat myself. The point of the DID Resolution spec is to expose a common API for resolution so that all clients that use DID URLs, i.e., all DID-enabled applications, can use a common algorithm without intimate knowledge of every method, just as http enables all web browsers to interact with any website without intimate knowledge of whatever content might be communicated over http. Method-specific customizations are the job of the resolver--which does have to know the unique features of the DID. The resolving client should not need to know anything about a DID method other than which resolver they trust to return an authoritative DID document of that DID method. |
|
@jandrieu -- I have never intended to say that Linked Resources is DID Method specific. Sorry if that wasn't clear. What I said was that when the resource is uniquely identified by a DID URL with a path, then the associated DID Method would handle the DID URL. That is independent of whether the DID URL is passed directly, or determined via a PathService, DID Linked Resource, Linked Resource or some other "path handling object". For a concrete example, a DID URL that uses DID Linked Resources to reference a Cheqd-hosted resource is retrieved using the Cheqd DID Method-specific software. The presence of the "did:cheqd" tells us to use that. |
|
The comparisons between PathService, DID Linked Resources (DLR) and Linked Resources (LR), raises a topic that I've not yet seen mentioned on this PR, but should be. Both DLR and LR have additional capabilities that are not addressed in PathService -- the inclusion of attributes that get at the verifiability of the resource and its relationship with the DID after retrieval. For example, LR and DLR objects may contain a hash and/or cryptographic proof that can be verified to attest to further attributes about the resource. This has not been included in PathService, but could (and probably) should be -- if optional. These can also be addressed in a query parameter for a hash, and are not needed if the resource itself if self-certifying, such as the Attested Resources that we defined for AnonCreds objects with did:webvh (but could be used with other DID Methods). ADDED AFTER POSTING DID Linked Resources also supports an "inline" feature where the resource can reside in the DIDDoc. If the resource's URL is a Data URI as defined by RFC 2397, (Data URI Wikipedia Link), then it can be embedded in the DIDDoc as part of a PathService. Happy to discuss in the group. |
|
Addressing the set of issues in @jandrieu 's comment here.
|
Signed-off-by: Stephen Curran <[email protected]>
Signed-off-by: Stephen Curran <[email protected]>
Respectfully, that simply is not true for linkedResources today. I've expanded on that in other comments, but you seem to keep asserting an incorrect understanding of how linkedResources work. I don't blame you for the confusion as the documentation for that is not particularly accessible. (It sucks when funding for advancing the standards gets cut.) However, I would appreciate some respect for actually knowing what I'm talking about, as I defined that property. You keep saying you can reduce it to a URL and, I'm sorry, but you can't. |
linkedResources also supports inline resources. Precisely because RFC2397 is not suitable for several distribution strategies. I hate to repeat what I've said in other comments, but the functionality specifiable in a linkedResource simply is not reducible to a URL. Not a DID URL. Not a data: URL. We would have used that if it was sufficient. It isn't. |
I am someone with JSON-LD knowledge. That is how type extensibility works. You simply add the types that apply to the object. You can have as many as you want. |
It isn't knowable if the DID URL is the only identifier for the resource. And if you did, you still wouldn't know if the DID method is the place that defines how to retrieve it. You can add a IMO, the only reason to have a fallback for DID methods is because we have an unfortunate legacy of suggesting that problems can be solved just by making them "did-method-specific". So we believe such things might be out there, but I actually haven't heard of any specific examples. It's a bit of a hack to say, hey, if you still rely on a DID method that does something weird, and that's the only way you can solve it, then you at least have a non-interoperable back door you can use. Unfortunately, placing DID method customization FIRST literally creates interoperability problems. The goal in THIS spec is to remove as much did-method-specific processing when using a DID URL. All the client really should need to know is whether or not they have a resolver they trust for the method in a given DID. That resolver encapsulates all DID method specific processing. Clients call that resolver using a our resolve API. Then they interpret the returned DID document based on the properties in that DID document. Finally, they may interpret query and fragment parts to cherry pick the right parts of the DID document for their context, such as gathering the public key from a verification method to check a proof. That architecture has nearly zero dependency or interference from did-method-specific path handling that they may or may not know about. |
|
This was discussed during the #did meeting on 08 April 2026. View the transcriptw3c/did-resolution#316Otto Mora: Yes, go ahead, Steve and Dan, maybe we can start. Start there... Stephen Curran: Okay, so, um, I did, uh, do you mind if I share screen? I did that presentation that... Otto Mora: Uh, yeah. Go ahead, Joe... Joe Andrieu: Oh yeah, I would just, you know, the queue's helpful, so… um… The... Stephen Curran: I, I... Joe Andrieu: linked resource property is not did method specific, so I can… I can put a linked resource in a DIDWEBH and embed the resource... Stephen Curran: It's the URL!... Joe Andrieu: And there is no URL that can represent that. So, even a did URL, because it is not a did at the end of the day. It is a did that is pointing to this resource, which is in the did document, or specified in the did document. So it's not... Stephen Curran: So the URL is the div URL. That's what I'm saying. That's exactly what I'm saying. I canceled it... Joe Andrieu: Yes, and the did URL has a WebHD method, which has no method-specific path handling properties... Stephen Curran: No, no, no... Will Abramson: Oh. Well, I'm on the queue... Otto Mora: Yeah, go… yeah, go ahead, Will... Will Abramson: Yeah, I just wondered, like, does this need to go first? Like, what's the argument for putting this first, as opposed to, like, putting it at the end?... Stephen Curran: Because the rest of the things don't apply, and if that is the case... Will Abramson: I guess I'm wondering, like... Dmitri Zagidulin: Right... Will Abramson: And in the other case, we would be saying, no, they did not have the specific thing comes last... Dmitri Zagidulin: So, can you give an example of what you mean by target, something in the document?... Joe Andrieu: There's a queue, Dimitri... Will Abramson: Like, for... Joe Andrieu: But go ahead and answer, Will. Okay... Dmitri Zagidulin: There's… oh, whoops, sorry, sorry... Joe Andrieu: Sound good... Will Abramson: Like, for example, I would have, like, a, you know, a Path service... Otto Mora: Uh... Joe Andrieu: Um, yeah, you keep using the phrase that that's the only way you can identify that resource, um, but we don't know that, so we can't use that as guidance or heuristic in the algorithm... Stephen Curran: Yep, okay... Joe Andrieu: If this issue that… you imagine that there's a way to reduce this to a known resource... Stephen Curran: Not really. Um… queue, sorry... Otto Mora: Q is, uh, next up, Dimitri. Jimmy... Dmitri Zagidulin: Joe, I think I see what you're saying, uh, in your current comment. My question was. if I… if I understood correctly. your… original... Otto Mora: Go ahead, George, you can respond... Joe Andrieu: Uh, sure, thanks. Um, no, my concern was that PATH Service dismissed the work of previous efforts and did not find a way to integrate it. It's not about precedence, it's about... Otto Mora: Okay, I know that, uh, Joe was there, but he just responded, so, uh, Steven... Stephen Curran: Yeah, so I think given that, and the argument's good about the precedence, um, it should go... Otto Mora: Okay, and I see Marcus has his hand up, so… uh… yeah, it's not an IRC, but go ahead, Marcus... Markus Sabadello: So I don't… I don't really understand why... Otto Mora: Mm-hmm. Uh, uh, Joe... Joe Andrieu: Um, uh, Marcus, you might be right about did linked resources, but linked resources is a different thing... <Zakim> JoeAndrieu, you wanted to say because any did document can have that property. It has nothing to do with did methods Joe Andrieu: And linked resources is not at all did method specific. It is a property that's in the extension registry. I can have a linked resource property Markus Sabadello: Okay, thanks. Sorry, I mixed those up then. Sorry... Joe Andrieu: Yeah, I think they… they're just… they have the metadata engagement, which I think does sort of entangle the did method. Um... Otto Mora: Uh… yeah. Well... Will Abramson: Yeah, I guess I just wanted to build on that, maybe, and say, like, that does seem to be the core of the... Otto Mora: I don't see anybody in the queue, but I see Steven wrote down a proposal... Stephen Curran: Um, I guess in response to Will's, I just went on a few, um, in response to Will's, um... Will Abramson: Hmm... Stephen Curran: I mean, and I guess I'll... <JoeAndrieu> +1 Otto Mora: Uh, Marcus, is it Nikhil? Breakfast... Markus Sabadello: Um... Stephen Curran: No, I'm looking at my spec, um, version, uh, because we're talking about this… this PR... Markus Sabadello: Okay, then I just want to say that in the current specification, there is such a fallback, right? In the algorithm, it covers... Stephen Curran: That's… that's this section here... Otto Mora: The .8, otherwise, if the date, okay... Stephen Curran: Um… Moving on to the next topic... Otto Mora: I guess, yeah, nobody disagrees with moving it down to 7.6. I don't see anybody… Agreeing there… So, yeah. Go ahead... Stephen Curran: Does it… um, so this is one thing Manu raised, um, um... <Zakim> JoeAndrieu, you wanted to ask return from what? Otto Mora: Okay. Uh, yeah... Joe Andrieu: Um… yeah, my… my question was because, um... Otto Mora: Okay, uh, Marcus?... Markus Sabadello: Um, in the case of did linked resources, the result of dereferencing is, is the resource itself, right? So it's, it's not a... <swcurran> +1 to what Markus Markus Sabadello: in the case of the service parameter, so if you have a DTRL with a service parameter Otto Mora: Uh… Steven?... Stephen Curran: Um, two points. I fundamentally don't agree with Joe's comments about, um... Otto Mora: Joe?... Joe Andrieu: Yeah, Steven, I'd like you to unpack what you don't like about the client definition, since I'm using the definition that's in the spec right now. Which is, it's the software that calls the resolver... Stephen Curran: Um, again, to unpack, I think if… if the spec does not tell us... <Zakim> JoeAndrieu, you wanted to say my PR says exactly what to do with a DID URL Stephen Curran: Using client, I just don't think I've had. That's it Otto Mora: Sure... Joe Andrieu: Yeah, so my PR does, in fact, explain exactly how the client of resolution prepares... <swcurran> Agree on the fragment Joe Andrieu: And it also must be choosing the singleton resource if there is a possible plethora. Based on content of the document Otto Mora: I will... Will Abramson: Yeah, to say, I think I agree with what Joe just said. In his... Stephen Curran: Um… sorry, I'll keep plus, but anyway, um... Otto Mora: Yep... Stephen Curran: Um... Otto Mora: Marcus?... Stephen Curran: That's it... Markus Sabadello: Um, I agree with Joe that, uh... <Zakim> JoeAndrieu, you wanted to say clarify the spec defines a client today Otto Mora: Uh, yeah... Joe Andrieu: Um, yeah, I… I agree that as the spec currently reads, Marcus, the dereferencer is acting as a client to the resolver... Otto Mora: Uh, Steven... Stephen Curran: Sorry. This specification… I'm reading the current test in the introduction. This specification defines a standard interface that clients can use to execute did resolution. And did URL dereferencing request... Otto Mora: Mm-hmm. Well... Will Abramson: Yeah, maybe Joe will speak to this better, but my understanding is what Joe is saying is that's. Wrong, because the client... Otto Mora: Mm-hmm... Will Abramson: So, like, it is inside the dereferencing process, whether we like it or not... <swcurran> Fragment is the one special case. Will Abramson: So, isn't it better to actually draw the boundaries a little different, I think? That's my understanding, what just replaced <Zakim> JoeAndrieu, you wanted to say my PR changes that opening line <swcurran> But that is the only one Otto Mora: That it still has a role in the… at least the fra- yeah, it could, yeah. Uh, so... Joe Andrieu: Um, yeah, that's… that's exactly right. I mean, the… the... <swcurran> A web browser is the client Joe Andrieu: Um, what it does is it uses the specifications and the protocols out there to execute algorithms that go out into the world and bring resources back into the current context Otto Mora: Steven?... Stephen Curran: Again, I failed to understand. To me, the web browser is the client... Otto Mora: Oh, well... Will Abramson: No, sorry, I was on the queue, I just... Stephen Curran: I don't think so, I think it calls… It calls... <Zakim> JoeAndrieu, you wanted to say that singular result is the DID document from resolution. if the client needs to verify a proof, that's not well handled by returning a subset resource Otto Mora: Okay, Joe?... Joe Andrieu: Um, yeah, I agree with the framing at the top level that you had, Steven, that when you get a data URL, you should be able to call a function that... Stephen Curran: And up. Okay... Joe Andrieu: like, it's really just a category error. Um, but I want to try, and… hold on, Steven, I wanted to try and turn our attention to, I think, really a bigger problem... Otto Mora: Uh, yeah, and we want to move to the What WG. There's an open issue for that, but… Yeah. Go ahead, Steven... Stephen Curran: Um, two things. 100% agreement that I don't expect a client to call. Uh, did URL... <JoeAndrieu> the interface is the problem. the algorithm is what is important, not what is passed or returned Stephen Curran: the, uh… the relative ref query parameter is problematic. Um, I Otto Mora: Joe... Joe Andrieu: Um… I think that was an old queue, but um... <swcurran> What should we use? Joe Andrieu: The fact that whatever is put in the service endpoint Stephen Curran: Are you talking… sorry, Joe, are you talking about the relative ref query parameter?... Joe Andrieu: The use of the… specifically, the 3986 reference resolution algorithm... Stephen Curran: Okay... Joe Andrieu: Yeah, what it does do a good job is the… and you can knock me off the queue, um... Stephen Curran: Hmm... Joe Andrieu: is sort of deconstructing the path and reconstructing the path in a good way. It deals with, like, dot parts, you know, if you have a dot in your path, you collapse it, etc... Stephen Curran: Okay... Joe Andrieu: Um, but it is… the edge cases that it deals with are for this website use case... Stephen Curran: Yeah... Otto Mora: Mm-hmm. So, okay, so just to close, I'm not sure if this, uh, particular, uh... <ottomorac> w3c/did-resolution#275 Otto Mora: Uh, issue of the 3986 should be part of this other issue, the 275. Um… yeah <swcurran> So how do we say what we really mean? Otto Mora: Or maybe we just open a separate one, Joe, if you want, but uh… maybe Joe Andrieu: H... Otto Mora: And, um, yeah, we can continue the discussion tomorrow. Sorry, go ahead... <swcurran> If we can't use Section 5 as a "short cut" Joe Andrieu: Yeah, just… just a comment real quickly, Otto. I'm pretty certain that the WhatWG is gonna be the same, because the functionality... Otto Mora: Okay... Joe Andrieu: Thanks, Otto... Otto Mora: Thank you... <ottomorac> transcriber-bot, pause |
…ath URL Signed-off-by: Stephen Curran <[email protected]>
Signed-off-by: Stephen Curran <[email protected]>
|
Four updates to the PR:
On the last, I think this is a first cut and happy to get feedback on both placement in the spec and wording. |
I think in the various recent discussions, we have provided several concrete examples of DID URLs with path that are dereferencing in a DID method specific way, so I'm a bit surprised that you haven't heard of any specific examples? One example is: -1 to characterizing DID URLs like this as an "unfortunate legacy" or a "hack". |
I agree, and I'd go even further to say that the DID URL being the only URL for a resource should be the default mental model. I'm a bit worried by discussions that over-emphasize DID URLs which return other URLs when dereferenced. Yes this is possible, e.g. when using the "service" DID parameter or the proposed "PathService". But DID URLs which can be dereferenced directly to a resource without any (HTTPS-based or otherwise) indirection should be the primary assumption.
Yes, I also think that the "fallback" language is problematic. This would be a bit like saying that an HTTPS URL should usually redirect to some other URL, and that returning a resource directly would be a "fallback". |
| <h3>`PathService` Service Type</h3> | ||
|
|
||
| <p>`PathService` is a `type` of `service` object used to generate a | ||
| URL for a resource from a DID URL path. Its `pathAlgorithm` attribute |
There was a problem hiding this comment.
Note that in the DID Core spec, this is called a "DID Path", not a "DID URL Path", see https://www.w3.org/TR/did-1.1/#dfn-did-paths
| </li> | ||
| <ol class="algorithm"> | ||
| <li> | ||
| Collect a list of all of the objects from the |
There was a problem hiding this comment.
Really all objects?! Including verification methods and any extensions?
| <li><b>content</b>: <code>null</code></li> | ||
| <li><b>dereferencingMetadata</b>: <var>error | ||
| object</var> with type set to <a | ||
| ref="#INVALID_DID_URL">INVALID_DID_URL</a></li> |
There was a problem hiding this comment.
Should probably be REPRESENTATION_NOT_SUPPORTED rather than INVALID_DID_URL
| </li> | ||
| <li><b>dereferencingMetadata</b>: <var>error | ||
| object</var> with type | ||
| set to <a ref="#INVALID_DID_URL">INVALID_DID_URL</a></li> |
There was a problem hiding this comment.
Shouldn't be INVALID_DID_URL (this is for invalid syntax of the DID URL).
| <ol> | ||
| <li> | ||
| For each object, retrieve the value of the path attribute | ||
| designated by the object's <code>type</code> (e.g., |
There was a problem hiding this comment.
Why would this be designated by the type? Why not always use a fixed property such as "basePath" across all types?
Also, I think the section on "PathService" doesn't actually designate such a path attribute. Readers will likely assume that it's "basePath", but it's not explicitly stated in "PathService" that "basePath" is the path attribute mentioned in this section here.
Replaces PR #260 with the same content applied to the current version of the specification. Attempting to resolve the conflicts failed miserably on #260. Happily, recreating the PR was not that hard. That said, there were some comments on that PR that are still applicable.
The new PR is identical to the one last discussed at the DID Working Group -- 2026.03.26.
The PR changes 4 things in the specification:
relativeRefquery parameter and how it applies.PathServiceserviceand/orserviceTypeand/orrelativeRefto also include "and/or DID URL Path", and describes how that all works.serviceobjects may be removed andserviceEndpointsaltered) may be removed in CR, as people don't seem to like that concept.Phewww....
Signed-off-by: Stephen Curran [email protected]
Preview | Diff