14:00:39 RRSAgent has joined #did 14:00:44 logging to https://www.w3.org/2026/08/26-did-irc 14:01:29 present+ 14:03:10 swcurran has joined #did 14:03:15 present+ 14:03:45 transcriber_bot, connect 14:03:45 JoeAndrieu has joined #did 14:03:54 transcriber-bot, connect 14:04:03 transcriber-bot has joined #did 14:04:07 transcriber-bot, connect 14:04:08 scribe+ 14:04:18 Otto Mora: There you go... 14:04:21 Will Abramson: Okay, and then resume, right? Or is it going right now?... 14:04:24 ... Okay, cool. No, that's fine 14:04:27 Otto Mora: It's already on, but you can pause it if you want to... 14:04:33 Will Abramson: Uh... 14:04:41 ... Yeah, I mean, maybe we do just get started and see, like, maybe money's busy. I don't know about Marcus 14:04:45 ... Is there anything else you'd be expecting? 14:04:50 ... It's done. It's good. I'm done 14:05:03 ... Um, yeah, okay, let's just get started and, you know, if you're joining, you can join a bit late 14:05:04 Benjamin Young: Hey, hey, Will... 14:05:07 Will Abramson: Oh, hey, Benjamin... 14:05:11 ... Sure 14:05:11 Benjamin Young: Um, yeah, I was just checking Manu's calendar. He's traveling to San Jose today. I don't know what his actual schedule is, but… um... 14:05:13 Will Abramson: Okay, that's great. Thanks... 14:05:18 Benjamin Young: Yeah, he's out tomorrow as well, which is gonna… In fact, probably they did... 14:05:22 ... Working group stuff and the BCWG stuff both, Dave 14:05:25 Will Abramson: Okay, cool. Thank you... 14:05:34 ... Um, yeah, okay, so welcome everyone to today's Good Working Group Special Topic Call 14:05:44 ... as I did briefly mention, we'll just be continuing what we did last week on the Wednesday's call, uh, and working through the presentation that Stephen Cowley put together for 14:05:48 https://github.com/w3c/did-resolution/pull/344 14:05:55 ... sort of issues that have been, or comments that need addressing, uh, referring to PR344… which I'll just drop in the chat 14:06:07 ... So this PR around the URL dereferencing algorithm, we're still just working through these issues, trying to get to complete spec text so we can get this section in. Uh, and with that, I think I'll… I'll just hand over to you, Steven 14:06:10 Stephen Curran: Okay, sounds good. Let me share... 14:06:15 danpape has joined #did 14:06:17 dmitriz has joined #did 14:06:21 ... Okay, um, I added a section to start 14:06:24 Will Abramson: Oh... 14:06:24 present+ 14:06:29 Stephen Curran: to cover this mental model mismatch. What's that?... 14:06:31 Will Abramson: We can't see your presentation, Stephen. We see the IRC. I can see the IRC bot, but not the presentation... 14:06:34 Stephen Curran: So... 14:06:36 ... I have a new setup, can you tell? 14:06:37 Will Abramson: Hahaha... 14:06:40 Stephen Curran: Not used to it yet... 14:06:44 ... I've got, um 14:06:52 ... Everything on screen 2, not screen 1, as it's always been for years and years. How's that? 14:06:55 Will Abramson: Yeah, let's do it. Yeah, we got you... 14:06:58 Stephen Curran: OK, I wanted to do a brief step back on the mental model mismatch... 14:07:04 bigbluehat has joined #did 14:07:04 ... This came to light over the last, um, conversations, and so 14:07:10 ... This is the, I think, the core of where a lot of the, um 14:07:23 ... difficulties in this VR come from. And I think if we, you know, we understand this, we get we can get past them much easier 14:07:26 ... I and and perhaps others thought the algorithm is 14:07:34 ... Called by a Business Aware DREF client, I'll call it a DREF client 14:07:39 ... So, it is essentially a DREF service that has 14:07:51 ... that is given the DID URL, returns a result, and has no business knowledge. Does not know why it's being called, does not know anything other than, hey, here's a DID URL, go deal with it 14:07:57 ... Joe and perhaps others assume that the algorithm is implemented by a resolution 14:08:01 ... is… is a resolution client. There's no other client 14:08:09 ... Um, it knows the DID URL, it knows the business purpose, um, for which it is being, uh, run 14:08:14 q+ 14:08:19 ... And the actions within the algorithm depend on known business requirements. It's executing the business. Um 14:08:31 ... Those are the two mental models that I think have been conflicting over the last while. Certainly I have, and I think I've captured Joe's. View 14:08:35 ... Um, and, um, so I just wanna 14:08:43 ... A, state that explicitly, and then say 14:08:48 ... You know, I assume we are good with Joe's assumption 14:08:56 ... would go the other way. But I think the group is fine with going with Joe's I would propose. Maybe we change the section to make that clearer 14:09:16 ... Um, by adding, you know, adding, did URL do referencing by a resolution client so that it's clear, and then add an intro to Section 6, what's currently Section 6 in PR344 that goes over that mental model to make sure there's no. People reading it that that 14:09:30 ... have the previous… the assumption that I think was also the Section 5 assumption, um, of the, um, that it's just… it just has the URL and nothing else, doesn't have a knowledge of the business. So 14:09:33 ack Wip 14:09:33 Will Abramson: Alright, thanks. I put myself on the queue, Stephen, if that's alright... 14:09:35 pdl-asu2 has joined #did 14:09:41 Stephen Curran: Yeah, yeah, that's as far as I wanted to go, so yeah... 14:09:52 Will Abramson: Yeah, great. I mean, I just wanted to add, maybe, I think I agree with that analysis. I guess, you know, partly this got… this mental model, or the mental model of the dereferencing client, I think got put in... 14:10:03 ... really through Marcus and his sort of, like, mental model from the universal resolver as a way that, you know, dereferencing might happen. And I think, if you just go back to slide 3 14:10:08 ... I think the thing that Joe's been trying to get us to tell us, uh, is that 14:10:23 ... you know, the point that you're saying here, that there is a DREF client and a DREF service. That might be the way that some people choose to implement this thing, right? Like, they might have this DREF service in their code 14:10:32 ... That has no business-aware logic, and just executes some of the dereferencing algorithm and returns it to this client that then does things. But 14:10:49 ... that shouldn't be the way that the spec sort of, like, directs people towards as the way to implement this. I think by having this sort of more generic approach, like, there's this resolution climb that does these things 14:10:53 ... Then it's up to the implementer to decide how they want to break and, like, choke that up 14:11:01 ... I think this mental model mismatch is saying, if we take the approach that Joe is advocating for. The approach that is in the spec currently is still perfectly legitimate 14:11:09 ... way to implement this thing, but it's just not something that the spec is, like, prescribing. That's my understanding of the… Okay 14:11:13 TallTed has joined #did 14:11:17 q+ 14:11:21 ... Uh, and then the other thing I was going to say, actually, was that I like your new proposed title, uh, for section. I think it would help people. I don't know what other people think 14:11:24 ack JoeAndrieu 14:11:24 Stephen Curran: Um... 14:11:26 ... Okay, Joe? 14:11:29 Will Abramson: Well, I see Joe. Yeah, Joe... 14:11:42 Joe Andrieu: Um, that was a good summary of this disconnect. Um, and I could… if it's helpful for folks, just chime in... 14:11:54 ... I could walk through the… in DID resolution, we're using, um, a diagram that I think illustrates, sort of, the distinctions, um, but also we don't need to bring that in if… if 14:12:04 ... We feel like maybe we're converging towards something. My sense, Steven, is maybe the most good we would do is to change the name of that section 14:12:16 q+ 14:12:27 ... Like, just stop calling it dereferencing, and just call it whether it's client algorithm or, you know, the client resolution. But we basically are describing a client server architecture, and we have a an algorithm for what the server needs to do that's execute the resolve 14:12:30 pdl-asu2 has left #did 14:12:34 ... Procedure. Um, and we have an ACPS binding for that 14:12:38 ack swcurran 14:12:39 ... And we have a client algorithm, which is what the client to the resolver should do, um, before they call the resolver, how they call the resolver, and how they handle the response to the resolver. So, maybe just getting rid of that term dereferencing would be clarified 14:12:42 Will Abramson: Go, Steven... 14:12:52 Stephen Curran: Um, I… I'd be a little concerned with that, because… Thank you... 14:12:59 ... for two reasons. One is that it is so ingrained in it, um, that's not a reason not to do it, but… but it is, um, a pushback on it 14:13:06 ... But the other is what Will said, which is, I think a lot of implementers will implement it in the way that 14:13:14 ... Um, that Marcus and I, uh, and others think about it, which is they will implement 14:13:22 ... uh, did… did reference her with… that will be called by a client, and that, um, implements it that way, I think 14:13:35 ... as Will said, there's different ways of approaching it, and we don't want to block out other ones. All I want to do… but I'm fine with explaining it in a way that's consistent 14:13:40 ... Uh, that's… that's clear. And so, um, I… I'd say 14:13:44 q+ to ask about other clients 14:13:51 ... I prefer the change of keeping the URL dereferencing in the title, but clarifying how it's being presented 14:14:04 +1 to Stephen's suggestion 14:14:11 ... And that includes that next comment, which is I kind of disagree and I've looked at it a bit to say that we need to change other parts of the spec to address this. I think it can be covered in an intro to this section to say, okay, here's 14:14:22 pdl-asu has joined #did 14:14:23 ... here's how we're approaching this. And, um, and that would cover it. We don't… I don't think there's massive changes needed, or significant changes needed in other parts of the spec to 14:14:25 ack JoeAndrieu 14:14:25 JoeAndrieu, you wanted to ask about other clients 14:14:27 ... cover this mental model. approach 14:14:27 present+ 14:14:27 Will Abramson: Thanks, Stephen. Joe?... 14:14:28 present+ 14:14:30 Stephen Curran: Joe... 14:14:39 ... Oh, yeah, absolutely 14:14:42 ... Absolutely. Yes 14:14:45 Joe Andrieu: One thing I'm not sure if you meant, Stephen, but I want to clarify. There is a whole section we need to get rid of, right? We have two competing dereferencing sections. Okay... 14:14:52 ... We are trying to have harmony with everything else, and we do know that there are going to be some… I just wanted to make sure we weren't passing… talking past each other on that point 14:15:01 ... Um, one of the things that concerns me about this particular phrase, and maybe a different phrase would address it, is that it implies that there could be DID URL dereferencing by something that isn't a resolution client 14:15:05 ... And that's the schism I'm trying to say, like, that is what's confusing people 14:15:13 ... Um, that what we are specifying is this HCTPS bonding to a resolving algorithm 14:15:17 ... And describing how people call it 14:15:22 q+ 14:15:23 ... We're not gonna describe the URL dereferencing by… A non-resolution client 14:15:26 ... Um, so… uh 14:15:39 ... that… that's why my… my suggestion was, the confusion seems to be, what client do you mean? The client to the dereferencer, or the client to the resolver? And I think they're… they're 14:15:54 ack Wip 14:15:56 ... I don't think there's any distinction between those two, so I'm trying to find a way for us to talk about that makes it clear there's no distinction between those two, that in terms of what is standardized, we're talking about what goes over the wire to resolve. And how you prepare for that and how you respond to what comes back 14:16:01 I have made the request to generate https://www.w3.org/2026/08/26-did-minutes.html TallTed 14:16:08 Will Abramson: Thanks, Joe. Um... 14:16:25 ... Yeah, I guess, like, I also was for keeping the GRL dereferencing. I think you're saying, like, don't put it in the title, right? But we're still talking about, like, the spec is going to talk about the GRL dereferencing, which would be fine to me. Like, I think to put it another way, you're saying… you know 14:16:33 ... Did URL dereferencing requires the execution of a resolution request? Thereby anything that you know implemented URL dereferencing is. A resolution client, a client of resolution. Which I think makes sense 14:16:41 ... And then, you know, if you, in your implementation, want to take that resolution client and chunk it up in different ways and call it different things 14:16:46 q+ 14:16:48 ... ah. That is also fine, but we're not going to tell you how to do that 14:16:51 ack ottomorac 14:16:59 ... Otto? 14:17:08 Otto Mora: Yeah, I just want to plus one Steven's suggestion. I mean, okay, maybe the title can just remain did you already referencing so that we don't always... 14:17:16 q+ 14:17:21 ... we're not forcing that there may not be a resolution client, but I think explaining those actors, the resolution client, or dereferencing client, and maybe even clarifying that they may be the same in some instances could be useful here. I just 14:17:23 ack swcurran 14:17:25 ... explaining it the way we think about it, I think that would be certainly useful 14:17:30 Will Abramson: Steven?... 14:17:37 Stephen Curran: I think that we need to be very clear that this is the resolution client and the description. that the... 14:17:43 ... The way it's being described is, as Joe says, a resolution client 14:17:58 ... unless we're switching to the different model, which I don't think the group wants to. Then we need to make it very clear. And that's why I propose putting it in the title and absolutely suggest the intro section that says, Here's the 14:18:05 ... The mental model you should be 14:18:17 ... in when you read this section. Now, how you implement it 14:18:21 ... Um, as Will says, you may do it in a different way, but you need to understand how this data is being presented, how this specification is being presented, how this algorithm is being presented, and that needs to follow 14:18:22 Will Abramson: um... 14:18:25 Stephen Curran: Um, the resolution client model... 14:18:37 Will Abramson: Yeah, okay, thanks. I mean, has anybody else, like I know we've heard from Joe and Stephen about this, like be interested in anyone else has strong opinions about this... 14:18:45 q+ 14:18:49 ack swcurran 14:18:54 ... this change that we're talking about, or not… it's really just a reframing of the mental model, and I think it's about clarifying the mental model, and being consistent about the mental model throughout the paper. Um, throughout the spec, sorry. Um. But, interested if anyone has comments. Uh, probably move on. Steven? 14:19:10 Stephen Curran: Just one other thing, which is clarifying the mental model so that while we talk about the PR, we're not talking past each other and trying to frame… trying to spin it in a different way, that we... 14:19:21 ... if this is the mental model we want to take, okay, great, now let's have the discussion on the rest of the things in that mental model, and not. push back into those different things. That's the biggest thing that 14:19:23 +1 to Stephen's suggestion, we're only describing one approach but acknowledge others may be possible 14:19:29 ... that I've seen with this is making sure that we're all talking about it the same way versus what we've been doing, which is talking about it in different ways 14:19:32 Will Abramson: Yep, totally. Um... 14:19:37 ... I think that's been holding us back a little bit, right? 14:19:37 q? 14:19:42 Stephen Curran: Okay... 14:19:42 Will Abramson: Um, okay, I mean, I'm not seeing anyone else on the queue, so... 14:19:44 Stephen Curran: Good to carry on?... 14:19:46 Joe Andrieu: Yeah, let me... 14:19:47 Will Abramson: Yeah, I mean, maybe we need… Oh, there you go, Joe... 14:19:50 Joe Andrieu: I was just gonna note, um... 14:19:56 ... I can take this as a friendly and and make an iteration that goes in this direction So 14:19:59 ... Consider this accepted as a suggestion for the PR in progress 14:20:02 Stephen Curran: Awesome. Thank you... 14:20:08 Will Abramson: Yeah, great. Yeah, I guess it would be great to see this intro section that Stephen's talking about, just clarifying the mental model that people can then read... 14:20:11 Stephen Curran: Um... 14:20:25 ... Okay, so that leads us to one clarifying point. So as you see, I put these together, assuming we get to that point, so that's good 14:20:32 ... There is this question we came up with, and we kind of resolved it, but I put a question mark on resolved. Um… that 14:20:36 ... In this particular question we talked about, there's a user 14:20:40 ... And… and that, uh 14:20:40 q+ 14:20:49 ... The resolution client picks a resolver it wants, or there was some talk that there's a user who would be able to supply the configuration 14:20:56 ... Do we need any clarification there? Because that's… this is the one place where it crept in that there's some other thing 14:20:58 ack Wip 14:21:04 ... Um, and so I wanted to raise this one more time, despite the fact that we got past this one. So, well… Go ahead 14:21:15 Will Abramson: Yeah, thanks. I mean, I would say something like the resolution client must be configurable, like, must enable configuration, like, maybe we don't need to talk about the user, but that is implicitly saying... 14:21:23 ... The resolution client should enable the configuration of the resolvers that it calls to execute specific resolution requests 14:21:25 ... Or resolution requests for specific methods, right? 14:21:27 q+ 14:21:28 Stephen Curran: Okay... 14:21:42 Will Abramson: I think that's what we're saying. There is this client that enables and provides configurable results that it's going to call rather than it being locked in and hidden away and not able to be changed... 14:21:42 ack JoeAndrieu 14:21:42 Stephen Curran: Go ahead, Joe... 14:21:43 Will Abramson: I don't know, while you're speaking, yeah... 14:21:48 Joe Andrieu: Yeah. I wanted to share my screen with a diagram I mentioned earlier... 14:22:03 ... This is the diagram that's the current center point for the DID resolution threat model. Um, and so the URL user here, E1, this first entity 14:22:18 ... is someone who is using the DID URL in an application that is DID-enabled, right? This could be an email client, it could be a web browser, it could be a wallet. Um, the nature of this application is its own point of existence 14:22:32 ... Um, that application doesn't necessarily have another software thing that is calling it, right? There isn't another client. This is the only client in the… in the process 14:22:33 q+ 14:22:49 q+ 14:22:50 ... Conceptually, it's everything in that loop. So how deep you want to go is up to you. If you wanted to threat model your concerns about hardware security or privacy, you would need more details in this diagram, but it would still all be in this user client device. Um, that then calls the resolver. Um… And so 14:23:05 ... the… with regard to the user here, we're talking about the person using this application ultimately having the authority to configure the resolvers. And I think one of the strong takeaways from the previous chat about it was, let's get it out of the loop 14:23:24 ... Because when it was in the algorithm loop, it made it sound like you would keep prompting the user. Like, which resolver do you want to use for this? Which would be crazy. Um, but moving it to the introduction section, which currently there isn't anything there, I think is a good spot to explain that, uh, there's a user, and, um 14:23:27 ack swcurran 14:23:29 ... We're talking about, how this algorithm processes and that they the user needs to be able to configure this capability 14:23:32 Will Abramson: Stephen?... 14:23:36 Stephen Curran: Um... 14:23:40 ... Yeah, that reverts back to this model that 14:23:49 ... Again, I… I find it confusing to say, okay, this user is invoking this 14:23:49 q+ 14:23:57 ... thing that we're not going to call a client, and passing a URL to it. If you had said. Um 14:24:08 ... the client pulls a DID URL from a verifiable credential. And that was written by 14:24:29 ... the issuer of the verifiable credential, I'd have been more comfortable, but that person, that entity doesn't care what resolver it is. The only entity that cares what resolver it is, is the C1D user client device in the mental model that. that you're saying, so I'm still a little confused by. that I 14:24:40 ... maybe we just need to say… yeah, I don't know. I don't know. I find this one… this leaves it as confusing. I don't know who… Um 14:24:43 ... The entity would be that decides 14:24:57 ack Wip 14:25:00 ... what resolver is needed, if the only thing we've got here is the client resolver. I guess you're saying it's a piece of software, and therefore, whoever owns that software needs to be able to configure it. Um… That's it 14:25:17 Will Abramson: Thanks, Stephen. Yeah, I don't know if I followed everything that you said, but, like, I also got a little thrown out by this, just because… I mean, I think it's saying, you know, like, say this client device is my mobile phone, right? And I, um... 14:25:28 ... you know, maybe somebody's sending me a verifiable credential, and then I'm performing… my client, my phone, is performing, like, resolution. I mean, like, performing the verification of the VC 14:25:38 ... Like, it is… I mean, really, the phone is the user of the DID URL, but I think, by implication, like, I am the user of the DID URL. Like, it's not so 14:25:49 ... Right, really, the client device is acting on my behalf, I think. And I should be able to configure the client devices that I use to interact with DID URLs 14:25:57 ack JoeAndrieu 14:25:57 Stephen Curran: But... 14:26:00 Will Abramson: But I think, you know, I use the URL, it's like not so explicit, right? It's not like I'm handing the device a edit URL. I don't know if that makes sense, but I think I understand this diagram. Joe?... 14:26:03 Stephen Curran: Okay... 14:26:06 Joe Andrieu: Um, yeah, to try and help with some of the... 14:26:14 ... What's the miscommunication here? F zero here is however the interface is allowing you to interact with it 14:26:31 ... You may, in fact, be typing in a full bid, just like you may type in a URL to your browser. But oftentimes, you just click on things, or you click on things, and the page then loads twenty different URLs. Right? There's a whole problem with cookies and and beacons and things of that nature 14:26:35 ... So this used the URL as is described. Later 14:26:44 ... is, in fact, however they're interacting with this app. And so, it may be you're interacting with a wallet 14:26:56 ... and you got an incoming credential from some service, and you want to verify that the credential that you just received shows up as legitimate, right? So you're going to verify the credential you were just given 14:27:08 ... Um, and you're gonna execute this DID resolution to go make sure that everything worked right. Um, so in that case, that client is the wallet. I would… I would… Caution, Will, about thinking about the phone as a client 14:27:13 ... The… the phone is a device 14:27:25 ... And we could break down the device into different containers of different trust boundaries. And we because some of these apps that you know we've been building, there are multiple apps on the phone 14:27:36 q+ 14:27:48 ... Um both of who are interacting right because you may have a browser based interaction and then there's a wallet based interaction and both of those apps are on the phone And so once you sort of start diving into the details of any particular deployment then you have to start modeling that So you you would add those components and you would say 14:27:48 hey there's a threat that maybe other applications on my phone are watching what I'm doing with the resolver 14:27:53 ... Right? That's a reasonable concern. The phone's actually pretty good about sandboxing. Um, but 14:28:10 ... I don't know. Hopefully that helps clarify. This user is just a human who's touching the device, interacting with the device. And that device and whatever logic stack it's running from operating system to drivers to libraries to end user apps, that's the whole client device 14:28:11 ack Wip 14:28:15 ... Which constitutes together a DID-enabled application that is going to do something with a DID. That's it 14:28:36 Will Abramson: Yeah, I think that makes sense to me, right? It's like whatever user actions trigger the invocation of, like, this dereferencing process and, like, the execution of the goal. Uh, the only thing that also throws me off a little bit is, like, it's not always a human, right? Like, there are cases where. Dereferencing and resolution 14:28:37 might occur through some, you know... 14:28:44 ... Back end like always on application or like obviously some AI might call it but I think more interesting like there are business 14:28:47 q+ there's always a human 14:28:51 ack JoeAndrieu 14:28:55 ... apps or websites and things that probably do dereference vid URLs without a human ever interacting with the system. But I think we're well. Okay, Joe? 14:29:03 ... Mm, mm 14:29:21 Joe Andrieu: Yeah, I would posit there's always a human. The human may have created the system and just let it run on its own. But that's the human who said, hey, software. Hey, ChatGPT. Go find me a bunch of dids and spam them all and try and take them out. Yes, you are creating an automated system that's actually going to go and do the rest of 14:29:21 this process... 14:29:25 q+ 14:29:36 ... Um, but it's… it's part of my practice in… in requirements engineering to say, wait a minute, who is the human who's actually involved? Because if we don't pay attention to that, we're gonna miss some administrative interfaces, or we're gonna miss some use cases that we aren't paying attention to. So even though you may break down that 14:29:36 did-user-client device in the 14:29:40 ... We may refactor it any number of ways. There's always some human that's driving it, in my opinion 14:29:43 ack Wip 14:29:47 ... That's right 14:29:50 Will Abramson: Yeah, okay, that makes sense to me. In that case, like, the DID URL user is kind of effectively the client administrator as well, right?... 14:29:55 q? 14:29:56 ... um… Okay 14:29:59 ... There's no one else on the queue. Maybe we can move on 14:30:02 Stephen Curran: Right?... 14:30:03 Will Abramson: I don't know, Steven, you have anything. Is that useful? Does that help?... 14:30:05 Stephen Curran: See my screen again?... 14:30:06 Will Abramson: Yep... 14:30:09 Stephen Curran: Okay... 14:30:14 Joe Andrieu: Yep... 14:30:17 Stephen Curran: Um, I think we resolved this one last week, so we'll skip by. Uh, Joe suggested using the new wording... 14:30:22 ... Uh… whoops, prepare resolution options… Um 14:30:34 ... Resolve that these are either from the DID URL or the business knowledge of the resolution client. It is constructing those… Um, options 14:30:41 q+ to accept with caveat 14:30:49 ... before calling the resolver. It could pull them from the DID URL, it could pull them from the business knowledge, which is required. It may have… we may want to add guidance, um… For the implementer on 14:31:03 ... care of using ones from the DID URL versus applying business knowledge, but that's up to… and that might be added, but that's where we are with this one. I think we're resolved on this one 14:31:08 ack JoeAndrieu 14:31:08 JoeAndrieu, you wanted to accept with caveat 14:31:09 ... Um, oops. Yeah 14:31:21 Joe Andrieu: Yeah, plus I just wanted to comment, Steven, that in addition, so I accept that as something we can, you know, to add this language either from the URL business knowledge. We also probably need to update the resolution section... 14:31:26 ... Um, because that's where these… how you prepare the options should be described 14:31:42 ... Um, like, it is a matter of the options called to resolution. That section, uh, I have not tried to update because we did this in an isolated way, so we will probably need more details over there if, in reading this section, it wasn't clear how you prepare resolution options 14:31:47 Stephen Curran: So... 14:31:56 Will Abramson: No, okay... 14:31:56 q? 14:31:59 Stephen Curran: Okay, that seems odd to me, but I'll make it... 14:32:03 ... Um 14:32:07 ... Any other… I'm just checking the queue. Nope. Okay. So, this one, uh, so this is the first new one we've got to, um 14:32:12 ... Did or did URL? So, first of all, that 14:32:20 ... There's the note about the working group debating did and did URL. I believe that debate is settled and we decided on did. And, um 14:32:23 easy fix. the pass to resolution is DID 14:32:36 ... so that's… that, um, chunk of text can be removed, and second, change the title section to resolve the DID versus resolve the DID URL, and I think those are part of the… Um, questions that Marcus has raised on the confusion of, um, that 14:32:41 ... that we're resolving the DID, we're not resolving the DID URL 14:32:45 ... in that section 14:32:48 ... Does that agree? 14:32:50 Joe Andrieu: Yep... 14:32:52 Will Abramson: Yeah. I think these are just little minor mistakes, right? Like, that should be easy to fix, yeah... 14:32:53 Stephen Curran: Okay... 14:32:56 Will Abramson: Yep... 14:33:02 Stephen Curran: Yeah, yeah, this one for sure is just a minor one. But I just… but it… Joe, there was a comment back, that's why I put it in. Okay, um... 14:33:07 ... The repeat. Section. Um 14:33:12 ... I think this is the one where it really became clear that the 14:33:27 ... algorithm is, um, business aware versus not, um, and this was totally why I didn't understand this. I… I would have thought that 14:33:34 ... The repeat was outside of the algorithm versus inside that the algorithm would 14:33:45 ... Pass back and be in so I think it would help to have a clarification that it's clearer that the reason you would repeat is the business knowledge is there 14:34:02 ... that certainly didn't come clearly to me. It might with the introduction of the mental model at the beginning of the section, if we add that. But I think this is another one where it could use a little bit clarification, but other than that. That's the reason for the confusion on the repeat 14:34:13 Will Abramson: I guess I would just say, yeah, I mean, I think I see how the introduction flows, and then we can revisit this if you still can get me some more... 14:34:16 Stephen Curran: Yep... 14:34:38 ... Okay, here is a style one, and I wanted to present this to the group. A couple, um, have proposed that… so, Joe's, um, PR has a diagram. So, if we jump to this section 14:34:47 Will Abramson: Thank you... 14:34:50 Stephen Curran: um, want to, uh, present this as an… oh, shoot. Um, I think people are familiar with the diagram that should be visible here, but it's not in the preview... 14:34:56 ... Um, but this is the diagram with the, um, if then else of 14:35:01 You can see the diagram here: https://raw.githubusercontent.com/w3c/did-resolution/e623427dd0ec786960d7f45cbed1e39832b2ccc6/diagrams/determine-handling-strategy.svg 14:35:06 ... the services step, and that, the path handler step, and so on. So, this diagram is here, and then. Um, in Joe's PR, each 14:35:14 ... Um, the if-then-else of that diagram is described in prose. In… in this 14:35:32 ... what I'm proposing, uh, is, and I think Ted proposed the same thing, that the prose is difficult to follow, and for those that think in particular ways 14:35:46 ... Um, it would be easier to have it laid out as an if 14:35:53 ... either if otherwise, because that's the term used up here, or else, if then else, um, type logic in here. So, the idea is, this is the diagram we were talking about, so it's here 14:36:04 ... it's laid out, and then the idea here is, oh, you get to this step here, and that is described in prose in Joe's PR 14:36:07 q+ 14:36:17 ... And what I'm proposing, and I have done this mostly with, um, AI, I haven't really edited these seriously, but, um, lay it out like this. Um, and 14:36:18 q+ to ask if the group prefers one or the other 14:36:25 ... So, if more than one are present, and then this is balanced by the else 14:36:47 ... continue on with the path handler step. The other thing that's included here that isn't in the pros is when an error occurs, set the error type. And so we've got an explicit setting of the error 14:36:53 ... And then the, um, what is the same is continue to the default did doc step 14:36:57 ... So the suggestion here is that I find it easier to follow this versus reading this 14:37:03 +1000 I think the ordered and unordered lists are far clearer than the prose 14:37:09 ... even though they are the equivalent. And so the idea we agreed to was to, um, present the two styles and suggest. Um, that they 14:37:11 ack Wip 14:37:12 ... To decide which is preferred 14:37:15 ... Well 14:37:19 Will Abramson: I put myself on the queue just to say... 14:37:21 +1 to ordered with bullets 14:37:29 ... I think I do prefer your style, but I wonder maybe if we can even make it more like Marcus's style, if you go back to the PR? 14:37:30 Stephen Curran: Okay, yeah... 14:37:32 Will Abramson: uh... 14:37:35 Stephen Curran: Either one, but you're stuck in Section 5... 14:37:39 Will Abramson: Yeah, if you go to the algorithm, by far... 14:37:47 Stephen Curran: Oh, sorry. Yeah. Helps if I click on the other one. Yes. Yeah... 14:37:54 ... Yes, um, so 14:37:57 Will Abramson: Yeah, just, I mean, around the numbering, right? Because you can have, like, 1, and then 1, and stuff, like, I think there's some sort of, like, algorithm thing in here that makes the numbering like that. Um, but yeah, I... 14:38:11 ... Okay 14:38:14 Stephen Curran: Yeah, if I could. This is sort of two way to as you layer it can go down. I would make these bullets so you don't go so deep. But this does go fairly deep once you get into 7.1 and 7.2... 14:38:18 ... Um, and these… and these numbers are valid, because then you can reference the number when you're 14:38:26 ... you know, implementing and talking about this with somebody. You could say, oh, but in 721, it says this 14:38:30 ack JoeAndrieu 14:38:30 JoeAndrieu, you wanted to ask if the group prefers one or the other 14:38:31 Will Abramson: Yeah, no, and I agree. That is a bit confusing, but I'm hoping with our modular refactoring, we're not going to have as much nesting as there is here... 14:38:32 Stephen Curran: Yes, yeah... 14:38:37 Will Abramson: Hahaha. Let's see, uh, Joe?... 14:38:55 q+ 14:38:56 Joe Andrieu: Yeah, I think this is just a matter of preference. I'm seeing from initial feedback in chat that quite a few people like it. I actually don't, but let me identify the one reason I don't is the ambiguity of English language in describing... 14:39:01 ... Uh, algorithms. So, it's not clear to me where the otherwise bounds in the description that you had it. Um 14:39:18 ... But if folks other than me feel like that's a coherent and better way to do it, I'll support it. The other thing that I think we probably shouldn't do is actually specify the error types. Um, because this isn't a function call where we're returning, uh, specific errors 14:39:24 ... Um, so… but… because the error types get very limiting, and if I'm 14:39:28 q+ 14:39:36 ... you know, this arbitrary function inside an arbitrary application, um, I may have to fit it into a completely different error architecture. And so the error that needs to be raised for my algorithm. Um, may need to be in a different namespace, or what have you 14:39:38 ... That's it 14:39:41 Stephen Curran: Interesting... 14:39:44 ... um… tall tech 14:40:04 TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, yeah, it was me who suggested going to the… the numbered lists, et cetera, uh, because I found in the prose writing, and I'll just give one example, that there was an if X… If not hex. otherwise set... 14:40:18 ... And I hope we all understand that you can… if you have X and not X, you have covered all scenarios, so there is no otherwise. But there was a lot of text in that otherwise, so 14:40:27 ... the otherwise bound does not exist in a useful way in that fashion. Um, I agree it can be unclear in these, uh 14:40:28 ack transcriber-bot 14:40:31 ack TallTed 14:40:35 ... enumerated steps where the otherwise bound goes, and I have no problem with changing that to something else. Um 14:40:44 ack Wip 14:40:46 ... It was just the logic broke hard when trying to follow the prose logic, and that's why I wanted it to turn into these steps. That's it 14:40:55 Will Abramson: Yeah, I mean, I think defining these algorithms is... 14:41:08 ... is a challenge either way. Um, I guess I actually wanted to talk about the error types. Like, I think I hear what Joe is saying, right? Like, there is not someone that maybe would be 14:41:13 Stephen Curran: Uh, yep... 14:41:18 Will Abramson: uh, ingesting these error types, but it does call into question the whole point of, like, having these error types in the specs. It's just a whole other thing that maybe we have to consider, right? If you have a… if you scroll down to the error section, Steven? All the way at the bottom. You know... 14:41:19 Stephen Curran: Shoot, where is it? Oh... 14:41:22 Will Abramson: Oh... 14:41:25 Stephen Curran: I bet if I click this, I would get to it... 14:41:34 Will Abramson: A bit higher up, a bit higher up there. Oh, yeah. Yeah. Yeah, I mean, the thing is... 14:41:41 ... there's a bunch of errors in here that are only relevant for dereferencing, right? Like, service not found, um, I guess multiple handler strategy. I don't know about representation, not the support, but, like 14:41:46 ... So, I guess it's 14:41:55 ... But maybe that is a bar, right? Like, we are defining standard errors for the resolve operation, because that is the standard interface that we're defining, and then the client errors 14:42:03 ... maybe we shouldn't redefine it. I don't know, I'd be interested to hear what other people think, but there are a few in here that probably 14:42:09 ... Actually, maybe there's less than I thought, right? Invalid options is fine for resolution, feature not supported, also fine for resolution 14:42:14 ... So maybe we'd only be getting rid of a few. I thought we'd be getting rid of a lot more 14:42:17 q? 14:42:19 ... I don't know. Questions of the group? Really? 14:42:22 s/there was an if X… If not hex. otherwise set/there was an "If X…; if not X…; otherwise…" set 14:42:29 ... Oh 14:42:35 ... I'm not seeing anyone on the queue, um 14:42:39 ... What do you think about that, Stephen? Do you think we should remove these errors from ours? 14:42:43 Stephen Curran: Um, I think it should be included, personally, but, um, I think it would help... 14:42:48 ... again, inconsistency on… on doing it. I mean, obviously, the 14:43:02 ... if it's a bespoke implementation for each client, it's… it's less of an issue, but it… it does… it does, I think, help to have the errors defined, and there aren't that many of them that 14:43:08 ... They're relatively along the lines of the same thing we already support in it, so 14:43:15 ... I preferred it. I just assumed they would be there 14:43:18 Joe Andrieu: Well, one of… one of the... 14:43:20 ... I don't see anyone on the queue. Um 14:43:23 Will Abramson: No, no, go for it... 14:43:32 Joe Andrieu: There's going to be a lot more errors that we're going to need to define. If we do want to define them... 14:43:43 ... Um, it could be that there are multiple services found, and that's the error, like… If you go up to that algorithm in the spec, right 14:43:48 Will Abramson: I, uh... 14:43:49 Joe Andrieu: There are several places that terminate with… you can look at the diagram in the chat, the SVG... 14:43:49 Stephen Curran: Yeah, I'm trying to get to the, oh, in the chat... 14:43:52 Joe Andrieu: I just put the URL that goes direct to the image... 14:44:03 ... There are a lot of places that raise an error. And so, if we do want to enumerate all of those, then we should do all of them. And 14:44:05 ... Not some arbitrary subset 14:44:08 Stephen Curran: Okay... 14:44:11 Joe Andrieu: So there's a raise error there that has, um, 7 incoming reasons for errors... 14:44:16 q+ 14:44:19 ack Wip 14:44:21 Stephen Curran: Yeah, no, I wasn't assuming we'd do just one of them, I'd assume we'd do all of... 14:44:24 Will Abramson: Yeah, I put my thumb just to say, like, I think... 14:44:32 ... I think we should definitely be defining the different kinds of errors that are raised. I guess, you know, what 14:44:42 ... Like, maybe we define them as we have defined them in problem details, but we say something like, you know. Like, it doesn't have to be so… hard and 14:44:58 ... fast, almost. Like, I think it's good to say, like, these are the different types of errors that get raised in this algorithm, or that get triggered in this algorithm, and maybe, like, this is one way that you could represent those errors, but you don't have. Whereas bid resolution, we explicitly want errors to be defined to use that problem 14:44:58 detail structure. So that's maybe potential 14:44:59 q+ problem details doesn't apply to the client algorithm 14:45:09 ack JoeAndrieu 14:45:11 ... Ha 14:45:14 ... Yeah, go 14:45:18 Joe Andrieu: Dang it. I forgot the two. Seeing no one else on there. Problem details is something that the resolver passes back... 14:45:33 ... Um 14:45:40 ... It's not something that currently we're even accumulating during the algorithm. The dereferencing algorithm 14:45:45 Will Abramson: So, um, maybe we're talking about two different, like, error sections, or, like, splitting the error sections up, because currently we do say, like, all errors must be represented in this problem details form. um... 14:45:48 ... Yep 14:45:51 Joe Andrieu: Right, which is part of the overprescription that... 14:46:01 ... is one of the sources of, let's clean this up. Um 14:46:05 ... I mean, it's good to have the standard. It's necessary, in my opinion, to have the standard form for how we serialize errors in the HTTPS binding. But 14:46:10 ... The the algorithm itself doesn't have. A return value 14:46:16 ... It may not be constructing problem details in that way 14:46:28 ack pdl-asu 14:46:36 Will Abramson: I don't know, does anyone else have opinions? Oh, Phyllis, to you on the que... 14:46:50 Phillip Long (GU, ASU): Yeah, it sounds like what we're saying is that the algorithm, the resolution algorithm itself, doesn't have defined errors. And if that's the case, then they should be removed from that section if there are some listed there. But, um... 14:47:03 ... I get the sense that people will be, at least to those naive and reading this for the first time, will be thinking that there might be algorithm, might be responses there that are error responses 14:47:18 ... that they need to have some statement about why they don't… they're not going to see any of that sort of thing. So, I guess I'm supporting the comment you just made about making two sections, where at least one section is talking about 14:47:19 q+ 14:47:26 ack Wip 14:47:30 ... the resolution itself, and there aren't defined errors there to be… to be… to be dealt with, and here's why. And where there are, you have the section above it where you have the errors defined clearly. Thanks 14:47:43 Will Abramson: Yeah, I think that makes sense, although I think the fact is that resolution has defined errors, and, like, they need to be precisely structured when they're serialized, but dereferencing... 14:48:00 ... While it has defined a set, you know, we can describe a set of errors that might occur during dereferencing. We can enumerate them, we know what they are at the seven points, and I think it is useful to be able to say this error is blah blah blah, but we don't need to prescribe. Walmart, that you would 14:48:05 ... You know, serialize that error too, because potentially you're not serializing to anyone. Is that 14:48:13 Phillip Long (GU, ASU): So if I could jump in, what you're saying is, is that we're not gonna define the format of those, but there are the, here's the list of what they might be... 14:48:17 Will Abramson: Yeah, here's a definition for, like, you know, like, what… like, here's a description of them... 14:48:21 Phillip Long (GU, ASU): Right, right. Okay... 14:48:26 ... Does that make sense to you, Joe? 14:48:29 Will Abramson: There's not much... 14:48:36 Joe Andrieu: Yeah I was just checking the queue. yes I think that makes sense I think what we're saying is let's do enumerate the error types... 14:48:42 ... Um, but we also need to clean up the problem details about the errors. Um 14:48:51 ... Because in alright in in many use cases you want the error to include the stack trace, for example. um 14:49:04 ... So I don't want to be over prescriptive about here's how you must represent these errors. But I think having an enumerated list is is probably a good idea 14:49:10 ... We just have to list all seven of those errors and double check to see if there are others that maybe we missed 14:49:17 Will Abramson: Great. OK. And then this will be something that we will handle after, right? Although maybe we even need an issue to track this... 14:49:26 ... I think that'll be a task once we've got this PR in to like go and update the errors section too. Separate these dereferencing errors out 14:49:31 Stephen Curran: Okay, so I wrote the results... 14:49:36 ... On this, is that… we agree that's… what we've got 14:49:49 ... Right, right 14:49:49 q+ to ask about two sections 14:49:54 Will Abramson: I think that's right, I mean, just knowing that, obviously, I think markets will push back against this, and hopefully we're going to write from that proposal, you know, to finalize this, because... 14:50:03 ... I think many in the group are saying, no, hey, GPP binding, or no abstract functions, there's no, like, inputs and outputs, but, like, if there's no output, uh, like, why, then there's. Errors that need to be sort of 14:50:07 ... render like represented in those outputs. But 14:50:18 ... Yeah, I guess the thing is… yeah, well, we're gonna run this payout… this proposal tomorrow. But yeah, I think this is a result for everyone on the call. Joe? 14:50:23 ... Yeah, yeah 14:50:28 Stephen Curran: Yeah, I mean, we're only talking Section 613 here. We're not talking the rest of the spec or resolution, so that no HTTP hiding is... 14:50:32 ack JoeAndrieu 14:50:32 JoeAndrieu, you wanted to ask about two sections 14:50:35 ... Because there's no HDB binding, we don't want to be overly prescriptive about how to present them. That's, I think, what Joe said. Cool 14:50:38 Will Abramson: Joe?... 14:50:46 Joe Andrieu: So, I… I think, and this is a question, I think there's also some consensus towards separating the two sections, so that there's... 14:50:53 ... I'm error handling for the resolution algorithm, which uses problem details, and we're describing that in detail 14:50:56 ... Um, and then, rather than 14:51:02 ... Put the referencing related errors in that same section, have a separate section 14:51:18 ... probably a subsection of the dereferencing algorithm. So I just want to clarify, do we have that consensus to go ahead and split those two so that the resolvers are together in a namespace, and then separately we're talking about the dereferencing algorithm errors? 14:51:24 ... Based on your typing, I'm guessing you're on board with that, Steven 14:51:27 Will Abramson: I think... 14:51:31 Stephen Curran: I'm, uh, ambivalent. It works... 14:51:41 q+ 14:51:43 ... No 14:51:48 Will Abramson: It makes sense to me, but I think maybe if we were going to do that, we would be getting rid of the errors section and, like, refactoring the relevant errors into the relevant sections, right? Like, resolution errors would go under resolution. No. Yeah, well, I don't know... 14:51:50 Stephen Curran: Oh, sorry. Um... 14:51:52 ack swcurran 14:51:53 Joe Andrieu: I would I would support that but also, clearly Stephen has a different meaning. Go ahead. Not in the queue, Stephen. Sorry... 14:51:58 Will Abramson: Hmm... 14:52:01 Stephen Curran: because we are saying there is HTTP binding for... 14:52:06 ... Resolution 14:52:13 Will Abramson: Mm-hmm... 14:52:16 Stephen Curran: And we want problem details and them to be able to implement a resolver that provides very clear results. I think we should keep a specific error section for that... 14:52:22 Will Abramson: Mmhm... 14:52:24 +1 dereferencing errors separted 14:52:25 Stephen Curran: I see the logic of separating out into this section the errors that occur during dereferencing that might be independent of those, and I'm fine with that... 14:52:32 ... Yep 14:52:35 Will Abramson: Okay, well, I think we can move on, and we can obviously come back to this when it gets time to, like, actually address that, you know, this little later thing, I think... 14:52:39 ... Maybe time one more 14:52:42 Stephen Curran: Um, you wanna try one more?... 14:52:43 q+ 14:52:45 Will Abramson: Yeah, I think we've got 8 minutes... 14:52:54 Stephen Curran: Um, this was a conversation, and I probably should have a link to it. Um, this is... 14:52:57 ... You know, I've got a link to where in the spec it is 14:53:04 ... Um, excuse me. Uh 14:53:11 ... Joe commented, this is removed as we have a firm proposal for handling query parameters 14:53:19 ... I wasn't sure what you meant by firm proposal. Um, I don't know if that's enough context for you to… Answer 14:53:23 https://legreq.github.io/did-resolution/#ref-for-dfn-query-parameters-step-1 14:53:25 ack JoeAndrieu 14:53:27 ... Um, if not, I can get more details. I thought of this, and I just didn't have time yesterday to add the more details. Um… Joe 14:53:36 Joe Andrieu: Um… Yeah, there's a section in the algorithm for query parameters. Um… So that's… that was the section I was referring to... 14:53:45 ... Step 5 there, and the query parameters, step 14:53:51 Stephen Curran: Okay, yeah, um… I think the comments around it... 14:53:54 ... didn't address that 14:53:57 ... Okay, we'll leave it at that 14:54:02 Joe Andrieu: No, no, that was added because of this issue... 14:54:04 Stephen Curran: Oh, so the firm proposal is the query parameter step. Okay... 14:54:14 ... Yeah, okay. Okay 14:54:17 Joe Andrieu: Correct. It didn't exist before, and part of what we talked about when we went through the algorithm was like, hey, should it be before this one, or should it be after this one? Do you remember that conversation? So that was new in this updated to the PR... 14:54:20 Stephen Curran: Um, let's try this one as well... 14:54:33 ... Since we, I think this will be quick and we were just talking about errors before this. All the error paths go to the return did doc 14:54:49 ... but there's no mention of whether we're just falling through to this return did doc, or we got an error, and so we were directed into this. And it seemed… it felt like to me that there should be some. guidance given 14:54:59 ... when we get to this via an error. And so I wanted to raise that as a question. Do we think? 14:55:00 q+ to say the guidance is "raise an error" 14:55:06 ... And so it relates to that previous discussion of errors. Joe wondered if you could comment on that 14:55:09 Joe Andrieu: Um... 14:55:15 ... Yeah. If you can think of language that makes things clearer, but the guidance is raise an error 14:55:24 ... Um, and so that's in all the process. Like, if this happens, raise an error, and then go to the return to deduct step. Um 14:55:31 ... I'm not sure what more guidance you want other than we can, as we just talked about 14:55:42 ... say, for each of the particular ones, like, raise a service not found error, or raise a bad query type error, or whatever the trigger is. So 14:55:47 ... If that would address your concern, then this is an easy fix. If there's more, help me understand what you're looking for 14:55:50 ack JoeAndrieu 14:55:50 JoeAndrieu, you wanted to say the guidance is "raise an error" 14:55:55 Stephen Curran: No, I think that, I mean, I just think in section 1619, it's very short... 14:56:04 ... Um, just says simply return the document, and… and I'm just saying, oh, by the way, we could have got here from an error, so 14:56:15 ... include with it the status, whether that be that we got here without an error, or we got there with an error. I just think it should be… and so I can try putting words in 14:56:19 ... Okay 14:56:22 Joe Andrieu: Okay. Yeah. I would be welcome to some suggested language... 14:56:27 Stephen Curran: All right. Just to summarize where we got to. um... 14:56:30 Will Abramson: Yeah, how many more is there?... 14:56:34 Stephen Curran: So, the remainder, I think... 14:56:38 ... Yeah, the multi-endpoints, uh, one 14:56:43 ... Path handling, I think we've more or less got to that one, but we'll see 14:56:48 ... And then the Marcus, um, discussions. Are the ones that remain after that 14:56:54 ... So hopefully, we'll get through that with maybe one more session, maybe a half a session 14:56:59 Will Abramson: Yeah, well, we might have some time tomorrow, so we'll try and, um... 14:57:08 ... get through. And I guess, Joe, a question to you, are you… we're gonna try and get through all these, and then you're gonna try and take a pass to… And. update 14:57:16 Joe Andrieu: Um, yes, I might have some appetite this weekend. Um, I try and block some time on my weekends to, like, advance if there's a chunk. Um... 14:57:32 ... I have not done anything yet, because I… was working on the resolution threat model this last weekend. Um, but… uh, so I may be able to incorporate some of the things we've already talked about. Um, in fact, Steven, if you can send a URL to the 14:57:33 Stephen Curran: Yep... 14:57:36 Joe Andrieu: the deck with those, uh, the resolutions on it. Um... 14:57:42 ... Because I may as well try and get some done this weekend, but I am definitely planning on taking all the notes from this 14:57:46 ... For a pass at the end of the however many more meetings we have for it 14:57:46 Will Abramson: Great, that's appreciated... 14:57:48 Stephen Curran: Awesome... 14:57:50 Joe Andrieu: But I'll try and do some interim as my point. Well... 14:57:54 Will Abramson: Cool. Thank you so much. Um... 14:58:00 ... Alright, wonderful, thanks for that, Stephen, for letting us do that, I appreciate that. And, um, we'll see you all tomorrow, I hope? 14:58:04 Joe Andrieu: Cool. Thanks, guys... 14:58:06 scribe- 14:59:01 zakim, end the meeting 14:59:02 As of this point the attendees have been ottomorac, swcurran, dmitriz, TallTed, pdl-asu 14:59:03 RRSAgent, please draft minutes 14:59:04 I have made the request to generate https://www.w3.org/2026/08/26-did-minutes.html Zakim 14:59:07 I am happy to have been of service, ottomorac; please remember to excuse RRSAgent. Goodbye 14:59:11 Zakim has left #did 14:59:32 JoeAndrieu has left #did 15:02:59 dmitriz has joined #did 15:04:21 agendabot has joined #did