Meeting minutes
<Wip> transcriber_bot, connect
<Wip> transcriber-bot, connect
<Wip> transcriber-bot, connect
Otto Mora: There you go...
Will Abramson: Okay, and then resume, right? Or is it going right now?...
… Okay, cool. No, that's fine
Otto Mora: It's already on, but you can pause it if you want to...
Will Abramson: Uh...
… Yeah, I mean, maybe we do just get started and see, like, maybe money's busy. I don't know about Marcus
… Is there anything else you'd be expecting?
… It's done. It's good. I'm done
… Um, yeah, okay, let's just get started and, you know, if you're joining, you can join a bit late
Benjamin Young: Hey, hey, Will...
Will Abramson: Oh, hey, Benjamin...
… Sure
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...
Will Abramson: Okay, that's great. Thanks...
Benjamin Young: Yeah, he's out tomorrow as well, which is gonna… In fact, probably they did...
… Working group stuff and the BCWG stuff both, Dave
Will Abramson: Okay, cool. Thank you...
… Um, yeah, okay, so welcome everyone to today's Good Working Group Special Topic Call
… 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
<Wip> w3c/
Will Abramson: sort of issues that have been, or comments that need addressing, uh, referring to PR344… which I'll just drop in the chat
… 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
Stephen Curran: Okay, sounds good. Let me share...
… Okay, um, I added a section to start
Will Abramson: Oh...
Stephen Curran: to cover this mental model mismatch. What's that?...
Will Abramson: We can't see your presentation, Stephen. We see the IRC. I can see the IRC bot, but not the presentation...
Stephen Curran: So...
… I have a new setup, can you tell?
Will Abramson: Hahaha...
Stephen Curran: Not used to it yet...
… I've got, um
… Everything on screen 2, not screen 1, as it's always been for years and years. How's that?
Will Abramson: Yeah, let's do it. Yeah, we got you...
Stephen Curran: OK, I wanted to do a brief step back on the mental model mismatch...
… This came to light over the last, um, conversations, and so
… This is the, I think, the core of where a lot of the, um
… 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
… I and and perhaps others thought the algorithm is
… Called by a Business Aware DREF client, I'll call it a DREF client
… So, it is essentially a DREF service that has
… 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
… Joe and perhaps others assume that the algorithm is implemented by a resolution
… is… is a resolution client. There's no other client
… Um, it knows the DID URL, it knows the business purpose, um, for which it is being, uh, run
… And the actions within the algorithm depend on known business requirements. It's executing the business. Um
… 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
… Um, and, um, so I just wanna
… A, state that explicitly, and then say
… You know, I assume we are good with Joe's assumption
… 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
… 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
… 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
Will Abramson: Alright, thanks. I put myself on the queue, Stephen, if that's alright...
Stephen Curran: Yeah, yeah, that's as far as I wanted to go, so yeah...
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...
… 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
… I think the thing that Joe's been trying to get us to tell us, uh, is that
… 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
… 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
… 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
… Then it's up to the implementer to decide how they want to break and, like, choke that up
… 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
… way to implement this thing, but it's just not something that the spec is, like, prescribing. That's my understanding of the… Okay
… 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
Stephen Curran: Um...
… Okay, Joe?
Will Abramson: Well, I see Joe. Yeah, Joe...
Joe Andrieu: Um, that was a good summary of this disconnect. Um, and I could… if it's helpful for folks, just chime in...
… 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
… 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
… 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
… Procedure. Um, and we have an ACPS binding for that
… 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
Will Abramson: Go, Steven...
Stephen Curran: Um, I… I'd be a little concerned with that, because… Thank you...
… 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
… But the other is what Will said, which is, I think a lot of implementers will implement it in the way that
… Um, that Marcus and I, uh, and others think about it, which is they will implement
… uh, did… did reference her with… that will be called by a client, and that, um, implements it that way, I think
… 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
… Uh, that's… that's clear. And so, um, I… I'd say
… I prefer the change of keeping the URL dereferencing in the title, but clarifying how it's being presented
<ottomorac> +1 to Stephen's suggestion
Stephen Curran: 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
… 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
<Zakim> JoeAndrieu, you wanted to ask about other clients
Stephen Curran: cover this mental model. approach
Will Abramson: Thanks, Stephen. Joe?...
Stephen Curran: Joe...
… Oh, yeah, absolutely
… Absolutely. Yes
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...
… 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
… 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
… And that's the schism I'm trying to say, like, that is what's confusing people
… Um, that what we are specifying is this HCTPS bonding to a resolving algorithm
… And describing how people call it
… We're not gonna describe the URL dereferencing by… A non-resolution client
… Um, so… uh
… 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
… 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
Will Abramson: Thanks, Joe. Um...
… 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
… 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
… 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
… ah. That is also fine, but we're not going to tell you how to do that
… Otto?
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...
… 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
… explaining it the way we think about it, I think that would be certainly useful
Will Abramson: Steven?...
Stephen Curran: I think that we need to be very clear that this is the resolution client and the description. that the...
… The way it's being described is, as Joe says, a resolution client
… 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
… The mental model you should be
… in when you read this section. Now, how you implement it
… 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
Will Abramson: um...
Stephen Curran: Um, the resolution client model...
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...
… 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?
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...
… 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
<pdl-asu> +1 to Stephen's suggestion, we're only describing one approach but acknowledge others may be possible
Stephen Curran: 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
Will Abramson: Yep, totally. Um...
… I think that's been holding us back a little bit, right?
Stephen Curran: Okay...
Will Abramson: Um, okay, I mean, I'm not seeing anyone else on the queue, so...
Stephen Curran: Good to carry on?...
Joe Andrieu: Yeah, let me...
Will Abramson: Yeah, I mean, maybe we need… Oh, there you go, Joe...
Joe Andrieu: I was just gonna note, um...
… I can take this as a friendly and and make an iteration that goes in this direction So
… Consider this accepted as a suggestion for the PR in progress
Stephen Curran: Awesome. Thank you...
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...
Stephen Curran: Um...
… 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
… There is this question we came up with, and we kind of resolved it, but I put a question mark on resolved. Um… that
… In this particular question we talked about, there's a user
… And… and that, uh
… 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
… Do we need any clarification there? Because that's… this is the one place where it crept in that there's some other thing
… Um, and so I wanted to raise this one more time, despite the fact that we got past this one. So, well… Go ahead
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...
… The resolution client should enable the configuration of the resolvers that it calls to execute specific resolution requests
… Or resolution requests for specific methods, right?
Stephen Curran: Okay...
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...
Stephen Curran: Go ahead, Joe...
Will Abramson: I don't know, while you're speaking, yeah...
Joe Andrieu: Yeah. I wanted to share my screen with a diagram I mentioned earlier...
… 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
… 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
… 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
… 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
… 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
… 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
… We're talking about, how this algorithm processes and that they the user needs to be able to configure this capability
Will Abramson: Stephen?...
Stephen Curran: Um...
… Yeah, that reverts back to this model that
… Again, I… I find it confusing to say, okay, this user is invoking this
… thing that we're not going to call a client, and passing a URL to it. If you had said. Um
… the client pulls a DID URL from a verifiable credential. And that was written by
… 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
… 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
… The entity would be that decides
… 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
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...
… 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
… 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
… 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
Stephen Curran: But...
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?...
Stephen Curran: Okay...
Joe Andrieu: Um, yeah, to try and help with some of the...
… What's the miscommunication here? F zero here is however the interface is allowing you to interact with it
… 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
… So this used the URL as is described. Later
… is, in fact, however they're interacting with this app. And so, it may be you're interacting with a wallet
… 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
… 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
… The… the phone is a device
… 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
… 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
hey there's a threat that maybe other applications on my phone are watching what I'm doing with the resolver
… Right? That's a reasonable concern. The phone's actually pretty good about sandboxing. Um, but
… 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
… Which constitutes together a DID-enabled application that is going to do something with a DID. That's it
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
might occur through some, you know...
… Back end like always on application or like obviously some AI might call it but I think more interesting like there are business
… 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?
… Mm, mm
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
this process...
… 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
did-user-client device in the
… We may refactor it any number of ways. There's always some human that's driving it, in my opinion
… That's right
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?...
… um… Okay
… There's no one else on the queue. Maybe we can move on
Stephen Curran: Right?...
Will Abramson: I don't know, Steven, you have anything. Is that useful? Does that help?...
Stephen Curran: See my screen again?...
Will Abramson: Yep...
Stephen Curran: Okay...
Joe Andrieu: Yep...
Stephen Curran: Um, I think we resolved this one last week, so we'll skip by. Uh, Joe suggested using the new wording...
… Uh… whoops, prepare resolution options… Um
… Resolve that these are either from the DID URL or the business knowledge of the resolution client. It is constructing those… Um, options
… 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
… 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
<Zakim> JoeAndrieu, you wanted to accept with caveat
Stephen Curran: Um, oops. Yeah
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...
… Um, because that's where these… how you prepare the options should be described
… 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
Stephen Curran: So...
Will Abramson: No, okay...
Stephen Curran: Okay, that seems odd to me, but I'll make it...
… Um
… 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
… Did or did URL? So, first of all, that
… 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
<JoeAndrieu> easy fix. the pass to resolution is DID
Stephen Curran: 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
… that we're resolving the DID, we're not resolving the DID URL
… in that section
… Does that agree?
Joe Andrieu: Yep...
Will Abramson: Yeah. I think these are just little minor mistakes, right? Like, that should be easy to fix, yeah...
Stephen Curran: Okay...
Will Abramson: Yep...
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...
… The repeat. Section. Um
… I think this is the one where it really became clear that the
… algorithm is, um, business aware versus not, um, and this was totally why I didn't understand this. I… I would have thought that
… The repeat was outside of the algorithm versus inside that the algorithm would
… 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
… 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
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...
Stephen Curran: Yep...
… 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
Will Abramson: Thank you...
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...
… Um, but this is the diagram with the, um, if then else of
<Wip> You can see the diagram here: https://
Stephen Curran: 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
… Um, the if-then-else of that diagram is described in prose. In… in this
… 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
… Um, it would be easier to have it laid out as an if
… 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
… 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
… 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
… So, if more than one are present, and then this is balanced by the else
… 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
… And then the, um, what is the same is continue to the default did doc step
… So the suggestion here is that I find it easier to follow this versus reading this
<TallTed> +1000 I think the ordered and unordered lists are far clearer than the prose
Stephen Curran: 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
… To decide which is preferred
… Well
Will Abramson: I put myself on the queue just to say...
<ottomorac> +1 to ordered with bullets
Will Abramson: 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?
Stephen Curran: Okay, yeah...
Will Abramson: uh...
Stephen Curran: Either one, but you're stuck in Section 5...
Will Abramson: Yeah, if you go to the algorithm, by far...
Stephen Curran: Oh, sorry. Yeah. Helps if I click on the other one. Yes. Yeah...
… Yes, um, so
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...
… Okay
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...
… Um, and these… and these numbers are valid, because then you can reference the number when you're
… you know, implementing and talking about this with somebody. You could say, oh, but in 721, it says this
<Zakim> JoeAndrieu, you wanted to ask if the group prefers one or the other
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...
Stephen Curran: Yes, yeah...
Will Abramson: Hahaha. Let's see, uh, Joe?...
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...
… Uh, algorithms. So, it's not clear to me where the otherwise bounds in the description that you had it. Um
… 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
… Um, so… but… because the error types get very limiting, and if I'm
… 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
… That's it
Stephen Curran: Interesting...
… um… tall tech
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 X…; otherwise…" set...
… 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
… the otherwise bound does not exist in a useful way in that fashion. Um, I agree it can be unclear in these, uh
… enumerated steps where the otherwise bound goes, and I have no problem with changing that to something else. Um
… 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
Will Abramson: Yeah, I mean, I think defining these algorithms is...
… 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
Stephen Curran: Uh, yep...
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...
Stephen Curran: Shoot, where is it? Oh...
Will Abramson: Oh...
Stephen Curran: I bet if I click this, I would get to it...
Will Abramson: A bit higher up, a bit higher up there. Oh, yeah. Yeah. Yeah, I mean, the thing is...
… 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
… So, I guess it's
… 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
… 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
… Actually, maybe there's less than I thought, right? Invalid options is fine for resolution, feature not supported, also fine for resolution
… So maybe we'd only be getting rid of a few. I thought we'd be getting rid of a lot more
… I don't know. Questions of the group? Really?
… Oh
… I'm not seeing anyone on the queue, um
… What do you think about that, Stephen? Do you think we should remove these errors from ours?
Stephen Curran: Um, I think it should be included, personally, but, um, I think it would help...
… again, inconsistency on… on doing it. I mean, obviously, the
… 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
… They're relatively along the lines of the same thing we already support in it, so
… I preferred it. I just assumed they would be there
Joe Andrieu: Well, one of… one of the...
… I don't see anyone on the queue. Um
Will Abramson: No, no, go for it...
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...
… 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
Will Abramson: I, uh...
Joe Andrieu: There are several places that terminate with… you can look at the diagram in the chat, the SVG...
Stephen Curran: Yeah, I'm trying to get to the, oh, in the chat...
Joe Andrieu: I just put the URL that goes direct to the image...
… 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
… Not some arbitrary subset
Stephen Curran: Okay...
Joe Andrieu: So there's a raise error there that has, um, 7 incoming reasons for errors...
Stephen Curran: Yeah, no, I wasn't assuming we'd do just one of them, I'd assume we'd do all of...
Will Abramson: Yeah, I put my thumb just to say, like, I think...
… I think we should definitely be defining the different kinds of errors that are raised. I guess, you know, what
… 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
… 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
detail structure. So that's maybe potential
… Ha
… Yeah, go
Joe Andrieu: Dang it. I forgot the two. Seeing no one else on there. Problem details is something that the resolver passes back...
… Um
… It's not something that currently we're even accumulating during the algorithm. The dereferencing algorithm
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...
… Yep
Joe Andrieu: Right, which is part of the overprescription that...
… is one of the sources of, let's clean this up. Um
… 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
… The the algorithm itself doesn't have. A return value
… It may not be constructing problem details in that way
Will Abramson: I don't know, does anyone else have opinions? Oh, Phyllis, to you on the que...
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...
… 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
… 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
… 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
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...
… 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
… You know, serialize that error too, because potentially you're not serializing to anyone. Is that
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...
Will Abramson: Yeah, here's a definition for, like, you know, like, what… like, here's a description of them...
Phillip Long (GU, ASU): Right, right. Okay...
… Does that make sense to you, Joe?
Will Abramson: There's not much...
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...
… Um, but we also need to clean up the problem details about the errors. Um
… Because in alright in in many use cases you want the error to include the stack trace, for example. um
… 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
… We just have to list all seven of those errors and double check to see if there are others that maybe we missed
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...
… 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
Stephen Curran: Okay, so I wrote the results...
… On this, is that… we agree that's… what we've got
… Right, right
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...
… 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
… render like represented in those outputs. But
… 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?
… Yeah, yeah
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...
<Zakim> JoeAndrieu, you wanted to ask about two sections
Stephen Curran: 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
Will Abramson: Joe?...
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...
… I'm error handling for the resolution algorithm, which uses problem details, and we're describing that in detail
… Um, and then, rather than
… Put the referencing related errors in that same section, have a separate section
… 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?
… Based on your typing, I'm guessing you're on board with that, Steven
Will Abramson: I think...
Stephen Curran: I'm, uh, ambivalent. It works...
… No
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...
Stephen Curran: Oh, sorry. Um...
Joe Andrieu: I would I would support that but also, clearly Stephen has a different meaning. Go ahead. Not in the queue, Stephen. Sorry...
Will Abramson: Hmm...
Stephen Curran: because we are saying there is HTTP binding for...
… Resolution
Will Abramson: Mm-hmm...
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...
Will Abramson: Mmhm...
<pdl-asu> +1 dereferencing errors separted
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...
… Yep
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...
… Maybe time one more
Stephen Curran: Um, you wanna try one more?...
Will Abramson: Yeah, I think we've got 8 minutes...
Stephen Curran: Um, this was a conversation, and I probably should have a link to it. Um, this is...
… You know, I've got a link to where in the spec it is
… Um, excuse me. Uh
… Joe commented, this is removed as we have a firm proposal for handling query parameters
… I wasn't sure what you meant by firm proposal. Um, I don't know if that's enough context for you to… Answer
<JoeAndrieu> https://
Stephen Curran: 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
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...
… Step 5 there, and the query parameters, step
Stephen Curran: Okay, yeah, um… I think the comments around it...
… didn't address that
… Okay, we'll leave it at that
Joe Andrieu: No, no, that was added because of this issue...
Stephen Curran: Oh, so the firm proposal is the query parameter step. Okay...
… Yeah, okay. Okay
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...
Stephen Curran: Um, let's try this one as well...
… 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
… 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
… when we get to this via an error. And so I wanted to raise that as a question. Do we think?
… And so it relates to that previous discussion of errors. Joe wondered if you could comment on that
Joe Andrieu: Um...
… Yeah. If you can think of language that makes things clearer, but the guidance is raise an error
… 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
… I'm not sure what more guidance you want other than we can, as we just talked about
… 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
… If that would address your concern, then this is an easy fix. If there's more, help me understand what you're looking for
<Zakim> JoeAndrieu, you wanted to say the guidance is "raise an error"
Stephen Curran: No, I think that, I mean, I just think in section 1619, it's very short...
… 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
… 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
… Okay
Joe Andrieu: Okay. Yeah. I would be welcome to some suggested language...
Stephen Curran: All right. Just to summarize where we got to. um...
Will Abramson: Yeah, how many more is there?...
Stephen Curran: So, the remainder, I think...
… Yeah, the multi-endpoints, uh, one
… Path handling, I think we've more or less got to that one, but we'll see
… And then the Marcus, um, discussions. Are the ones that remain after that
… So hopefully, we'll get through that with maybe one more session, maybe a half a session
Will Abramson: Yeah, well, we might have some time tomorrow, so we'll try and, um...
… 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
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...
… 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
Stephen Curran: Yep...
Joe Andrieu: the deck with those, uh, the resolutions on it. Um...
… Because I may as well try and get some done this weekend, but I am definitely planning on taking all the notes from this
… For a pass at the end of the however many more meetings we have for it
Will Abramson: Great, that's appreciated...
Stephen Curran: Awesome...
Joe Andrieu: But I'll try and do some interim as my point. Well...
Will Abramson: Cool. Thank you so much. Um...
… Alright, wonderful, thanks for that, Stephen, for letting us do that, I appreciate that. And, um, we'll see you all tomorrow, I hope?
Joe Andrieu: Cool. Thanks, guys...