14:05:24 RRSAgent has joined #did 14:05:29 logging to https://www.w3.org/2026/04/15-did-irc 14:05:29 rrsagent, make logs public 14:05:32 rrsagent, draft minutes 14:05:33 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html manu 14:05:41 Meeting: DID Resolution Special Topic Call 14:05:54 Present: Manu, Will, Joe, Stephen, Dmitri, Ted 14:05:54 https://docs.google.com/document/d/1xcoslzqA6Wr_CHhvvhZ4wKupEE32HZ69hp2AE1rJMjs/edit?tab=t.0 14:06:00 rrsagent, draft minutes 14:06:01 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html manu 14:06:08 transcriber-bot, resume 14:06:08 scribe+ 14:06:16 Wip: We went through document last week, we want to reground. Where do we have consensus? 14:06:48 Wip: There are two main points we need to discuss -- Markus has thoughts on two major points. 14:06:49 present+ 14:07:01 Wip: First one -- do we pass in full DID URL to resolution, or a DID? 14:07:03 previous meeting: https://www.w3.org/2026/04/09-did-minutes.html 14:07:05 next meeting: https://www.w3.org/2026/04/16-did-minutes.html 14:07:20 Wip: For Dereferencing function, there are PRs up, focus on conversation on getting PRs through. 14:07:35 q+ 14:07:39 ack manu 14:07:41 Wip: any other things to discuss? 14:08:28 i/We went through document last week/agenda: https://www.w3.org/events/meetings/fc72b076-8389-4fd8-b223-a985590d3f33/20260415T100000/ 14:08:53 manu: Jeffrey Yasskin from TAG said that Markus addressed his issue in a PR Markus raised, when do we chat about that? 14:08:59 Wip: Tomorrow, it's schedule for tomorrow. 14:09:11 Wip: I don't believe, based on Jeffrey's comments, he's reviewed dereferencing. 14:09:32 q+ 14:09:35 ack JoeAndrieu 14:10:10 JoeAndrieu: I know Jeffrey approved changes, but reading his last comment, he's still suggesting maybe possible direction is to state RFC3986 isn't useful. I don't think we've cleared up his confusion. 14:10:30 Wip: If he does review DID URL dereferencing, some of this might surface again. 14:10:42 Wip: Useful to share screen? 14:10:57 Wip: I'll share my screen to look at document above. 14:11:30 Wip: 1 feels editorial and can be done at the end. Broad consensus minus Markus' concern -- we're pushing that. 14:11:33 q+ 14:12:32 manu: Can we mark these? 14:12:41 Wip: 1 is orange, Markus is slightly against 14:12:49 Wip: 2 is red, Markus is strongly opposed 14:13:18 Wip: 3 is green, we have a PR, we can move to resolution in PR 14:13:42 Wip: 4 is red, big change, PR exists, few different things bundled up in here. 14:13:58 Wip: 4a is red, remove HTTPS binding, PR exists. 14:14:41 q+ 14:14:43 Wip: 5 is orange, we might be able to get consensus on it separately. 14:14:46 ack JoeAndrieu 14:15:15 JoeAndrieu: Reason this is in 315, don't know how to separate in current algorithm, more complicated to separate it as a PR, but open to someone trying. 14:15:37 Wip: Maybe this can't be independent from function signature. 14:16:07 Wip: maybe 5 is tied up in 4. 14:16:24 s/ in 4/ in 4 and 8/ 14:17:30 Wip: 6 is red, tied up on HTTPS is involved for dereferencing. 14:17:50 dmitriz: There is potential confusion, two accept properties -- input options passed to dereferencer, other is HTTP Accept header. 14:17:57 rrsagent, draft minutes 14:17:59 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html manu 14:18:08 q+ 14:18:13 ack JoeAndrieu 14:18:41 JoeAndrieu: This is about both, also in the function, separate to 6 and 6a, could separate between HTTP headers and the function itself. 14:18:56 Wip: 7 is green, just updating the image. 14:19:55 Wip: 8 is orange, refactoring is a good idea and supported, but when we get into details it might become complicated. 14:20:27 Wip: 9 is green, add step that says a dereferencer must allow user to select resolver. 14:21:12 q+ 14:21:35 JoeAndrieu: we could do this separately, say if client or dereferencer does it. 14:21:41 Wip: This is a change everyone is for, though. 14:21:46 ack swcurran 14:23:05 swcurran: Wondering if we can have conversation around why there would be two algorithms called when it's only one. The algorithm is DID URL dereferencing, that's all we do. You pass in a DID URL, naked DID or parameters, could have version time, and a result comes back. Can we have conversation on whether we should talk about two different things and two different calls? Ignoring the fragment, which is handled by thing calling, everything else is handled 14:23:05 by nebulous, logical thing called DID URL dereferencer. F 14:23:21 swcurran: First step is to get DID Document, separation makes so many of these conversations difficult. 14:23:41 Wip: We should have that conversation, let's keep going through this document. 14:23:51 q+ 14:23:56 ack manu 14:24:25 q+ 14:24:33 ack manu 14:25:01 q+ 14:25:26 manu: I think 10 is orange, we can make it backwards compatible. 14:25:35 ack JoeAndrieu 14:26:04 JoeAndrieu: I think we can change it because it's a security issue -- still think this should be red. Either Markus' -1 are red, or we argue and we override. 14:26:18 Wip: 10 is red for now, we'll have to discuss. 14:27:25 Wip: 11 is red because Markus is -1'ing it as the thing sent to the resolver. 14:28:17 Wip: 12 is orange, might be difficult conversation, but general consensus to clarify this. 14:28:46 q+ 14:28:47 Wip: 13 is green, general consensus on retrieval strategy. 14:28:53 ack JoeAndrieu 14:29:17 JoeAndrieu: 13 is dependent on 12 and dependent on algorithm, which is 8. 14:29:24 JoeAndrieu: Current algorithm doesn't pick strategy to execute. 14:29:41 Wip: 14 is orange, where is the boundary for the algorithm? 14:30:06 Wip: My instinct is to pick hard topic first, if we can decide on 2, it'll help turn some of the orange items to green as well. 14:30:23 q+ 14:30:27 ack manu 14:30:59 present- Ted 14:30:59 present+ 14:31:08 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html TallTed 14:31:38 manu: There is an issue when the strongest opposing voice on many of these isn't here... those that are here are largely onboard. 14:31:48 Wip: Is there an HTTPs binding to dereferencing? 14:31:56 q+ 14:32:03 q+ to bring in Stephen's comment 14:32:09 ack manu 14:32:10 Wip: We could have no HTTPS binding, but still ahve function signature. 14:32:15 q+ 14:32:15 Zakim has joined #did 14:33:08 q- 14:33:48 present+ TallTed, manu, JoeAndrieu, swcurran, Wip, dmitriz 14:34:59 q+ 14:36:13 manu: Digital Bazaar feels very strongly that the specification should not have an HTTPs Binding for dereferencing. We have never had consensus on this in the group. We believe it is an attack vector, people can request massive files via dereferencing, or send the system on a variety of loops dereferencing, and we don't think that is appropriate for a specification of this type. We will not formally object to the feature, but we certainly will not 14:36:13 implement it and we will speak strongly against anyone that does. 14:36:31 https://docs.google.com/document/d/1xcoslzqA6Wr_CHhvvhZ4wKupEE32HZ69hp2AE1rJMjs/edit?tab=t.0 14:36:32 markus_sabadello has joined #did 14:36:35 s/implement it and/... implement it and/ 14:36:37 present+ 14:36:47 https://docs.google.com/document/d/1xcoslzqA6Wr_CHhvvhZ4wKupEE32HZ69hp2AE1rJMjs/edit?tab=t.0 14:36:48 ack JoeAndrieu 14:38:41 JoeAndrieu: I copied text to 4a that should be on 4, which is heart of concern -- if I have a DID URL, I need to resolve it, and describing algorithm should work without needing another 3rd party function. Going from URL to use it in my application, shouldn't have to implement dereferencer function, you don't need this function, you can execute algorithm -- when derefrencing in browser, they might do a lot of things to dereference, I want to echo 14:38:41 Stephen's frustration that there aren't two things we're describing here. We differ on what we define those things, we have to define resolve (that is the point of interop), so anyone can resolve through HTTP interface. 14:39:26 q? 14:39:27 JoeAndrieu: we're defining how someone who has a DID URL, preprocesses it, handles response, we should get rid of function because it has us have an additional limitation on inputs/outputs and I cannot change it, I wouldn't implement it, I would object if we don't define the algorithm in such a way that it's independent of software called a dereferencer. 14:39:29 ack swcurran 14:39:37 scribe+ 14:39:45 swcurran: Manu, your comment about removign HTTPS binding son dereferencer, same for resolver? 14:39:58 swcurran: or is that the same thing? 14:39:59 q+ 14:40:00 scribe+ 14:40:02 ack manu 14:40:11 q+ 14:41:30 manu: the thing that we are opposed to is retrieving any arbitrary resource using an HTTPs endpoint. The only return value that we want to implement for an http binding is the one that return the DID document. 14:41:55 ack markus_sabadello 14:41:59 manu: The thing we are opposed to is retrieving an arbitrary resource using an HTTP endpoint. We are OK with getting the DIDDoc so that you can do the dereferencing yourself, but you have do the dereferencing is some arbitrary resource. The client can do the dereferencing, following the spec, but our code won't do that. Return the DIDDoc and 14:41:59 something else gets the resources. 14:41:59 manu: we would rather have an alg where the return value is a did document and then you can take it from there 14:42:20 Back to you manu 14:43:22 markus_sabadello: As I've said in some of the issues, I'm against changing the language we've had for a long time. We are resolving DIDs and dereferencing DID URLs, important to think this. Resolving DID URLs, dereferencing DIDs, think it would break a lot of things if we break the clear separation we've had. Some of the proposals in that direction are based on misunderstanding of specification and how it works. versionId and versionTime are resolution 14:43:22 options passed to a DID Resolver, doesn't mean we're resolving DID URLs. 14:43:53 Wip: We're focused on the HTTPS Binding right now, are you going to formally object if we remove the HTTPS Binding. 14:44:01 q+ 14:45:17 markus_sabadello: Yes, I'd object, we have some some use cases that need HTTPS Binding, but it's important for some use cases to have it. What Joe wants is also supported by the specification. Because we define a function w/ inputs/outputs, it doesn't prevent anyone from derefrencing client side. 14:45:17 q+ 14:45:18 ack manu 14:45:26 scribe+ 14:46:02 manu: I guess one thing on the feature and formal objection. In order to have the FO , the burden of proof is that the feature should have consensus by the group. 14:46:24 q+ bigbluehat 14:46:28 q+ 14:46:40 manu: if we go this route then it will just result in a delay. 14:48:10 manu: on the point regarding implementation of https binding being optional, this is actually a security issue. From DB's position this will be dangerous. I know this has been in the spec for a long time, but I feel people have not really been reading this deeply and following it. 14:48:20 ack JoeAndrieu 14:48:21 manu: Respond to formal objection idea. If you FO you have the burden to show there is concensus that the feature is in the spec. The claim is there is not a concensus so it will be unlikely to proven. This is a high chance as a security risk, and we strongly think it is a bad idea. We should not help them do something that dangerous. Pushing 14:48:21 back hard that this had concensus. It's been in the spec, but people have not been thinking. Just the HTTPS binding. We don't want a client to insist we do this. We don't want it in the spec. 14:49:16 JoeAndrieu: Speaking to Marku's comment about not needing to implement dereferencer. It's inseparable from the current algorithm, that doesn't depend on this function (that I think is a bad function). If we formally define what client does more appropriately, it's a huge shift to clear this up. If we can't define how a client calls a dereferencer and how to use it, that's a big problem. 14:49:16 JoeAndrieu: I think the challenge is that we need to formally define how the client should behave here. How does a client call a resolver once it has a DID url. 14:49:21 ack bigbluehat 14:49:42 ack markus_sabadello 14:49:44 bigbluehat: Is this a SHOULD vs. MUST or a MAY? Even with SHOULD/MAY, there are concerns that Manu/Joe both spoke to. 14:49:59 markus_sabadello: I don't understand what the problem is with the function -- function has inputs and outputs 14:50:00 q+ 14:50:03 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html TallTed 14:50:13 q+ to say algorithms don't need return values 14:52:00 markus_sabadello: There is an algorithm that is executed, it is an algorithm, it can be executed on client-side, it's what Joe is describing -- don't understand what the problem is with it. No one is saying you can implement it yourself, no one is saying you need a remote endpoint, algorithm has inputs/outputs -- also how dereferencing HTTPS URLs works, you have to mention browser as analogy, exactly like that. You have an HTTPS URL you dereference it, 14:52:00 there are inputs/outputs, same thing. DID URL representation of resource together with metadata, has inputs and outputs, more client-side than HTTPS URLs, implement entire derefrencing function entirely on client-side, including DID Resolution -- for example did:key or did:jwk, all resolution, all derefrencing can happen on client-side. What's the problem with expressing as a logical function. 14:52:20 ack manu 14:52:41 Wip: We're migrating a bit into logical function discussion. I'm hearing strong support for removing, and also hearing Markus is opposed. 14:52:43 scribe+ 14:53:04 q- 14:53:25 q+ 14:53:35 ack markus_sabadello 14:53:41 manu: Markus, my comments are not about the logical function. I'm only speaking to the binding. We're bouncing between the two. Let's stick to the HTTPS binding. There are thing that you said that I agree, with but we're not talking about that. 14:54:19 i/make logs public/scribe+ manu 14:54:30 Here are the use cases - https://github.com/w3c/did-resolution/issues/306#issuecomment-4101276200 14:54:45 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html TallTed 14:55:29 s/by nebulous, logical thing/... by nebulous, logical thing 14:55:30 markus_sabadello: Ok, so regarding HTTPS binding for dereferencing, shared two use cases in comments, one is DID Linked Resources, if you have DID URL that references a DID Linked Resource, the result of dereferencing is an image and value of HTTPS binding is you can put it in browser, you can have HTTPS URL which uses binding for DID URL dereferencing to return representation of resource over HTTPS binding. Redirect a service endpoint URL, where you can 14:55:30 construct HTTPS URL that includes DID URL that result is redirect, useful for a number of reasons. Persistent identifier, URL backed by DIDs, these things would be unspecified if we remove the binding. 14:55:55 s/Stephen's frustration that there aren't/... Stephen's frustration that there aren't 14:55:55 q+ 14:56:04 ack dmitriz 14:56:04 markus_sabadello: I can understand that we can remove it and people can implement it. Valuable feature in deployments, for that reason, we should keep it and emphasize that dereferencing on client-side is preferred, and point out security considerations, but I don't think we should remove it. 14:56:07 s/options passed to a DID Resolver, doesn't/... options passed to a DID Resolver, doesn't 14:56:27 dmitriz: What if we lean into optional nature of it, standalone spec? Not in core DID Resolution spec? 14:56:28 s/back hard that this had concensus/... back hard that this had consensus 14:56:39 s/there are inputs/outputs, same thing/... there are inputs/outputs, same thing 14:56:47 You mean like did-extension style Dimitri? 14:56:52 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html TallTed 14:57:18 markus_sabadello: I have to think about it, very parallel to binding for DID Resolution, would make it more complicated if we put it in another spec. Helps interop -- good reasons we want HTTPS binding for Resolution, same applies for Dereferencing. 14:57:26 @ottomorac - yeah 14:57:47 Wip: We need to make decisions that some aren't going to like and move forward. Can more conversation help move this forward? Or do we need to make a decision about the feature? 14:57:51 q+ 14:57:55 ack manu 14:57:58 s/construct HTTPS URL that includes DID URL that result is redirect/... construct HTTPS URL that includes DID URL that result is redirect 14:59:08 q+ 14:59:27 s| outputs, same thing/... there are inputs/outputs, same thing/outputs, same thing| ... there are inputs/outputs, same thing 14:59:36 q- 14:59:37 manu: We need to continue the conversations so that we can get to an educated position on what they want to see going forward. 14:59:50 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html TallTed 15:00:01 markus_sabadello: Agree to having more calls about this. 15:00:35 rrsagent, draft minutes 15:00:36 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html manu 15:01:00 present+ bigbluehat 15:01:09 I have made the request to generate https://www.w3.org/2026/04/15-did-minutes.html TallTed 15:42:31 bigbluehat has joined #did 16:01:36 TallTed has joined #did 17:23:32 Zakim has left #did 18:23:48 transcriber-bot, pause 18:23:48 scribe- 19:20:56 rrsagent, please excuse us 19:20:56 I see no action items