14:02:28 RRSAgent has joined #did 14:02:32 logging to https://www.w3.org/2026/04/22-did-irc 14:02:32 Zakim has joined #did 14:02:32 ottomorac has changed the topic to: DID WG Agenda https://lists.w3.org/Archives/Public/public-did-wg/2026Apr/0023.html 14:02:49 WIp has joined #did 14:02:54 meeting: DID WG Special Topic Call 14:02:57 rrsagent, make logs public 14:03:09 Chair: ottomorac 14:03:21 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Apr/0023.html 14:03:22 clear agenda 14:03:22 agenda+ Will Abramson 14:03:22 agenda+ Pierre-Antoine Champin 14:03:22 agenda+ Otto Mora 14:03:22 agenda+ [Decentralized Identifier Working Group](https://www.w3.org/groups/wg/did/) ([View Calendar](https://www.w3.org/groups/wg/did/calendar/)) 14:03:39 previous meeting: https://www.w3.org/2026/04/16-did-minutes.html 14:03:49 next meeting: https://www.w3.org/2026/04/23-did-minutes.html 14:05:07 I have made the request to generate https://www.w3.org/2026/04/22-did-minutes.html TallTed 14:05:48 present+ TallTed, pchampin, ottomorac, JoeAndrieu, WIp 14:08:27 Topic: General discussion 14:08:55 transcriber-bot, resume 14:08:55 scribe+ 14:09:00 Otto Mora: I'll… I'll stop it... 14:09:08 ... Yeah, can somebody recap me on the latest on the side chat that there was there? 14:09:13 ... I honestly haven't had a chance… I think maybe Will and Pierre, you had a chance to 14:09:18 ... Just a little bit of a conversation there between Marcus and Joe, and 14:09:29 ... Manu and the others on that group 14:09:30 Joe Andrieu: Yeah, I think TalTed's the only one who's not in that thread. Oh, no, maybe PA isn't either... 14:09:31 Will Abramson: Okay, yes... 14:09:38 Joe Andrieu: OPA, yes... 14:09:43 ... But yeah, it'd be good to brief, tell Ted. I think, Will, your summary at the end was, um, a reasonable attempt. If you want to just review that 14:09:49 Will Abramson: Uh… yeah. Sure, yeah, I mean... 14:09:55 ... So this is just a discussion to try and move us forward on all of these many things that we have 14:10:00 ... focused on at the moment, but in particular, the recent discussion has been focused on 14:10:04 ... did URL dereferencing, and 14:10:10 ... You know, starting off with HTTPS binding, but then moving up to 14:10:26 ... I think there's 3 tiers for diguera LD referencing, currently. I think the top tier is, like, okay, do we want to define an algorithm for diguera LD referencing? My sense from the group is we all agree we want that. Definitely, right? Um 14:10:34 ... maybe I'm wrong there, but I don't think anyone's… you know, like, maybe there's some work to do to define the algorithm differently 14:10:41 ... We all realize we need to define an algorithm for how dereferencing happens. The second tier is, like, around this, um 14:10:48 ... Abstract function definition that is in respect today, which defines 14:10:54 ... Like, logical inputs and outputs that a implementer has to implement, and 14:10:59 ... jurisdiction is this should be removed. Marx is strongly against that. I think 14:11:04 ... the… the bit that I got from the conversation in the group is that 14:11:07 ... The… while the abstract 14:11:14 ... Function is supposed to be abstract and, like, not prescriptive of how an implementer should implement 14:11:18 ... did your LD referencing. Currently, in the spec today, it 14:11:29 ... it doesn't read like that, right? It reads like, as an implementer, you should implement this function signature, and it should take these inputs. And it should return these outputs 14:11:41 ... So that's where a lot of the discussion has been going on, it seemed to me. Uh, and then the, like, top bit is, like, okay, do we want to define HTTPS binding to this. function signature. Um 14:11:47 ... But I think the discussion really has revolved around number 2 and, like, this abstract function 14:11:53 ... Um, oh, and then another piece that is confusing people in the spec today is around 14:12:02 ... this concept of a dereference. Like, the spec today talks about this conference. This concept of a dereference there 14:12:11 ... Almost as if it's, like, a separate component, or at least a logical thing that implements dereferencing, like the dereferenced, the 14:12:17 ... It's the thing that implements a dereferencing algorithm, and would, you know, implement this function signature 14:12:23 ... But the confusion there is, I think, about where we're drawing these boundaries, because the dereferencer 14:12:32 ... actually only implement the dereferencing algorithm that currently in the specs today is defined as dereferencing the resource. There is, like, a secondary step 14:12:40 ... That is about handling the fragment that is actually performed by the client 14:12:47 ... And I think the argument is, like, maybe we should just get rid of derefencer and say dereferencing is something performed by the client 14:12:51 ... You know, they first get the results, and then they do the fragment handling 14:12:57 ... Um… and then the other conversation is around, like, okay, do we want, um 14:13:09 ... the, you know, if we are defining this abstract function, like, currently it's dereferenced, it takes in a bid URL and some options, and returns. These three things, like, is that, like 14:13:12 ... Can we still have that in the spec without 14:13:17 ... Like, with some language that says you don't have to implement it like this, is it just 14:13:23 ... uh, like, abstract, or, like, indicating this is one way you might influence it. I don't know, I think 14:13:28 ... That's where Joe's coming from, he's like, I'm not going to implement that abstract function, and I shouldn't 14:13:35 ... I have to… you know, if I don't implement that abstract function, I can still implement the referencing, and that should be conform 14:13:40 ... But, I don't know if I captured our CPA. Yeah, please 14:13:51 Pierre-Antoine Champin: Yes, uh, I'm… I'm currently walking in the street, I hope there's not too much noise, sorry for that... 14:13:59 ... And also, I'm not on IRC. Um, yeah, I think that's a good summary. Um 14:14:05 ... I've re-read all the algorithms, just to get them fresh in my head 14:14:08 ... And one thing that's 14:14:15 ... What bothers me a bit is this idea that. Uh, uh 14:14:23 ... The referencing happen… happens once you resolved the document 14:14:30 ... Is that really always the case, uh, when it comes to the past parameters in the div? 14:14:37 ... I read the current algorithm as saying, well, the fast parameter, it really depends on the method, and uh 14:14:44 ... So… is everything in dereferencing happening 14:14:51 ... Once you get the lead document, or… is it more flexible than that? 14:14:55 q+ 14:14:59 Will Abramson: Um… I guess I can double queue... 14:15:01 ack Wip 14:15:02 Otto Mora: Yeah, go, go ahead. Yep... 14:15:09 Will Abramson: Yeah, I mean, my understanding is that is part of the disagreement or confusion that's going on. Certainly, I've heard Marcus say that... 14:15:16 ... You know, like, some path handling has to be done by… like, is method-specific in some way 14:15:24 ... Um, but I did look into, did you, like, did… did, um… It linked resource back 14:15:29 ... And for me, like, there is two bits, right? There is some method-specific way 14:15:42 ... that is part of Resolve that then hydrates or populates, you know, both the… like, it resolves a DID document, and also, in did link resources, it will, like, populate some information 14:15:46 q+ to say retrieval happens after Resolution, but dereferencing is what you do with the DID URL. It's the outer algorithm. 14:15:48 ... in the did document metadata. And that's all returned as a… as a result, right? Like, the did 14:16:00 ... resolution result object contains all that information, and then dereferencing is a step that happens, and it… in DidLink Resort's case, like, it was looking in the. Um 14:16:06 ... In this metadata, and identifying the, um 14:16:15 ... like, I guess it's not quite the result, it's like the thing that references the resource, and then it's doing a step which retrieves that resource 14:16:30 ... And yes, that retrieval step might require, you know, method-specific stuff, but it's not really method-specific, it's verifiable data registry for specific stuff. Like, wherever that resource is, you have to find it, and 14:16:39 ... and return it. But I don't think… I think that's conflating things to say it's method-specific, specifically because in this… in the did link resources spec, it says 14:16:48 ... I can have a did document, and I can put in a linked resource, you know, if I control the did document metadata for my DID document 14:16:56 ... Like, I can put in that metadata a linked resource to a resource on any verifiable data registry, right? Like, I could put one 14:17:03 ... you know, I could have a did web, and I could put a linked resource or something on did check, so that's totally allowed. But then, uh 14:17:10 ... like, it's not method-specific, I've just used the checked blockchain to store a resource. Um 14:17:18 ... So I think the argument is, like, we should be saying dereference is something that happens once you get the did resolution result 14:17:28 ... like, you get this result, and then you perform the referencing on the results. You might have to do some additional steps, but it's independent of. I did not. I think 14:17:35 ack Joe 14:17:35 JoeAndrieu, you wanted to say retrieval happens after Resolution, but dereferencing is what you do with the DID URL. It's the outer algorithm. 14:17:38 Otto Mora: Mm-hmm. Okay, then I think then, Joe... 14:17:46 Joe Andrieu: Um, yeah, I actually think that's quite wrong. Like, I think, um, the… You do retrieval... 14:17:55 ... after you get the did document, which may mean… include determining that the did document is the resource, so there's no more retrieval that happens 14:18:02 ... Um, but dereferencing is what you do to the did URL because you have a did URL, and you were trying to use it in your application 14:18:11 ... So, dereferencing of that pointer means to take that reference and bring it into the current context, and that is sort of the outer algorithm 14:18:22 ... Which… within which we call resolution, and then based on the results of resolution, which is hopefully a did document or a failure, but assuming you get a good did document. Then you process that did document 14:18:27 ... to figure out how to retrieve the resource. And then your application says, hey, I've got this 14:18:34 ... data that I have, um, how do I apply it? And that's using the results 14:18:37 ... After retrieval. Um 14:18:43 ... So, hopefully… well, I see your hands up here, I'll let you go. I have some more points to make, but let's continue this thread 14:18:46 Otto Mora: Mm-hmm. Yep. Uh, Pierre... 14:18:49 Pierre-Antoine Champin: Yep... 14:18:58 ... My understanding of why we have this specification in the first place. is to 14:19:07 ... Uh, respond to the formal objections about interoperability and the variety introduced by these methods 14:19:14 ... By proposing a unified interface that hides this variability. Uh, so 14:19:22 ... In order for it to be… to respond adequately to this problem 14:19:27 ... I think that everything that is method-specific should actually happen behind the 14:19:31 ... Did resolution, uh, signature 14:19:40 ... And then the rest, you should be able to do that. I agree that you should be able to do that. Uh, on the client side 14:19:46 ... That doesn't mean that the spec doesn't have… cannot tell you how to do that 14:19:50 ... And again, all the algorithms that are provided, in my opinion, are 14:20:01 ... just specifying the result. I didn't see that in this spec, but in other specs, I saw 14:20:08 ... When there's an algorithm, the spec says, you can implement it otherwise as long as your results are the same algorithm 14:20:15 ... I think that's the same way to look at it, and to understand that neither the algorithm nor the 14:20:20 ... Interface defined by the function signature are mandatory 14:20:25 q+ to +1 hide the variability in the resolution 14:20:28 ... But for me, the compact should be, we provide an interface, a unified interface 14:20:37 ... to whatever is method specific. And… and then we may provide some algorithm to. For the next step 14:20:41 ... But, uh, it needs to be separate, and I, uh 14:20:46 ... I agree that it doesn't need to be in a specific component 14:20:53 ... But again, apart from those sentences that you pointed out to Joe, and that Marcus agreed 14:21:03 ... Uh, that they should be removed, or the thing about should not alter the signature. I think we all agree that this part is misleading and should not be there, so 14:21:08 ... I do believe that the intent is not to force anyone to, uh 14:21:11 ack JoeAndrieu 14:21:13 JoeAndrieu, you wanted to +1 hide the variability in the resolution 14:21:13 ... Isolates those algorithms in a specific component 14:21:29 Joe Andrieu: Uh, yeah, plus one that the… all the variability should be in the VDR, um, and hence resolved by the resolver. Um, I think that is the… how we've architected our architecture... 14:21:34 ... Um, we… we have, for reasons that may not be meritorious, um 14:21:42 ... Uh, accepted that there are likely did methods out there that have customizations, or using properties 14:21:52 ... Um, that could affect the path, um, because we allowed that in our, uh, did method registry, and we have not figured out how to unify all that. Um… so 14:21:59 ... Uh… that's why we, in the… in my algorithm, I made it clear 14:22:04 ... If, after you've exhausted all the other possibilities, you need to check to see 14:22:22 ... If someone has defined a did method-specific something, hopefully it's a property-specific something, like did linked resources, or linked resources, or path service, because those are, by inspection, you can tell from the did document that you have to do something special, and the client can know if they understand it or not. Um, but 14:22:32 ... I would love to get rid of the fallback to the DID method, but it's there because we expect there's some legacy entanglements. Um, but I would support getting rid of it 14:22:38 ... Um, I think, though, if you have a function that doesn't define its inputs and outputs, you have an algorithm 14:22:43 ... And that is what I've been arguing for, because I am not implementing the algorithm 14:22:48 ... Um, in any particular way whatsoever. I do not take those inputs 14:22:58 ... Um, and I do not return that kind of result. And so, we could define this new component that you don't have to implement 14:23:06 ... But then we also… and this is something I will object to, is we need the algorithm defined so it doesn't depend on that object 14:23:12 Section 7.2.3 14:23:12 "Specifically, when a DID URL with a DID fragment is dereferenced, then Dereferencing the Resource is done by the DID resolver, and Dereferencing the Fragment is done by the client." 14:23:12 And yet, the client is defined as 14:23:12 "Software and/or hardware that invokes a DID resolver" 14:23:16 ... And right now, we're conflating those two. So, one point of conflation, um, which I brought up on the signal chat we had going, I'll share with the group here. Um, in the spec today 14:23:26 ... In section 7.3, we have that when a did URL is dereferenced. The referencing is done by the resolver 14:23:31 ... However, the client is the software or hardware that invokes a DID Resolver 14:23:41 ... This is the kind of conflation that makes it very hard when we start talking about a dereferencer in the way the spec does. To even distinguish who is doing what 14:23:50 ... And I think this is the heart of the problem, is that throughout the spec, because we introduced this new term, it got used, and we have clients of the dereferencer 14:23:55 ... Um, but I think the right take is something that I believe 14:23:57 Markus 14:23:57 If you have a DID-enabled application which dereferences something -> you have a dereferencer :) 14:24:07 ... Marcus, Steven, and I are actually aligned on, even though it's very hard to find ways to talk about it. In the recent chat, Marcus had said, if you have a DID-enabled application which defines 14:24:12 ... which dereferences something, which is what I care about, it enabled application. Then you have a dereferencer 14:24:20 ... And what that tells me is that the client is the dereferencer, and any notion of a dereferencer that's not the client 14:24:21 q+ 14:24:27 ... Um, is not something that we have consensus on. Like, it is… it is a weird new component 14:24:34 q? 14:24:39 ... that the current algorithm depends on that I think this group didn't really understand. And one of the reasons we didn't understand it is none of the diagrams show that. We have an extensive section on resolution architectures 14:24:47 ... There is no dereferencer in there. The dereferencer is the client for a significant portion of the documentation, and occasionally, Marcus 14:24:56 ... asserts that, which I would agree with. But then, if the client is a dereferencer, where's the separation between the client and dereferencer? And I think that's where things break 14:25:00 function checkProof(didUrl, proof) { 14:25:00 let baseDid = removeFragement(didUrl); 14:25:00 let fragment = getFragment(didURL); 14:25:00 let didDoc = resolve(baseDid); 14:25:01 let key=getKey(didDoc,fragment); 14:25:01 let result = checkProof(proof, key); 14:25:01 return result; 14:25:02 } 14:25:03 ... Um, and just as an example, I'll give you a little bit of JavaScript that, in fact, dereferences, checks a proof 14:25:06 ... And never has the signature function 14:25:12 ... Of, um… that… that is defined in that system. Um 14:25:15 ... Okay, so that's… That's it 14:25:17 ack TallTed 14:25:18 Otto Mora: Mm-hmm. Uh huh... 14:25:21 ... Uh, it's 14:25:27 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Um, a suggestion which may help some in... 14:25:34 ... Keeping the architecture straighter in people's heads is to 14:25:40 ... Refer to a compound noun instead of a simple noun for both client and server 14:25:46 ... Uh, to say what the client is a client of. And what the server is a server of 14:25:49 ... Every time those two words are used 14:25:55 ... Uh, it has helped in a lot of other places where similar 14:26:00 ... blurring has taken place, so I'm suggesting it here 14:26:05 ... Um… I don't think I have strong feelings about 14:26:14 ... how this is built yet, but maybe that's just because I haven't heard the thing that I have strong feelings about yet. Um 14:26:17 q+ to agree and add its even simpler if we only have one client, the client of the resolver 14:26:25 ... But yeah, I just wanted to suggest a compound down. It's helped a lot elsewhere, maybe it can help some here 14:26:29 Will Abramson: Yeah, it's greatest handle... 14:26:29 Joe Andrieu: Um, yeah, I like that a lot... 14:26:34 Pierre-Antoine Champin: Yeah, uh… Yeah, sorry, sorry... 14:26:36 q? 14:26:37 Joe Andrieu: Sorry, I thought… I thought you just queued me up. Go ahead, Pierre. I didn't see that. Your hand... 14:26:42 Pierre-Antoine Champin: Uh, no, no, yeah, but, uh, plus one, uh, plus 1, so to, uh, maybe... 14:26:45 ... clarify things by having us compile nouns 14:26:49 ... I tend to agree with Joe that 14:26:53 s/compound down/compound noun/ 14:27:02 ... the spec is sometimes a bit, uh, unclear about, uh, what the client is the client of, and where exactly is the dereferencer. I think some clarification is, uh 14:27:09 ... is needed, and so, yeah, I like Ted's proposal. On that, um 14:27:11 q+ 14:27:16 ... And I think I had something else to add. Yeah, Joe, I'm unclear why 14:27:16 q? 14:27:25 ... why you insist on the distinction between algorithm and function. For me, the terms are almost synonyms 14:27:30 ... Uh, again, as long as we agree that it's an abstract function, it doesn't have to be a 14:27:39 ... function or a separate component in your specific programming language or other. In order to… in order to execute an algorithm 14:27:55 ... you need to know what your… what you start with, and you need to know what you expect at the end. For me, that's input and output in a very, very general notion, and so that's a signature. So you… I don't understand 14:28:03 ... Yeah, I think you said, uh, you can have an algorithm but not have a function signature, and I disagree on that 14:28:04 ack JoeAndrieu 14:28:04 JoeAndrieu, you wanted to agree and add its even simpler if we only have one client, the client of the resolver 14:28:12 Joe Andrieu: I'm sorry, you said on the last word, did you disagree about the algorithm without a function signature?... 14:28:24 Pierre-Antoine Champin: Yes, yes, I disagree with that, because for me, an algorithm without… without knowing what you start the algorithm with and what you're supposed to end it with... 14:28:32 ... Which is input and output, uh, that, that doesn't… for me, that doesn't add up, that an algorithm always have 14:28:40 Otto Mora: Go ahead, Joe... 14:28:45 Joe Andrieu: Um, yeah, not all… not all functions have returns, and the... 14:28:51 ... way that we are describing the function here, it defines both inputs and return outputs 14:29:00 ... Um, and while it's reasonable to say, hey, this algorithm depends on these inputs, which I believe my PR does 14:29:05 ... Um, requiring that I structure my output in any particular way is where I have a problem 14:29:10 ... Um, functions can easily simply change program state 14:29:18 ... There's, in fact, a whole college of software design that tries to ensure that every function does not change 14:29:23 ... external state, but just returns a value. Um, but the function I… I 14:29:29 ... put in chat, which I know you can't see, PA, um, you know, it does not return the resource 14:29:38 ... Um, nowhere in that loop is that dereferencing algorithm, uh, function, I'm sorry, the dereferencer function is not in that algorithm 14:29:44 q? 14:29:46 ... But I do dereference. Um, and so what I'm trying to get to is an algorithm that explains what the client, the one singular client, needs to do 14:29:58 ... Um, to call a resolver, and then process the result. And the way that they process it may or may not 14:30:00 ... Um, within their software architecture suggest that they return a result at the end of some specific function. Um 14:30:03 ... So, uh, that's it 14:30:06 ack Wip 14:30:07 Otto Mora: Okay... 14:30:10 ... Uh, Will? 14:30:14 Will Abramson: Uh, yeah, I think I agree... 14:30:27 ... Well, I was gonna say to… to Ted that I think if we… if we go down this route that we seem to be, at least on this call, moving towards. Then, the client 14:30:29 q+ 14:30:29 Joe Andrieu: Oh, yeah... 14:30:33 Will Abramson: is the client of the did resolver, right? Like, the client only calls the did resolver and executes a resolution request... 14:30:41 ... And gets back a bid resolution result. And the client. is always 14:30:45 ... executing dereferencing, right? Like, I mean, we could call it 14:30:50 ... the Resolver client, or something like that. That helps clarify things, but 14:30:55 ... I think part of the confusion is at the moment, the client sometimes is the client of the did resolver 14:31:01 ... and is executing a resolution request, sometimes the client is the client of a dereferencer 14:31:11 ... And dereferencing, and sometimes the deref… the DID resolver is executing the dereference. Some portion of geography. Um 14:31:20 ... Yeah, and then the other thing I was gonna say is just on this, like, I mean, I think Joe's example is quite a good one, like 14:31:24 q? 14:31:25 ... I think it's the return values of this function signature that are 14:31:37 ... um… you know, potentially problematic, because what does it… because, you know, those return values are return values of the dereferencing the resource operation, and I think they are 14:31:45 ... Partly legacy from the fact that we were imagining some other entity, some server, you know, doing that function for us 14:31:52 ... and then providing a result. Like, really, they're just a way of forwarding on that did resolution result 14:32:03 ... Is how I see it. Whereas if the client is doing dereferencing, then they're going to get the data resolution results. They'll have all that metadata. And then they can decide how they want to use it 14:32:06 ack JoeAndrieu 14:32:08 Otto Mora: Mm-hmm... 14:32:17 ... I'll let Joe go, just because he had his hand raised before you did, Pierre, but right after that, you'll go. Yeah, go ahead, Joe 14:32:27 Joe Andrieu: Uh, yeah, I forgot what I want to say to… in response to tell Ted. I do like the compound. If we are going to have clients mean multiple things, we will need compound... 14:32:35 ... Um, however, I think I'm in the camp Will just, uh, marked out, which is, I think what we're talking about is one client, a client that calls the resolver 14:32:40 ... And I think anything more than that is a complexity that is… is the source of the confusion 14:32:44 q+ 14:32:46 ... Hence, my attempt to clear that up with a rewrite. That's up 14:32:51 Otto Mora: Uh… Yes, uh, Pierre... 14:32:57 Pierre-Antoine Champin: Yeah, to, uh, to Joe's point about... 14:33:08 ... the return value, you don't necessarily want to return anything, I agree. I read the current text, and I'm sorry, Joe, I didn't review your PR in detail 14:33:14 ... Uh, so… that's why maybe what I'm saying is redundant, so… But, uh 14:33:17 ... The current text, the specs 14:33:33 ... tries to be quite generic about the output of the algorithm. Says, okay, there are those three things, and we do not tell you exactly how they are structured, so I don't read return here as constraining as you imply 14:33:37 ... The goal of the algorithm is to produce those things somehow 14:33:45 ... And maybe that's producing them in a way that modifies the state of the application, not necessarily returning them to an external component 14:33:54 q? 14:33:55 ... Uh, then, again, as soon as you define an algorithm 14:34:00 ... I would consider that you could decide to embed this algorithm in a separate function 14:34:04 ... Programmatic function, or component, or whatever 14:34:08 ... So, in that sense, I think it's 14:34:17 ... It still makes sense to talk about the dereference, as long as we are more clear about. When 14:34:23 q? 14:34:24 q+ to say, we don't need to create the metadata or process options 14:34:24 ... Again, whose client, whose clients we are talking about, I think this was said several times 14:34:28 ... Uh, yeah, that's… that's what I have 14:34:29 ack TallTed 14:34:31 Otto Mora: Okay, uh, Ted... 14:34:34 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Um... 14:34:49 ... So, for you, Joe, who see the quote-unquote client as always the client of the same. Service 14:34:49 ... You don't need the compound noun 14:34:51 Joe Andrieu: Yeah, agreed... 14:34:55 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): The purpose of the compound noun is for the folks who don't necessarily have that vision... 14:35:01 ... And maybe after a while, it will become clear that that is, in fact, the only 14:35:07 ... Client relationship that happens here. Or, maybe that will 14:35:14 ... Reveal that there is another client relationship. That gets described at some point 14:35:21 ... And that'll change your viewpoint. And either way, going with the compound. Makes things clearer for 14:35:26 ... Somebody, and I think that's a good direction to go 14:35:29 ... Um… on the 14:35:35 ... Function versus algorithm versus whatever else it might be called 14:35:42 q? 14:35:46 ... I think this is another one of those black box things where what we're trying to define is. some inputs 14:35:55 ... and some outputs. And maybe there are other outputs that mostly don't matter 14:35:58 ... Or only come up sometimes, and we don't have to define those. And maybe there are inputs that 14:36:05 ... Are extra and get ignored and so we don't have to talk about those either or maybe we want to reveal 14:36:10 ... That those things exist, and when they exist, this is the shape they should take 14:36:22 ... I don't know, I don't have strong feelings about that. I think that defining the algorithm is a useful way to say, this is one black box that you can use. And when you get these inputs 14:36:26 ... into it, then you'll get these outputs from it. And 14:36:35 ... Whether that's implemented as a library call, or a function call within an application, or 14:36:42 ... Rolling of the dice in the secret oracle chamber, um… That doesn't matter 14:36:48 https://w3c.github.io/did-resolution/#example-0 14:36:52 ack JoeAndrieu 14:36:52 JoeAndrieu, you wanted to say, we don't need to create the metadata or process options 14:36:53 ... We don't really care how you implement the algorithm, just long as when we put these inputs into it, we get those outputs from it. That's it 14:36:57 Otto Mora: Uh, Joe... 14:37:03 Joe Andrieu: Um, yes, I appreciate that framing, Talted, um, but I... 14:37:08 ... I… I think the problem is our inputs and outputs are very explicitly defined 14:37:14 ... Um, and I don't have that black box. The little JavaScript snippet that I shared 14:37:22 ... does not return a DID URLD referencing result. I dropped that link into the chat. It is a very complex result, and I do not 14:37:28 ... track did URLD referencing metadata, I don't track content metadata, I just use the result 14:37:35 ... Um, so my challenge is, even if we try to think it as a black box, the problem is those inputs and outputs are not something I need to implement 14:37:40 ... And that would make my application a non-conformant dereferencer 14:37:50 ... And that's… that's where I fall down. I think what we need to do is define how you dereference a did URL, which is what the client does to prepare for resolution 14:37:53 ... Call Resolve, and then process the answer 14:37:56 s/Talted/TallTed/g 14:38:00 ... Um, having it as a separate component just… it feels really awkward 14:38:03 q? 14:38:04 q+ 14:38:05 Otto Mora: Mm-hmm... 14:38:08 ack Wip 14:38:10 ... Well 14:38:18 Will Abramson: Yeah, I just wanted to say, like, I think, Joe, your example is good, but also it is, like... 14:38:26 ... it has already decided the path that the dereferencing should take, if you know what I mean. Like, it's… it's 14:38:30 ... Expecting a fragment that returns a key 14:38:38 q+ yes. that's the context in which I'm dereferencing the DID URL 14:38:42 q+ to say yes. that's the context in which I'm dereferencing the DID URL 14:38:42 ... And then can be used to check and prove. Whereas, I think the other side is, like, you are dereferencing. did URLs without really knowing. what those did URLs 14:38:48 ... reference, and what they do reference to, so there's lots of, like, logic that would 14:38:53 ... Be repeated as you try and figure out, like, what is… you know, when you're trying to get to the results 14:39:00 ... So… I think, sort of, the argument that Marcus, like, to put this algorithm 14:39:04 ... behind a function is that… that would be repeated, right? Like, I… I'm 14:39:11 ... Maybe going to call the dereference operation and get back some 14:39:17 ... Resolve, like, hide all the logic in the same place, it can be repeated, and then handle fragment 14:39:21 ... I think that's the argument that Marx is putting forward 14:39:32 ... uh… I guess in this case, you know, you are, like, probably imagining, like, this is a verification method, it has a proof on it, the proof has a verification method 14:39:37 ... which is a URL of a specific type, so I don't need all that stuff 14:39:44 Otto Mora: Mm-hmm... 14:39:44 q? 14:39:49 ack JoeAndrieu 14:39:49 JoeAndrieu, you wanted to say yes. that's the context in which I'm dereferencing the DID URL 14:39:51 ... So 14:39:57 Joe Andrieu: Um, so that is right, I do not need all that stuff. And I don't need all that stuff because I'm in a context... 14:40:04 ... that I understand, right? Either I'm evaluating the subject of a VC, I'm 14:40:12 ... dereferencing into an image tag in an HTML page. Like, the whole point is that the dereferencer is the one who knows 14:40:17 ... The context in which they are using that reference 14:40:23 ... And if what I need to do is check the proof, then really the only things I need to add to that algorithm are error handling 14:40:32 Will Abramson: Hmm... 14:40:35 Joe Andrieu: Like, hey, what if it's malformed? What if I didn't get the DID talk? Like, obviously, my little example snippet didn't deal with that. But either it fails or it succeeds, right? Either resolve works or it doesn't. Either the proof checks or it doesn't... 14:40:42 q+ 14:40:43 ... Um, and I know that I'm checking a proof because someone gave me a VC with a proof on it. And that is what my application is doing 14:40:48 ... And there's no need for me to engage with some generic thing that's gonna force 14:40:57 ... the JSON of that key to be represented in some way that either is… is, um, returned to RDF triples 14:41:11 q? 14:41:12 ... So that all the context is there. Or, um, I'm getting some weird subsection that includes the context, but not the other details. Like, how you actually return a snippet of a JSON-LD file is a hard problem 14:41:19 ... Um, and we don't propose an algorithm in here, we don't show how to do that. The calling application knows. In my case, when I'm checking a proof 14:41:26 ... I understand that I'm getting back a CID, which might be a DID, and I understand how to interpret the properties of that document 14:41:39 ... Um, I don't need a generic mechanism to arbitrarily give me some form of something I would call a resource. I can just directly interpret the result of resolution. to do the function that I need in that application 14:41:41 q? 14:41:43 ... That's 14:41:44 ack TallTed 14:41:47 Otto Mora: Right... 14:41:51 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): I think I hear what's going on. Um... 14:41:58 ... I think that… you are… Optimizing 14:42:02 ... your implementation of 14:42:04 bigbluehat has joined #did 14:42:08 ... the algorithm, etc. So, you don't need XY, and Z 14:42:11 ... So you don't implement it for your deployment 14:42:17 +1 14:42:20 ... And your deployment is not a general service that other things. Are meant to call in this way 14:42:25 ... Your deployment is a special purpose build that sort of 14:42:31 ... Blends a few things together, and in the process, drops a few things off 14:42:39 ... You know, when you go to the store and buy eggs, they come in a shell. You don't need the shell 14:42:42 ... It's just this thing that keeps the glop together 14:42:46 q? 14:42:49 ... And when you get home, and you're making a thing, you might separate the eggs that the 14:42:57 ... Consumable material from the shell, and then put the consumable material in the fridge overnight for whatever reason 14:43:02 ... And that's an optimization in your deployment of the egg 14:43:10 ... I think that's what I hear going on. And I think that's fine 14:43:21 ... Right, you're not making a general purpose thing for other people to work with in this sense. You're making a special purpose thing for your. Other things to work with 14:43:27 ... And that's okay. I don't see a problem with that. I don't think we have to document that 14:43:31 ... In the same way that we have to document the general purpose stuff 14:43:37 ... If I'm understanding things correctly. Which is always a mystery. That's it 14:43:38 q? 14:43:42 Otto Mora: Okay... 14:43:50 ... There was, uh, a comment there. Uh, that I just wanted to read. To highlight from 14:43:53 ... And 14:44:02 ... Ben, essentially, Andrew, we do have select Jason LD for selected disclosure in the ECDSA crypto suite 14:44:04 q+ to say the client is always special purpose 14:44:09 ... For what it's worth. Might work for subset creation for any JSON L. the doc 14:44:12 ... Uh, yes, uh, Joe 14:44:18 ack JoeAndrieu 14:44:18 JoeAndrieu, you wanted to say the client is always special purpose 14:44:26 Joe Andrieu: Um, yeah, so, plus one, a big blue hats, Benjamin's comment, um, but we have not defined that. Like, we have not pulled that in. We are, you know, it's… it's underspecified. What happens there? Um... 14:44:31 ... Uh, but to tell Ted's point, I 14:44:34 ... I think the client is always special purpose 14:44:39