Meeting minutes
Agenda Review, Introductions (5 min)
<ottomorac> transcriber-bot, resume
Otto Mora: I assume...
… Okay, so today, uh, we have just a possibility we're discussing a special topic called on the 8th. That we are, um
… planning for, based on that discussion that we have today. Then we have a conversation around the DID path PR
… Which, uh, it has had a few updates, and I believe I saw a new PR from, uh, Steven
… Uh, and then we have an updated PR on the dereferencing changes suggested by Joe that we can talk about
… And then we can just have a little brief update on the status of the threat modeling
… But, uh, beyond that, does anybody else have any points that they want to mention before… oh, yeah, we'll
Will Abramson: Yeah, I just wanted to mention about the special topic call. Like, I think we will be having a special topic call, right? We're not sure about the...
… topic of the special topic call, I think we will decide that based on how the conversation today goes. But we definitely need more time, it feels like, so
Otto Mora: Yes. Uh, okay, and I see Manu?...
Manu Sporny: Yeah, a plus one to that, and I think we may want even more calls. I mean, we're in the final stretch, like, you know, a couple of weeks left, so, um...
… this is usually death march territory, right? Put everyone on a death march until the spec is done. Um, so… I would not be opposed to
<swcurran> +1
Otto Mora: Mhm...
… And, uh, Steven
Stephen Curran: I just did a plus one, I just agreed. That's all...
Otto Mora: Oh, sorry, okay, I thought it was… never mind, I thought it was a Q+. Okay, I also want to welcome today, uh, I see you there, Grace, uh, Grace Rakmani, Executive Director of the Decentralized Identity Foundation. Welcome to the meeting, thank you for… For joining, uh, good to have you here...
Grace Rachmany: Yeah, thanks. I didn't have enough working group meetings on my calendar, so I thought I would just, uh, sit in...
Otto Mora: Yes, I sometimes think the same...
… worry about how many identity-related meetings versus actual work meetings I have myself. Uh, okay
Reminder of Special Topic call for 8th Apr \[1\] (5 min)
Otto Mora: So, welcome. Um, yeah. So, on this, uh, next, uh, topic, I think we just said, right, we will have a special topic on the 8th, uh
… It will be at the usual time, uh, same time as this meeting, and
… And, uh, the topics to be determined based on the conversation here. The only, uh, caveat, I guess I would say is that those special topicals use the Google Meet
… Uh, so just a heads up on that, but anything else to add there, Will, regarding that special topic that we have on the calendar?
Will Abramson: Uh, I guess just to say, you know, I think I'm… I'm up for more calls, too. I guess we'll… like, people should just expect...
… We will be using this special topic called time to have calls throughout this month, right, from the 8th onwards, until we don't. Need them anymore. Um
Otto Mora: Mm-hmm...
Will Abramson: So, yeah. And that's great...
Otto Mora: Okay. Correct. Uh, yes, madam...
Manu Sporny: And apologies if I'm stomping on the agenda, but I'm wondering if we can get into a mode where we basically say...
… We are going to publish the spec that we have right now. That is just going to be our default plan
… Uh, and what we're really hoping to do is merge all these other PRs in, but if we don't, we would much rather, you know, have a spec out there in CR than… Not. Um
… And then I'm sure we'll, you know, work through the PRs as, as we, as we can
… And we can always, in the spec note, hey, there are PRs in flight, there are issues in flight, implementers must pay attention to those
… take those into consideration, um, you know, as you're implementing 4CR, and that allows us to just warn the implementation community that we may have some
… adjustments to implementations, um, while, you know, entering CR
Otto Mora: Mm-hmm...
… Thank you
… Ah… So
… Uh, yes, Will
Will Abramson: Yeah, I guess, I mean, I think that's not a bad suggestion. I don't know what would be needed for it, like, is there anyone opposed to going down that route? Like...
… I know there's some… still some contention on the URL dereferencing section
<swcurran> Not a fan of that idea.
Will Abramson: Um, like, what are we expecting, Manu, to be the outcome of that? Like, do you want us to pass a proposal? Like, are we just sort of sensing from the group that
… that we're okay with this package. That's even
Otto Mora: Yes, madam?...
Manu Sporny: Um, the… the outcome would be us preparing a first public working dra… or sorry, not first… a candidate recommendation static snapshot...
… And then… saying that is going to be the thing that we… we, uh, publish
… Um, unless we merge some of these other PRs and get it in there. Um
… I… I understand… I'm not… I'm not a fan of this approach either, uh, just to be clear, um, but I think our back's against the wall at this point, and we need to publish something
… Um, uh, I don't, you know, and if we don't have agreement
… on these PRs, by the time we go into CR, then that's just where we are, right?
… Um, versus not having anything in candidate rec. You know, again, that would be a very bad look on the
… Um, on the, uh, on the working group, uh, when we ask for, uh, you know, a charter extension
Otto Mora: Uh, yes, I see Joe has his hand up, Joe...
Joe Andrieu: Yeah, I just… I just want to ask Amanda, what was the timing that you were proposing to this, in terms of when you want to see a...
Otto Mora: Like, the cutoff...
Joe Andrieu: Uh… lockdown for CR?...
Manu Sporny: Uh, the, and a, I mean, within, within the week, um, not a lockdown for CR, just a, we have something ready to go versus we have something ready to go...
… And as we merge PRs, we will update that something, but we have something ready to go. Right? Um
… If that makes sense. Like, we cut a static snapshot of the candidate rec
… and we've got it ready to go, so that we can give a heads up to, like, W3C management, like, hey, we're getting ready to, you know, publish a CR, you know, get ready
… Um, and then we work as hard as we can over the next couple of weeks to get these PRs into that static snapshot
<Zakim> JoeAndrieu, you wanted to say we should decide about my PR before that, one way or another. It isn't amenable to an "at risk" tag
Manu Sporny: Um, but if we don't, then we don't, right? But we'll still have a warning in that static snapshot that, like, hey, there's still PRs in flight, there's still issues that we are going to address and see our implementers, you know. Uh, beware
Otto Mora: Uh, Joe?...
Joe Andrieu: Yeah, if that's the case, then I think we should resolve one way or the other about whether or not we're gonna go with the PR that I've presented...
… Uh, because I think that is too much of an edit to be an at-risk marker. Um, I don't think that would work
Otto Mora: Mm-hmm...
… I think both changes are pretty substantial, just to say myself
… let's try to just work through this meeting and get that done, I would agree with that. And then we can
… Yeah, maybe the rest of the changes aren't as substantial, right, Will? I think it… Just the size of the… Of the change
… Okay, well, uh, let's just move on. I think we hear Humano and
DID Path PR \[2\] (15 min)
<ottomorac> w3c/
Otto Mora: Yes, let's do our best to just get this done. Um
… Okay, so on this Did PathPR, I wanted to give the floor to Steven
… Um, I will note that there is a new PR, which is, uh
… Not 260, it's 316 now, right?
Stephen Curran: Yeah, it's 316 now...
… Um
Otto Mora: Okay...
Stephen Curran: The attempt at resolving the conflict was a disaster...
… Um, so I just had nothing that I could go forward with with that. So, um
… took the content, um, missed one little piece that Will pointed at this morning that I corrected this morning
… So, it's there. Um
… There are only 4… blocks of changes
… Um… and those are listed in the comments. Um
… It looks like, from Will's comment, I also missed… in… recall, in the previous iteration that I worked on. I opened
… Try to make a wider tint of the object types, so not limited to service types, is, um… Joe, uh, had objected to
… Um, the idea that only service types could reference other resources, um, and so expanded
… that looks like I missed one spot. I think that's what Will's saying in his last comment
… Um, but other than that, the sequence… the algorithm sequence is the same as before
… And, um, includes, you know, the handling of when you have
… Service, and or service type, and or relative rep, and or a patent
… And just walks through the steps you take to
… Process, and come up with a result
… Um, so, as I say, I think everything's there, um, and it's… Pretty much what was, um
… What was, uh, there before, uh, just with
… Uh, the cleanup done. So that's that. Questions?
Otto Mora: Does it need one...
… Final adjustment based on Will's comment, or it's now
Stephen Curran: Um, I think, Will, you just said it looks like there's a place where I say a list of service objects one more time, or is it more… more than that?...
Will Abramson: Uh… yeah, well, definitely that needs to be fixed. That's a mistake just in the current approach...
Stephen Curran: Yeah...
Will Abramson: Yeah, I guess...
… I… I mean, I… my concern is that this PR and Joe's PR are just in huge conflict
Stephen Curran: Oh, absolutely. I...
Will Abramson: Um… uh...
… I don't know what the… how we resolve that conflict, but… I mean, I've read both of them, right, and I've tried to understand
… What is being proposed in terms of, like, how you… how you… each of you are proposing handling paths. And there are just some things in there that are just complete
… completely different approaches. So, I would like to see us discuss those… I mean, I've highlighted 3 differences
… like, maybe we can discuss them individually, and as a group, like, what do people think is the best approach, right? My concern is if we merge this
… Fine, but what happens then, like, with 311, 316, or whatever one it is. Um… I don't know, um… Open to what people think, really
Otto Mora: Mm-hmm...
… Okay, so yeah, I see we got a few people, um… Steven?
Stephen Curran: So, in, in looking at the 2, I think, um, Jose, while, while the repositioning. of Joe's, um...
… in Joe's PR is… is… is interesting and helpful, I think
… The changing of the algorithm is inappropriate. I think the… there's a pretty radical change
… I think it's flat out in places wrong. Um
… Um, because of the, uh, sequential… if you see this, then this is what it is, and skip all the rest and go to the end, like, that just doesn't work
… So, even if it's, um… you know, it has to be reworked
… Um, I think it loses the existing even before my
… It doesn't align with what was there before, let alone what… how I've extended it. So, I think that. I don't think it's
… the comparison is necessary, because I think, um, that one needs to be reworked, even if, you know, even if we keep this reframing. of, um
… The… the resolution and dereferencing. I call
Otto Mora: Mm-hmm...
… Okay, and I see
… Yeah, one thing, it's like, um… I feel, Joe
… That it might also be worth socializing, like, uh, for everybody else that hasn't on the call
… Or, like, your new PR has… it's more readable route, right? So it might be
… Worth also spending some time on the call right now to highlight your changes, so that folks, maybe even screen sharing
… I don't know. So folks are aware, like, oh, this and this and this are the key changes there. Just my own personal… Yes, Shepard. Go ahead
Joe Andrieu: Okay, so I believe that's our next, uh, agenda item. It may have been easier if we had done that agenda item first, but...
… Um, we're… we're here talking about this did path algorithm. Um, I… I agree with Steven that this… this really is incompatible with my PR
… Um, and the, you know, the concern that it does not align with what was there before is because I disagree with what was there before. I do not believe we had an actual consensus around the notion of creating a separate standalone dereferencer
… Precisely because that's not how dereferencing works. And so this PR includes some language explaining what dereferencing means, including the sort of normal computer science meaning
… As well as what it means for a URL. Um, looking at this, so I have not, um, been able to process this deeply, because I've been paying attention to that and the threat model
… Um, uh, but looking at some of the issues that Will has brought up, I do not believe that it is possible
… For a did… for any URL to refer to multiple resources
… Like, by definition, a URL points to a resource. That resource may be a compound resource
… But leaving the ambiguity up to the caller to say, where does this URL go? I think that's a non-starter. I think that's a huge mistake
… Um, my… another concern I have is precedence, which I need to read through here and understand it. I do appreciate that Steven's trying… been trying to find a way that allows extensibility within the algorithm
… Um, but I think there's a big change here from where it was before, which it looks like it's the did method
… Uh, reads first, and I think the… if there is a service or service type parameter, that should read first
… So there may be more nuance there for me to understand, but that's… that's my first blush on that
… Um, and I also think we need to come up with a way, so even if, you know, to the extent we pursue this flexible path handling option, which I think we should figure out how to do
… I just… I'm not sure that this is the right way to do it, given that I think we need to explain the rest of the algorithm differently
… Um, I think we should introduce a path handling type
… Because, um, unless
… Um, uh, service endpoints specifically say, hey, I handle the path
… Then, um, endpoints that handle the path that were not known at the time that the software was written will not be included in the algorithm
… And so, we have this wonderful type feature in JSONLD, and we can specify a type, and it can be, you know, maybe path service is that type, but then we need an adjustment for that
… So, you know, it could be path handlers of type, that's another way to deal with that. Um
… Uh, and then the final thing is, I think these should not be service endpoints, because that
… It prevents the use case where
… Um, the URL is, in fact from, uh… uh
… uh, like, an on-chain resource, and it's not reducible to, um, a URL
… Um, so that's… that's my comments here
Otto Mora: Okay, so let me just try to suggest something, okay?...
… Right now, let's just focus on the effects of the changes
… So we'll… we're right now reviewing Steven's updated PR
… We'll then change over and discuss Joe's PR in the next topic. And the discussion on what gets merged first
… Like, let's push that to the end of the call. Just because I feel like we all need to be on the same page about the level of change and what each of them is attempting to do before we try to make that decision, and it might be a more informed decision. If we make that at the end of the call, as opposed to
… right now, like, just, you know, kind of based on what knowledge we have. Um, so, just my own suggestion here, um… And I see Manuel is next
Manu Sporny: Um, right, so, uh… High-level comment first. Um...
… I think we have been through
… uh, the path service PR multiple times now, and have whittled it down and down and down to… Um, to
… Uh, be a better version of what the spec says, uh, today
… Uh, I don't… I am not… so, Joe, I heard you say a bunch of things. I was trying to… some of what you said, I don't think is actually reflective of what the text actually says right now, so some of the things where you're like, it doesn't do this, or it doesn't do that. I don't, like
… I'm concerned that you're working with an old version of what the algorithm does. Um, I went through this
… You know, with fine-tooth comb with Steven to see if that we're addressing, you know, everyone's concerns, including yours
… I believe that we are, so I… at this point, I think the working group needs to hear the concrete
… technical thing that, uh, this PR, uh, does not allow. Because the things I heard you say, the PR allows you to do those things, so I don't… I think there's a gap in understanding here
… Okay, so… so I want us to focus for the path service PR on, um, uh, does it actually, you know, prevent the things that, uh, I think, Joe, you're concerned that it prevents? I don't think it does anymore. I think we've addressed, you know, all of your concerns
… Um, let's try to focus on that, rather than high-level philosophy about how the… how the spec should be structured. Okay, so that's high-level comment one
… High-level comment, too, is I did read through Joe's PR. Um, I think philosophically there's good stuff there. I think we should do, kind of, the reframing
… that Joe has done in his PR. I don't think that they are… work against each other. I think it's true in some kind of, you know, corner case, the things that I'm gonna call corner cases, they might work against each other, but I see them as largely compatible
… Where we would get Steven's technically correct PR in
… and then break it apart and rework it, um, in the way that, uh, high-level philosophically Joe has reworked
… it, making sure that we don't break the algorithm, which I think, you know, I don't have an opinion on whether or not, Joe, your algorithm, you know, breaks things or not, but there are a number of things that I disagree with in that PR
… Right? Um, uh, mostly around ordering and I think it's vague in some places, overly vague in some places in the same way that Stephen mentioned
… Um, okay, so I… I want to understand what
… concretely, uh, this Steven's Path Service PR is going to break
Otto Mora: Okay, uh, let… we'll jump in here...
… Well, you're on mute
Will Abramson: Yeah, sorry. Yeah, I wanted to speak to one thing that I maybe disagree with in Stephen's PR specifically...
… Which is around how it currently handles this service and service type processing
… like, it feels like if I have a did URL, and in that did URL, there is explicitly a query parameter that says service equals X, or service type
… equals Y, then we should be dereferencing that URL
… As defined by the service type identified. And not including. Any other
… Path handling objects that might be defined, but
… it just feels weird to me, like, why would you construct a DID URL that explicitly targets a service type, and then also
… include all these other approaches, so that's all I wanted to say
<Zakim> TallTed, you wanted to say that a URL refers *semantically* to a single resource. Something like "today's complaints" may redirect to `.../2026/03/15.foo` and `.../2026/04/15.foo` in March and April
Otto Mora: Mm-hmm. Okay, uh… Good...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, this will be fairly quick, um...
… Joe, I don't know if this is something that you said in the speed of addressing it now
… Or if it's something that really you mean. Um
… A URL may lead you to two different physical resources
… when you dereference it. If it is written, for instance
… to incorporate a date along the string. If the
… date is today, which changes, it can lead to a different document tomorrow than it did today
… Semantically, it's the same thing, because it's the stuff that's related to today, but
… Literally, it refers to the first or the second's worth of information. That's all
Otto Mora: Mm-hmm...
… Um
<Zakim> JoeAndrieu, you wanted to say the amount of time we've spent arguing a PR is not an argument for accepting it
Otto Mora: Uh, yes, so, uh, we have Joe. Joe, go ahead
Joe Andrieu: Um, yeah, I agree with what you just said, Ted. Um, I didn't mean to say that the...
<manu> +1 to what Ted is saying -- you can have one URL that leads to multiple options.
<manu> no, that's wrong
Joe Andrieu: resource returned is the same every time you evaluate and dereference a URL, but rather that one resource is returned. For any given dereferencing. Um
<manu> https://
Joe Andrieu: I think that's just how it works. Uh, to Manu's comment, I'm actually… I don't… I'm really confused, because I did, in fact, outline very specific technical things that I don't believe this does
<pchampin> a resource is not returned; a representation of the state of the resource is returned
Joe Andrieu: Um, and you just said you don't think I understand the spec, but, um, I think it should be service-as-service type first. I think there are precedence issues. Um, I don't think we should be returning multiple resources, and I think we should have some sort of path handling type that any path handling
… service endpoint can register, or any kind of endpoint. And finally, I think it needs to be able to handle something that's not a service
… That may be in there, that part I'm not sure about, but the other things still seem to survive this conversation, so I'm… I'm
… Confused about that. I also take issue with the idea that because a PR has been argued over for a long time
<manu> No one is saying that, Joe
Joe Andrieu: that we should accelerate the adoption of that PR. The argument itself over this that has taken a long time should be an indicator that we're not there yet
… And, secondly, this PR is brand new. It has not… this PR, with these changes, with these algorithms, with these nuances
… is… is brand new, and I have not had the time to review it. And so
… We need to take the time to understand this algorithm so we can tease out if I'm right or Manu's right about these concerns I have about does it support multiple resources, which I think is bad, does it have a bad precedent?
… Um, does it miss these other opportunities, such as service endpoint… or non-service endpoint-based mechanisms?
… Um, and then finally, Manu, if you have issues with my PR, please make comments on it. That's why we put it out there. I did attempt to respond to everyone's comment who commented on the first round of that. I welcome comments, I'm trying to incorporate those as quickly as possible
… Which is why I have not been able to do a deep dive on what Stephen did this last week. That's my comments
Otto Mora: Mm-hmm. Mm-hmm. And just one more thing, so the concern around the link resources, that's...
… Or do you still have that concern, Joe, or is that
… Okay
Joe Andrieu: Um, I do still have that concern. I haven't read this, and I know that Steven was trying to find a way to make it extensible, and so I don't know if he has managed to cross that gap or not...
Otto Mora: Okay, so just one thing on that, it might be useful, like, um...
<ottomorac> w3c/
Otto Mora: Alex from, uh, Checked did… I just put it in the Zoom, but I also put it here in the IRC
… he did give us a feedback, and I think he was saying that, uh
… The layering is sound because, um
<ottomorac> "Reading the updated §6.4.1 algorithm, Step 8.1: "If the DID Method specifies its own path handling algorithm, use that algorithm, skipping the rest of these steps", is exactly the right design for DLR-implementing DID methods. They define their own path handling and bypass PathService entirely. This confirms the layering is sound."
Otto Mora: Yeah, he posted this bit here, I'll just paste it
… Um, yeah, you can see it there, right?
… it's kind of a layering thing that he said it was fine, so… just for that… for that particular… I mean, I don't know about the rest of your concerns, but just for that one particular part, I think he was fine
Joe Andrieu: Right, so we should clarify, did linked resources is not linked resources...
… And linked resources doesn't use a service property, um, and it is able to deliver a resource that doesn't have an endpoint, doesn't have a URL that you return, which is required
… Uh, property and services. So, I don't
… It's great that Alex likes this, that helps. That was one of the three approaches to path handling that the community has been dealing with
… Um, but I've been mostly speaking to defend the Sean Conway's work at IXO
… Um, because I'm more familiar with it. I understand why they did what they did
Otto Mora: Okay. Perfect. Uh, Steven...
Stephen Curran: So much to respond to. Uh, Will, on your point on the service types and service, if you specify those in a URL, I'm happy to do that...
… Um, I'm… I'm on the fence on that one, so I think that just we make a decision on eliminating everything except the specified service type
… The multiple resource I originally had up until the last revision
… had, um, did it be an error if multiple resources resulted? Um, Manu convinced me that it should be allowed so that you could store a resume on multiple places, and you could get it from multiple places, so that's a
… an issue. Um, Joe, service type and service are the first thing processed
… The only thing in front of it is a did method specific allowing for on-chain resources to be resolved, so both of those things that you. Mentioned there are taken into account. Um
… There are other services included, or other objects included, it's not just services. Um
… and the required property on a service being a URL, it could be a did URL, and that is… is a reasonable endpoint. which is… and exactly what I've used
… Um, or… or consider to be used, so that when you then
… resolve it, it is the first thing you hit, which is, is if the did method
… Has a path handling algorithm, because that's the only place to get it
… it would retrieve it off the ledger in that case. So, I think all of those things you mentioned are handled. So, I look forward to you taking a look at the latest, and. That's… yeah, anyway
… That's it
Otto Mora: Okay. Uh, Manu?...
<manu> https://
Manu Sporny: Uh, on the multiple choices thing, what Steven said, I'll also point out that RFC 7231 allows there to be a response for… that there are multiple choices for a given URL...
… Um, that can vary in representation, but it doesn't have to. So, I… minus 1 to
… uh, you know, they're not being a precedent where a URL can point to multiple other URLs, it's in the… in the core HTTP spec
… Um… I think, uh, Steven has responded to… well, one, I'm having a very hard time tracking what the concrete concerns are
… I would like a 1, 2, 3, 4, these are Joe's concerns, so that we can address them one by one. Otherwise, this is going to be a random walk through
… a set of shifting concerns. Um… I… I believe I heard Steven respond to
… hopefully all of your concerns, or at least a subset, Joe, so I would like to understand at this point
… which one of those are left? What of the concerns are left?
Otto Mora: Okay, and then...
… Yeah, I just want to, like, cap it at 5 more minutes, and then we should switch to those PR, because I also want to make sure that the group
<Zakim> JoeAndrieu, you wanted to point out that dismissing my concerns because Manu disagrees doesn't address my concern.
Otto Mora: gets to see the changes proposed by Joe. So, Joe, like, uh, yeah, go ahead
Joe Andrieu: Um, yeah, Manu, I think we've just done that twice now, so I'm getting extremely frustrated with what feels like abuse of process to keep demanding that I say something that I've already said...
… It's extremely frustrating. I have enumerated this list. The fact that Steven has dismissed one of my concerns, because you agree with him on it, does not address my concern
… And so, my concerns have not been addressed many times throughout this process, and that is a dialogue about how we move forward
… And I have been putting issues on the repo, I have stated here, a list here, and for some reason, that doesn't meet your standard, because I don't know why
… But I don't think it's a fair engagement the way that you are treating my concerns about this PR
Otto Mora: Uh, Steven, uh, Manu, and then I think let's just close off. Conversation...
Stephen Curran: I'd like to move on, I think, um...
… Joe, you raised a bunch of concerns. I think all of them are addressed, so hopefully we can just move on from now and see what happens
<JoeAndrieu> I will list my concerns in the PR when I can get to that
Otto Mora: And yeah, I think maybe then this also be a topic of… a special topic called the… Uh, yes, madam...
Manu Sporny: Yeah, just to try and clarify, Joe, I am not dismissing your concerns...
… Uh, I have… I have tried to listen, I have read, I tried to read absolutely everything that you've written, I have tried to convey it to Steven so that he, you know, adjusts the text
… Steven has been receptive to that, and has modified text over and over again, based on me going, I think this is what Joe wants. I think… and I think he has a point. I think we need to change it in this way. That has been going on for weeks
… So… we are listening to you, Joe, we are making modifications
… It is still really hard to track what you are disagreeing with. You said there was something that he is dismissing, but you didn't say what that was, and so I'm trying to understand. We are really trying… We… please?
Joe Andrieu: Manuel, I have to interrupt, I've said it now twice, you just didn't like what I said...
Manu Sporny: What? No, I don't know what you said, Joe. I literally… I don't… in my...
… That's not what I'm saying
Joe Andrieu: Look at the transcript, Manu, I iterated 3 things that I felt I was concerned about, and you're saying I'm not saying anything. You are misrepresenting what… how I am contributing...
Stephen Curran: What...
Otto Mora: Okay, okay, so, so, folks, we're really not gonna get...
… this discussion sorted out. Uh, let's… let's, uh, just move on. There will be time
DID URL Dereferencing PR \[3\] (20 min)
<ottomorac> w3c/
Otto Mora: this week to review this PR, and we will arrive at a special topic call with hopefully more concrete
… Concerns about what the changes required are, okay? And then we'll just move on
Will Abramson: Yeah, I just wanted to say that's one thing, too, Otto. Maybe, Joe, if you can take, I don't know...
… 10-15 minutes to just write up 1, 2, 3 on the ish… on the PR. I think that would be really helpful
Joe Andrieu: Yeah, I'm happy to do that...
Will Abramson: I'm sure we could do that. Yeah, great, thanks...
Otto Mora: Okay. So...
<swcurran> Joe What is the specific item that you said was dismissed -- the multiple resources? I've just lost track.
Otto Mora: Yeah, in the interest of time as well, like, yeah, I just want to give Joe time to present his change as well, because I think it is important as well that we understand it
… Um… so, Joe, please go ahead. You can highlight the changes if you like, uh, by screen sharing, or if you want to just tell us what the key changes are, that's fine too
Joe Andrieu: Sure, let me… let me speak to it first. There… there are two main changes...
… One is that I refactored the algorithm so that it was easier to understand
… Um, I had a very hard time understanding the existing algorithm when trying to contribute to Steven's work on the path handling algorithm
… Um, it was nearly impossible, with the way it was structured, to separate dereferencing from resolution
… Um, and it connected for me with, oh, maybe this is why Jeffrey Raskin thinks that it's confusing how we talk about dereferencing and resolution
… Um, so that was a start, and I started with the threat, uh
… the threat modeling exercise to socialize, here's a version of what I think the algorithm is, and people seem to buy into that. And so, that was the first write-up, is to say, hey
… Can we get this opening to express this different algorithm?
… Um, I guess there's a third thing, which is just the introduction that frames this issue about dereferencing, because the other big change, and this is a huge change, and I do apologize that it is… it is
… Um, it is substantial, which is to say, I got rid of this idea of a
… uh, software API and an interface for a dereferencer
… Because I think that is fundamentally a confusing concept, given how the rest of computer science and the web
… talks about and means dereferencing. So, I think what we need, um, is for
… A, uh, to describe how a client of the resolution process prepares, calls, and then
… deals with the response to resolution. I think because our URLs are different than other URLs, I think it's important
… To have that sort of distinction of what is the dereferencing algorithm. Um, but if we
… introduce in the… as we do in the current text, if we introduce this new object that is itself a dereferencer, then we have this underspecified thing that's a client
… which is calling the dereferencer. And so now we have 3 objects in our system, which we have to threat model, and which we have to explicitly define, and we don't have that client defined. It's not a conformant requirement
… Um, and I think there are some opportunities lost there because of that structuring. In particular, we don't have the spec anywhere that requires that the user is able to choose the resolver
… for particular DID methods. And I think that is a huge security flaw in the current approach
… Um, and I think where we would put that, I think, would be in the client component of the current spec
… But there isn't a client component of the current spec. There's a couple of lines in the current spec about, um, dealing with dereferencing a fragment, and that's something that this client software, which is otherwise underspecified
… Um, does. So those… those are the… the two big changes, is this effort to
… To get rid of this complex piece of additional software that isn't really how most of the rest of the web deals with dereferencing
… Um, and to clarify the algorithm, um, so that it was easier to understand from a first read
Otto Mora: Mm-hmm...
Joe Andrieu: And I'm open to all sorts of suggestions on how to clean that up. I'm actually very interested, Manny, in the criticisms you have of it, because if you think I got it wrong, I want to try and fix it...
Otto Mora: Okay...
… So those are the high-level changes. Uh… okay, I see Steven first. Steven?
Stephen Curran: I… I like...
… I think the client needs to be there. I don't think it should be
… in the middle of processing, so I would… would prefer to see. that
… It is that… that the client passes in
… a div URL
… That goes through a sequence of steps
… And returns a result
… And the client then does some processing on that result
… Um, I would prefer to see that style of piece, and then
… That logical piece of software
… It has to first retrieve a DID doc, and that may require the use of
… parameters, and so on. And then
… based on the remainder of the URL. do additional processing
… And then pass the result back to the client, and the client then
… May still do further processing, such as processing the fragment. I think that model
Otto Mora: Hmm...
Stephen Curran: works. Um, and so does it require two separate algorithms? Requires a single algorithm?...
… Um, where, obviously, the early part of the process is to find the appropriate DIDO to be dealt with, and the second part to be
… handle everything else that's on the URL that hasn't been
… Um, used in finding the… finding the object. So that's kind of how I would like to see it
… Doctor, I'm reading through yours today, I thought
… The thing that threw me was the client sort of in the middle of the process
… As if it was sort of multiple calls in and out of whatever's doing the resolution and dereferencing. That's it
Otto Mora: Okay, so just to get a range, so did URL...
… set of steps to… to process that. There's a result. That can then be shared with the client
… Did document, and then final, um
… Pass back to the client with any additional processing on the fragment that. Might be done by the client itself, is that right?
Stephen Curran: The only thing… the only thing you added there was the did doc. The did doc...
… Doesn't necessarily go back to the calling client if they didn't want it
Otto Mora: Okay...
Stephen Curran: That… but, I mean, that I'd be willing to talk about, is did we always also pass back the doc, but I… again, now you're starting to get into passing multiple things back, which gets complicated...
Otto Mora: Mm-hmm...
<Zakim> JoeAndrieu, you wanted to agree. Dereferencing should start off the specification rather than resolution
Stephen Curran: I'm not quite sure how you would handle that...
Otto Mora: Okay, thank you. Uh, Joe...
Joe Andrieu: Um, yeah, it's interesting. The way you described it is how I would describe the current algorithm. Um...
… The first PR, I, in fact, reorganized the document so that it was clear that dereferencing is the
… Starting, or the outer algorithm, and that resolution is an algorithm that happens in the middle of that
… Um, but that made it look like I rewrote everything because of the diffs. So, I put a little note in here that says, hey, I think dereferencing specifications should kick off this spec
… Um, but… so, in the order of the spec is not the order of the algorithm. And I believe the algorithm, uh, is exactly as you just described
… It's like, you are preparing for resolution, you are performing resolution, and getting a DID document, that's
… That's one pushback I'd have on what you just said. Resolution must return a did document, and so that algorithm needs to be defined in a way that
… um, honors that contract that we have with did method creators. Um, and I think the work is figuring out, well, how does the client do that? Like, how do they prepare and call resolution, and then what do they do with the response? And I think that is the outline you'll see in the dereferencing algorithm
… That's it
Otto Mora: Mm-hmm. So, I guess, did URL goes to either dereferencing or resolution?...
… Uh, initially, and then… and then just different results get… Sure
Joe Andrieu: No, no. The… what you do with a URL is you dereference it to bring it in the current context so that...
<swcurran> Absoluttely a DIDDoc must be resolved -- just a question of whether it is the result to the client
Joe Andrieu: Um, either the browser can display it, or you can pull it into a JavaScript process and use the data that came back from that
… Um, so dereferencing is the root action that you have a URL, you want to use it. First thing you do is you dereference it so you can get the reference that it is pointing to
… and then you can do something with it. So resolution is entirely a subset of dereferencing
… Um, and it's not that someone gets to choose one or the other at the beginning, um
… you are fundamentally dereferencing that did URL. Um, that's the reason you are calling resolution, is to. Get through that, the referencing process
Otto Mora: Okay, got it. So they… yeah, the referencing filter first, the pointer resource, then...
<ottomorac> Wip
Otto Mora: If it is indeed something to be resolved, then resolution applies. Okay. Thank you. Um… Uh, yes, Will
Will Abramson: Yeah, I don't know if Joe will like this, but I wondered about...
… like, is there a way that we can, um, apply some of these changes, like, that are smaller, right? Like, it feels like one of the main changes that I've seen you propose, Joe, which I think everyone is on board with
… is instead… for did resolution, right, we should pass in a did URL
… Uh, and probably the URL dereferencing algorithm could… should come first
<manu> I'm not on board with that :)
Will Abramson: I feel like people are on board with that, like, is there a smaller PR that could do that rearranging, maybe update the introduction like you proposed?
… And then there's a separate PR that is really about fixing or, you know, improving, refactoring
… that did URL dereferencing algorithm. Uh, another thing that I think it
… people are agreed with, but I'd like to hear that, if this is the case
… you, Joe, are proposing that dereferencing happens on the client, right? Like, so the client is dereferencing this URL. The first thing the client does is they call the resolver to get back the resolution result, which contains
… The did document. And then the client applies the dereferencing algorithm to that result
… And that would mean the change that I think is also in this PR is getting rid of the HTTPS binding for Dig URLD referencing
… I think people are… are okay with that, right? So it feels like there's… there's some bits of this PR that everybody is on board with that would be great to get into the spec
… sooner than later. And then there is a more contentious bit, which is about how we restructure the digital dereferencing algorithm. I guess I'd be interesting to hear if you think. These could be decomposed, or… no
Otto Mora: Yes...
… And… uh… Steven
… Oh, sorry, what's up? Let me see… look at this queue again. Uh, Manuel
Manu Sporny: Uh, yeah, so let me kind of point out the things I like about the PR. Um, I like the fact that it is breaking apart things that were previously together, right? Uh, I don't think we should have just one long algorithm, uh, you know, to do any one of the things that we're doing. So, plus one...
… For separating, kind of, the read resolution part from the dereferencing part
… I think that's a good change. Uh, I think it's a good change to remove the HTTP binding
… Like, I don't think we… we need that. Um… uh
… Okay, so those… and then the rewording, Joe's also… Joe is always very careful about, you know, making sure that we're using the right phrasing and wording throughout. I think there are a number of positive
… you know, changes there. There are other things that I didn't quite like. I don't know if it's in this rev, but there was some dead user
… you know, language there that I felt we were… we were creating new terminology that we didn't necessarily need to create. Um, okay, so going into the things that, you know, I don't quite like. Um, uh
… I think this stuff… the concepts can be introduced in a variety of different orders. I don't think that there is one right way to do it
… Right, so I reject the notion that we have to start with talking about, did URL dereferencing, and… and that is the… that is the entry point
… No, that we don't… that is not… that doesn't need to be the way that we explain it. I agree that it could be explained in that way, but I think explaining it in other ways is totally legitimate as well, like talking about, you know, the did resolution process, the thing that you get a DID document back from
… you can pass a did URL into that. It's totally… it's… that's a totally legitimate thing to do, right? Um, and if we want to talk about dereferencing completely separately, we can say dereferencing also takes a did URL
… in. It will call the resolution, you know, algorithm to get the did document and figure out what it needs to do, and then it'll do a whole bunch of other stuff, right? I'm not saying that we explain it in that way, that is certainly the way I have it modeled in my head
… Um, but I don't think there is one right way to… way to, you know, go through this and explain it. I think, you know, Jeff Free's comments can be, you know, explained in a variety of different ways, so
… Um, so coming at it, saying, did URLD referencing is the entry point, that is where we start, I don't think is… I don't think is
… it feels very weird to me. Not weird to the point that I'm going to object to the spec going forward in that path, but it's just kind of like
… That is definitely not the mental model I've ever had around, you know, dead resolution. Um
… Okay, uh, but going back to the good parts of this, uh, I think, uh, you know, teasing these things out and removing the HTTP binding are good things to do
… fundamentally, I think these are things that we can do during CR, because they do not change the outcome of the implementations
… Like, I don't… I don't see how this… like, I think it's a good, you know, rearranging to make. I do agree that there are probably some algorithmic things that are broken or need to be aligned
… But the fundamental outcome of, like, what does did resolution do, and what, as, you know, me as an implementer, what am I actually implementing, I don't think the end result changes
… Right? You're gonna get a DID document at some, you know, step, or you're gonna get some kind of resource at another step. And, you know, whether we use the algorithm, you know, that Steven has in PathService, or whether we figure out what the gaps are, if there are any
… with Joe's thing is… is kind of, like, implementation detail that's largely opaque. Uh, to the test suite. Um… That's it, for now
Otto Mora: Okay, Steven?...
Stephen Curran: Um, I'm gonna… I would prefer to see one long algorithm...
<ottomorac> Joe will have final word
<manu> I would prefer to NOT see one long algorithm.
Stephen Curran: Um, because I think it makes more sense. I… I do think we need to… I keep bringing up the fact that the spec currently says there's 5. Possible outcomes?
… From, um, dereferencing, or from… from
… the process, and I would really like us to
… Agree or not that these are the possible outcomes, and under what ways they come about
… and I think the one long algorithm leads to that
… The thing that gets returned is a did doc, then that would come out early, because you have to get the did doc first
… The only question is whether… is that the intended result?
<TallTed> One long algorithm might often be decomposable into several internal sub-algorithms...
Stephen Curran: from, uh, from the DID that is… the DID URL that's being processed. And again, I always use DID URL because, again, even if you're just getting the DID, because of version time and version
… ID, it's a did URL, even if the thing you're going to return is a did doc
… Um, I would also like to just add one more thing, which is my PR adds
… detail about how to handle a path, which to me is a very important part of a URL. That's all it does. It doesn't
… it fits in with the rest of it. I don't… you know, it's not fundamentally different, uh, adding anything fundamentally different, except to
… Provide a specification of what you do with a path, which to me is
… Um, is… is missing or way understated in the current spec. That's it
Otto Mora: Mm-hmm. Okay, uh, Joe is gonna have the final word, but I… during the special topic call, we will dedicate equal time to both of these, uh, pull requests...
… And, uh, then some, uh, close-up discussion time to just come to some kind of synthesis and agreement. Uh, so Joe, go ahead
Joe Andrieu: Thanks. Um...
… Uh, so, first of all, I think it would be easy, Steven, to incorporate
<swcurran> +1
Joe Andrieu: um, some version of the algorithm you're trying to define, like, into this PR, and I did not attempt to do that
<swcurran> Agreed
Joe Andrieu: I just tried to capture what was already in the spec with regard to relative ref, and how service parameters are treated
… Um, so I totally agree, this PR did not attempt to address that. Um, I think to your opening question, Will, I think the problem is that the root of this was about confusion between, uh, did resolution and dereferencing, and I don't think
… you know, piecewel changes are going to address that confusion. Um, we could cherry-pick some stuff, but we're not going to address Jeffrey Askins' concerns with that. Um
… I think, you know, to… Manu, I'm not sure why you think I said it had to be a certain way. Um, I said two different things. One is I said, I believe it would be clearer if we started with dereferencing. And one of the reasons I said that is because Steven, who's with us
… just interpreted that dereferencing was in the middle of the algorithm, but it's not. It happens to be in the middle of the document, and I think it's a natural thing that when people scan these documents, that, you know, they think it is going through the algorithm in order, and so I think we should put it in the order that things actually
happen
… The other thing I said is that what you do with the DID URL is you dereference it. This is a
… computer science concept, that that is just the action that happens. Um, the fact that we have not spoken about it that way is also probably why there's confusion in the marketplace
… Uh, and with regard to did URLUser, I'm happy to find a different term. I needed a term in the threat modeling exercise to talk about the individual who has a URL who's interacting with a device to do something with that URL
… Um, happy to figure out another term for it, um, but that was a term that came to mind
… And… and that's it
Otto Mora: Okay. Okay...
… So, uh, Wednesday, uh, the 8th, special topic call
… Yes, go ahead
Joe Andrieu: Wait, I'm sorry, I forgot, I had, um, a couple of other things. Um, I had two index cards, my apologies...
… Um, one is… one of the reasons I'm concerned with, you know, going to CR without
… figuring out which way we're going to go with this, is these are going to be normative changes. So even though it may not affect whether or not, um
… resolution changes, because I don't think there's any real proposed changes to the resolution algorithm
<manu> You can make normative changes in CR, even giant ones.
Joe Andrieu: But we are proposing that there are normative steps that the client of Resolver should go through before and after. Um, and I think also this speaks to that there are not, in my PR, 5 possible outcomes
… Did resolution has one outcome, which is a did document, and then the client does whatever they need to do, which could be a million different things
… They're going to take the result of that, and they are going to interpret in the current context. And in some cases, that will mean validating a proof on a verifiable credential. In other cases, it will mean putting something on the screen and scrolling to the appropriate context
… Um, and then, finally, the reason I think we have to have two algorithms is because people will implement resolvers, um, without implementing the AD referencer or a client
<Wip> +1 definitely
<swcurran> That's what the client does with the result. Not with the dereferencing returns.
Joe Andrieu: And so, if I have a did method, and I know that I need a resolver that supports a particular interface
… I need to have that algorithm clearly defined somewhere so that I can implement that, and it will work with whatever clients are out there, even though I may never implement a client. And that's it, sorry
Otto Mora: Okay. Uh, just one thing here on the timing for next week. So, Will, I see that the meeting is scheduled for...
… 10 to 11 Eastern. It's… this would be effectively set
… 7 Pacific, which might be
… A problem, it wouldn't be
Will Abramson: That's the time it is. Well, we...
Otto Mora: At the moment, it is… It needs to be… it needs to be the same time, right?...
Will Abramson: Yeah, I mean, we could try and find another time, but that's just been the time that we call. We've… been at, it feels like...
… Would be complicated to try and find another time, especially in time for next week
Otto Mora: So it… it needs to be 8am Pacific, right?...
Will Abramson: 7am Pacific is when we have always...
Joe Andrieu: Yeah, why do you...
Otto Mora: Oh, we've always had it. Oh, okay, just making sure...
Joe Andrieu: No, we've always had it at 7. Yeah, it's an annoying time for...
Otto Mora: Okay, okay, okay, sorry, yes...
Joe Andrieu: For some of us, but...
Otto Mora: Okay. Alright, well, then that's it...
Will Abramson: I will say, I think the transcriber bot is a success, right? Like, it's… I mean, I've not noticed, I've not, like, paid too detailed attention, but it seemed to work much better than last month...
<ottomorac> transcriber-bot, pause
Pierre-Antoine Champin: It was much better, yeah...