Meeting minutes
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, connect
Otto Mora: Okay. Okay, thank you...
<ottomorac> transcriber-bot, pause
Agenda Review
<Wip> transcriber-bot, resume
Will Abramson: Let's resume, right?...
… Yeah. Okay, cool. Yeah, so welcome to, uh, today's
… Working Group Special Topic Call
… Today, I mean, really the focus is around trying to get to CR. There are two outstanding PRs that I want us to review and discuss. Uh, I think there are some comments on Marcus… from Marcus on one of them that
… you know, we're gonna need to figure out how do we want to handle that. Uh, I hope to be able to merge them today, but we'll see. And then, if there is time remaining, uh, I think it's best placed to review Joe's outstanding PR and any comments on that from the group around the digital URL dereferencing algorithm
DID Resolution CR Issues
Will Abramson: But yeah, focus today and tomorrow is just going to be how do we get to CR spending as much time as is useful on that. Um… Okay. So, I'm gonna go on
… So
… I mean, CI issue is probably wrong, actually, CRPRs, but
w3c/did-resolution#345
Will Abramson: Let me do the easier one first
… So, 345 is, uh
… A PR from Otto, which addresses issue 341, which was a kind of remaining tag review issue that I think we forgot to, we missed when I was trying to capture them all. So as I was reviewing the tag design issues, this one sort of, I was like, we haven't handled that. And it's really. About… we have this hedgy text that Jeffrey was saying, you
know, this
… This needs to be a bit clearer. Otto's put in a PR that basically just removes the hedgy text and follows the advice of Jeffrey, which is to
… uh… take things out of the notes, and make it normative, I believe
… I don't know if you want to say anything about that
Otto Mora: Yeah, no, you got it. That's essentially what it does...
… Uh, it implements the text change that we had agreed, uh, I think about 2 weeks ago. And, uh
… Yeah, I mean, I see approvals from both, uh, you and Marcus, but, uh, obviously
… Maybe one more approval or a final blessing here would be
Will Abramson: So it's got 2PR, I think Manny's just approved it. Yeah. Great. I mean, okay. So...
… If anyone else has any comments, jump on the queue, but otherwise, I mean, I'm of mind to merge this, maybe I'll do it after the call. um
<JoeAndrieu> looks good
Will Abramson: That's great. We can just move on
… Okay
… Uh, yeah, so actually, just before I move on, the last quick comment on that, I don't think I've heard back from TAG, but I did, um, you know
… review where… tell Type where we're at, and then just recently, I just pinged them and said, look, we have this one remaining issue, uh
… when we merge this, are you happy for us to move to CR? So hopefully they're going to get back to us and say, yes, that's great
… But I think we do need tags or a blessing that their review is complete, right? That's my… Understand
w3c/did-resolution#346
Will Abramson: Okay, well, that's fine. I'm sitting, and I'll
… updated feedback from them. So, okay, let's move on to 346. So 346 is really trying, Otto, again, took this one on, which is great. He's trying to execute the resolution that we passed last week, which was focused on moving DID resolution to CR with DID URL Dereferencing marked at risk
… And when we reviewed this text, really, the editors, like Joe and Stephen, and I think many of you weren't there, actually, but we just looked through the spec and realized there are a few other sections that are, like, heavily
… Did URL dereferencing dependent? I mean, obviously, did URL dereferencing is woven throughout the spec, and I think
… that obvious tag will have to realize that, and I think that's fine, because we have this top statement that says, you know, did URL be referencing?
… feature is at risk, and if we do remove it, we are going to have to do some surgery to the spec
… the… the… oh, that… Sections that we marked as at risk
… that really Marcus is querying are the did resolution architecture section
… And the did URL dereferencing result section. I'd love to hear from people
… what they think, or, like, how do we move past this without just… you know, I don't think we can completely overrule Marcus. I mean, maybe he is right, we didn't have a discussion about what to do with the DID resolution architectures section in the group
… But I really was hoping to get this merged. So yeah, that's tricky
… Yeah
Manu Sporny: Uh, I did a quick, uh, read-through of the sections Marcus is saying we should not mark as at-risk. Uh, they are largely non-normative, though we do have a couple of normative, like, should statements sprinkled throughout...
… Um, which, you know, I don't like, I don't think we should be doing, but… but whatever, right? They're not… I don't think there are any musts, uh, in either section
… Um, and for that reason, I'm fine removing the at-risk issue markers. Um
… Because, you know, whether or not they're marked at risk or not
… If we change did URL dereferencing, there is a chance that those other sections are gonna have to change as well, right? So I don't, you know, I disagree with Marcus saying like we shouldn't mark it as at risk. There's no downside to marking it as at risk
… You know, as at risk, we're just saying, hey, like there, this section might change heavily, um, and people should pay attention to it, um, but if markets is gonna block, uh, you know, us being able to get these, uh, you know, get the CR based on this, then. Find, like, remove the language and, um
… And we, you know, we will have marked the ones that are really, you know, likely to change. as at risk, and we can… we can move on from there. So
<Zakim> JoeAndrieu, you wanted to speak for at risk for resolution architectures
Manu Sporny: Anyway, all that to say, I think it's fine for removing the at-risk markers for the things that, you know, Marcus is objecting to, um, if it gets us into CR
Will Abramson: Yeah, thanks, Manu. I do hear that. It's important to get to CR. Joe?...
Joe Andrieu: Yeah, unfortunately, Manu, I disagree. I'm the one who asked that we put that section at risk. It has language in there that I would formally object to. We define things that violates our fundamental security model...
… I really think we need to, at a minimum, put it at risk
… And we're going to have to talk about those sections if Marcus is going to fight to put them in. But we define things like proxy in your resolver, which is not supported by our security model. We have no consensus mechanisms by which we could secure that architecture. And the presumption is you need to trust your resolver
… And I think the conversation that Marcus wrote was intended to be, these are ways that things can be done, which is true, but they are not things that are part of our recommendation
… And so I think we really do need to keep that section at risk. And I didn't hear Marcus's objection to saying he's going to stop CR. I'm hearing him say he wants us to have a conversation about it
Will Abramson: Yes. I mean, I think that was his main concern. He just saw the spec and didn't realize the exception would get marked at risk. Manu?...
Manu Sporny: Yeah, and, you know, acknowledge Joe, that's, you know, a legitimate concern. I don't think you can, I don't think you can, I mean, you can formally object over anything, right? And you can object over anything, but like objecting over marking something is at risk is a bit...
… I don't
… No, no, no, no, I'm not talking about you, Joe. Yes, I heard you understood fully. I'm talking about Marcus. If Marcus is like, no, I am blocking our transition to CR, at that point, I think you can just override and basically be like, we are just putting an at-risk issue. Marker in here, like… you know
Joe Andrieu: No, I mean, I will object to this content. This is...
Manu Sporny: If you want us to talk more about it, we can talk more about it during CR. If you want us to talk about it right now...
Joe Andrieu: Oh, okay, sorry...
Manu Sporny: You know?...
… what's the point, right? Like… anyway, so I don't… I don't think it's… let's just have a discussion with Marcus tomorrow, hopefully he's on the call
… Um, and if not, let's leave it in there, and, you know, if folks want to object to it, we can say, hey, yeah, when we tried to transition to CR, there was an objection over marking a section as at-risk. And then, you know
… I don't think that… I think the response to that is like, okay, we… like, you know, it's, uh… you can talk about it in CR. It's marked as at-risk. That's it
Will Abramson: Yeah, great. I mean, uh, I think we're all on a similar page. Uh...
… I spoke to Marcus today, actually, and he said he's at this event. I'm hopeful he's going to come tomorrow, but if he's not, I think we just should… I think I take Manu's point that we should move forwards. I mean, I think we could get Marcus on board that this did resolution
… architecture section… I mean, I think I've agreed with Joe, really. This is… this is currently a section that just says, here's different ways that you could do this architecture without any real, um
… thought around the ways in which we want people to do this architecture, right? It's just, here are all the different variations, and there's no, sort of, like
… guidance around which variation is good or bad. And I think my understanding, maybe talking with Joe and some others, is that really this did resolution architecture section can be, I mean, as we mentioned there, right, can hopefully be replaced by the resolution threat model
… which is gonna, sort of, review the architecture, right, like with the DFD diagram, and then have some
… analysis, security analysis over that architecture. And… I mean, I think some of the sections in this architecture section, right, about, uh, I think it's the proxying section, maybe isn't even going to be in there. I'm not sure, I'd be interested to see how that plays out, but
… I think… I think we on the group think that's a bad idea, and we shouldn't be talking about it in… like, in this section, it's just like, here's just one way you could do it, and we don't say whether it's good or bad, or what the risks of doing it are, we just say, you know, you can do it like that if you want. um
… So, yeah, I think I like Manu's suggestion. I mean
… I take Marcus's point, we haven't talked about this as a group, right? So maybe Marcus just feels like it's gone out of nowhere, we should chat about it. I do also see that, you know, just want to get to CR. We think we're all in agreement that this section is going to be under discussion in CR
… I guess pretty, it doesn't matter too much either way. Anyway
Otto Mora: Yeah, I mean, um...
Will Abramson: What's up?...
Otto Mora: Yeah, I mean, I'm just echoing that I understand where Marcus is coming from, but I do agree with Joe's view on this, that...
… It is a
… Uh, something that, you know, is definitely going to be subject to change, and we do want to show. to the outside world, I guess, that we are… You know, kind of taking the work to do the resolution threat model, which is important, so
… Uh, even though, yes, okay, his point, yeah, formally discuss it in the call, okay, fine, but I do agree with Joe's positioning here, I think it is correct. Uh, I guess, yeah, that's it
Will Abramson: Yeah, so I think I'll add maybe just to close unless anyone has anything else. I think we can say now that we are going to discuss this again tomorrow and I will message Marcus to say that, right? But if he can't make the call, I think we should just overrule and leave these...
… sections in. I mean, the other section that we've not talked about is section 10, so maybe we can just briefly discuss that, like
… Uh, again, this is… this is non-norm… I don't think there's any normative statements in here, um, so maybe it's… it's not as important, and we could just get rid of this at-risk marker for now
… I mean, it's obviously entangled with digital URL dereferencing, so it's definitely going to be under discussion in CR
… I mean, maybe, like, you know, if that's the easiest path to just move forward, perhaps we do that
… Joe
Joe Andrieu: Yeah. Two things. One is to correct some notion about normative...
… Any section in here that is not marked as non-normative is normative
… Um, so whether or not it has shoulds or may, this section is normative
… And it would be very easy for a later edit to add a normative thing. So if if we intend for sections to be non normative we need to mark them as non normative
… that might be one step towards including, you know, the resolver architectures as, you know, a compromise direction, if ultimately that's where we went. Um, but this is at risk because it's part of dereferencing. So
… Um, right now, I do not believe we have group consensus, and I think we had a resolution to the effect that, um, we are not going to have a dereferencing function as a call, and this was the result of that function
… So I think this is just all bundled up in, you know, we're still figuring it out and trying to come to terms over what dereferencing is
Will Abramson: Mario?...
Manu Sporny: Yeah, plus one to that. I do think we need to go through and explicitly mark sections as informative or normative. That is, you know, editors typically do that much earlier in the process than this. And what that does is it adds...
… piece of text underneath that section that says this section is informative, uh, and Joe's right. This doesn't have it written as that, and therefore this section is normative, um, even though it does not have any normative, um, statements in it, and also plus one to, like, we have not agreed. that this is, you know, the output here, and so it
should be marked as at risk
Will Abramson: Okay, um...
… Yeah, so… yeah, I was kinda hoping we were gonna get to merge this today, but I think that's not possible, but we can review it again tomorrow, and uh
… You know, hopefully get through this. I hope Marcus is on the call and we can just talk through this. I mean, one of Marcus's pushback is as all, you know, as he's been saying throughout this, for instance, like, there are people who are depending on this did resolution result. He thinks if, I mean, not to put words in his mouth, but I think he
thinks that if we remove this, we're going to harm Interop
… But I think I am more in agreement with the rest of the group, which is, you know, we haven't really agreed this. It's all on discussion. I think we have passed some resolutions which impact this, particularly around HTTPS binding
… I think there is maybe a compromise that we were exploring, but then just didn't quite get to around. Leaving the HVS binding section in as informative. I'm not sure, but I think all of this needs more discussion and that's part of the problem, right? We don't want to have any more discussion. We want to just
… get something that we're happy with, which is just a resolution algorithm. into CR, right? So
… Uh, yeah, I mean, personally, I don't care how often I'm in favor of marking this section at risk and just moving forwards, but I can appreciate that, because it came as a surprise, so… this discussion. Hopefully we can have that tomorrow. Um… Okay
… Uh, any final comments before we move on to Joe's panel?
Otto Mora: No...
DID URL Dereferencing Algorithm
w3c/did-resolution#344
Will Abramson: So it's issue 3, 4, I mean, PR 3, 4, 4, sorry...
… Yeah, I don't know how it's best to go to this. I don't know, Joe, if you have things you want to, like, lead the group through, or we can just go over it. Maybe I can share my screen and we can review the comments. I'm not sure. Or does anybody?
Joe Andrieu: Yeah, I would just… I would just review the comments. I don't… I… Don't have a better way to go through it...
Will Abramson: Good. Uh, excuse me...
… So… this
… You should see my screen, although, also, I'm not looking at the queue, so maybe you could do the queue
Otto Mora: Yeah. Yeah, I got you...
Will Abramson: Yeah, so this is… let me look at the preview, um...
… First, maybe we can just ask, has everybody had a chance to review this algorithm from Joe? Or are there folks who still haven't had a look at the spec text that Joe's proposing yet?
Manu Sporny: I've glanced at it briefly, but have not had a chance to look at it in detail...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): I have definitely not reviewed it, but that's not a blocker...
Will Abramson: Yeah, well, that's fine, but I wonder if maybe it is worth, you know, you just sort of walking through the steps. I mean, I can have a go, but you probably know a bit more intimately than me...
Joe Andrieu: Uh, through the content? Yeah, I could walk… yeah, we could do that. Um...
Will Abramson: It's here, right? Section 365. Oh, it's actually the whole...
Joe Andrieu: Well, go ahead and go up to the first one because those are also edits. Um...
… There was a there was a different style than what I had written before. So and there were some elements missing about prepare for resolution. So those are changes
… For example, and prepare for resolution, we validate
… And that did URL. Then we select a resolver. So that's something that hadn't been in the current documentation. And then remove the fragment. That's currently what we do. Um
Will Abramson: Yeah, so this will have to be updated, right, to be just a DID, I think...
… Yep, yep. Yeah, yeah, yeah
… Right. Yeah, yeah, yeah, sure
Joe Andrieu: Correct. Based on current, like, right, so these have all been things that have happened since IPR. Um, I'll also have to pull in the at-risk markers, right? So there's… there are some just logistical edits that...
… if if if people have easy edits, I'm happy to take them as suggestions. But just yes, I'm aware that those those things need to be updated. But the the main difference in that 1st one is explicitly saying, selecting a resolver is part of that process. Um, but
… And then the second one is you resolve the did by calling, and interpreting the response repeat as necessary. The reason I know there's a comment from, Stephen about why are we repeating? And that's because for some algorithms
… Um, for some DID methods, we know that, in fact, it is an iterative process. Um, DIDBCCR2 is this way. Um
… Because you may not know what data is needed to resolve until you're doing the resolution and you may not know all of it until you go through the entire process. So you have to look at the response and resolve and see if there's a next step or not. And if there is a next step, you have to keep going. Keep going on it
… Um, so
Will Abramson: Yep, great...
Joe Andrieu: happy to get changes to make that clearer if the language is unclear, but I just wanted to speak to the question Steven had, um, even though he's not here, we'll...
… I sort of socialize why that difference is there
… Okay, determined handling strategy. So this was updated to address
… What I think our current consensus might be, there are issues around query parameters, and so I do not include that here. But I embrace the group having a conversation about how do we want to deal with query parameters in the DID URL
… and whether or not they should be how they should affect determining the handling strategy beyond services. So the the 1st one and I wish we could see the diagram. Um
Will Abramson: Uh… Or maybe I can...
Joe Andrieu: I put those in for you, Ted. Uh, you had mentioned how useful that is, and I don't disagree as a requirements guy. I'm like, hey, I've got tools that could make that...
Will Abramson: This one, uh, this one, this one. Uh...
Joe Andrieu: So that's the easy one This is the more complicated one but, there is an effort to try and give a visual explanation of what I'm about to walk through...
Will Abramson: Well, maybe I can...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, I appreciate the effort. I'm just looking at these quickly and noticing contrast definitely needs to be checked with the tool. I'm pretty sure that the top two colors will want white text if they're going to stay those colors. The other thing is these seem to have colors...
… That are meant to be interpreted as something, and that being the only difference, and that's… That cool
Joe Andrieu: They only indicate for the eye to follow that line...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Okay...
Joe Andrieu: There's no semantic difference...
… So I… and I appreciate the accessibility point, and… Let me… yeah, let me see if I can recolor
… They're intended to be pastels, but I agree. We should check it with a tool
Will Abramson: Yep...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): We don't have to hammer on that right now. It's just a thing to have in mind...
Joe Andrieu: Yep, I appreciate that...
Will Abramson: I mean, is it worth going over the algorithm through this diagram, or do you want to go back to the text?...
Joe Andrieu: Sure. This may be easier. So first of all...
… Um we check if there's a service query And if there is, that's what we use. Um so if there's multiple service parameters then that exits to an error
… So we produce some kind of error, and I just have raise errors or the exit for any of these that hit an error
… And then second, as you use a service selection algorithm
… Um
… And that basically says match to the service algorithm that has the same ID as the value of the parameter, right? It's a very simple algorithm. Um, and
… And if that selection algorithm has a handler strategy. Um, then we use it
… If it does not, I created a default service handler strategy, which deserves debate and input
… It was an attempt to say, Hey, we've got a bunch of services out there that didn't realize that they should be defining a handler strategy. Btcr. 2 is one of them. And so if someone attempts to access a service that's in a Btcr. 2. That's really meant to just be a beacon
… and not be dereferenced, well, then what do we do? And I… so we came up with a strategy, we can look at that strategy, and argue about it if we like. Um, but that's… both of those, then, you're done with the service, uh, loop
… So if there isn't a service query parameter, then we look to see if there's a path handler. And that basically means seeing if there are any objects in the did document, and I believe we should include the two metadata documents
… to look, and I think that's what's in the text, um, to see if any of them have a type of path handler. So if they have a type of path handler, they're saying, yes, we are a path handler. Um… And then we use the path value in the path handler
… Um, to pick one of them. Um, and hopefully there's only one. If there are two, that creates an error. Um
… We can talk about that path handling path matching algorithm, but it was designed to hopefully work with how, Steven was thinking about it as well
… If there are no multiples, then does the path handler have a type definition? That would explain how you do the path handling. For example, is it a path handler and a path service? Then you
… would use the past service handling strategy. Um, if it doesn't have a secondary type that explains how you would do the handling. Then, we raise an error
… Um, because we… although we have identified it as a path handler, it didn't identify how you actually do the handling
… But if it does, we set the handler to that and that gets us to the inbox there. Sure. No, no
Will Abramson: Is it a good time? I have a question, but maybe we'll let you go through it all. I don't know what's best...
Joe Andrieu: By all means...
Will Abramson: Yeah, so my question is really… I think it was Steven that raised this in the issues, um… in the comments, rather, and he's saying… so say we go… like, we just… we have a DID URL, but really that DID URL is just a DID, right? We're starting this DID URL...
… did your LD referencing process, and the DID document that's returned from Resolve contains a path handler
Joe Andrieu: Yep...
Will Abramson: uh, like, contains this… a service, for example, with a path handler type. What… what should happen?...
… Right
Joe Andrieu: Um, so there is a path handler. You would use a path handler, path matching algorithm...
… And if there is a path handler that matches on an empty path, you would use that path handler object
Will Abramson: Okay...
Joe Andrieu: To continue, and if that path handler object has a handler strategy. Um, then you would use that...
Will Abramson: Yep. Right, but if there isn't a match...
… it's gonna be an error. Like, what I'm saying is, like, that… in that case, or I think what Steven was really saying, in that case, there is no way for that DID to be referenced to just a DID document
… Doesn't seem like it
Joe Andrieu: Um...
… Yeah, that's an interesting, uh, point, and uh… Actually, in my brain, I had… I stopped
… Going through the algorithm to see if he might be wrong, because the easier solution may simply be to identify where, when we raise an error
… Maybe we should always default back to the did documents path handler
… I mean, uh, handler strategy
Will Abramson: Yeah, so, I mean, in this case, it would be effectively if you don't manage to identify a path handler. Um...
… You would fall back to the document, right?
Joe Andrieu: Right. And that may be the right strategy for all of them. So maybe it's raise error and then go to use default document strategy. Maybe that's a better… Strategy...
Will Abramson: uh...
… Yep
Joe Andrieu: Right now, I'm thinking it is better, like, because what else do you do? You raise an error, and then you end, and then you got...
Will Abramson: Yeah...
Joe Andrieu: um...
Will Abramson: Yeah, I agree, actually, because you're gonna have a DID document when you get here, aren't you. So, yeah...
Joe Andrieu: Right...
Will Abramson: Uh, the other question...
Joe Andrieu: So if you fail any of the fancy dereferencing, I think it probably is appropriate. I want to think through that from a security perspective or unexpected consequences, but it feels right on first blush to me...
Will Abramson: Yeah, the other question I had is this path handling matching? Is… is this… like, say, like… is this, like, the… this is the largest path, right? So, like, say if I… I am just this slash path...
… and then I… there's a path service and slash service, or whatever it is, like, would that just match? Because that's the largest… path, like, it's one, and it's the largest one. I don't know
Joe Andrieu: If, if you had, um...
Will Abramson: It's interesting...
Joe Andrieu: Uh, a URL with a slash as the path, and you had a service operative slash service? Um, in the current algorithm, that would match...
… Um, I'm not sure it should
… Um, but that was my interpretation of… of how I thought Steven was trying to do it. Um, I'm happy to revise if we think there's a… if it shouldn't… if it can't match the whole thing
Will Abramson: Great, thanks...
Joe Andrieu: Um, should it match at all, is a reasonable question. Um...
… I'm pretty sure what, um… Steven was imagining… is that you… in your PATH service, you
Will Abramson: Hmm. Okay...
Joe Andrieu: Um, are saying, hey, uh, this… this token is like a folder. And everything below this folder is accessible via this path service...
… Right, so if you have slash images, and slash images is your path in the service object
… then, you know, pathImages slash avatar.png is legitimate, and it would use that service handler, unless there's a specific override for a path handler whose path is services slash avatar.png. Um, but if it's an incomplete match. Maybe that should not be a match
Will Abramson: We'll have something to think through. um...
… So again, I'm not managing the queue auto, so if there are other people who have comments, otherwise
Joe Andrieu: Okay...
Will Abramson: Uh, Joe, just keep going, I guess...
Otto Mora: Uh, I see Ted. I see Ted in the queue...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Oh, that was old...
Joe Andrieu: Okay...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Sorry...
Otto Mora: I don't know if it was… that was… oh, okay...
… Okay
Joe Andrieu: So those are the two sort of advocated strategies. I want to be clear that the rest is all fallback. Um...
… For then the next two are explicitly for legacy reasons So are there any document properties that define a handling strategy?
… Such as linked resources. And if there are, then you have to process them. And if there are multiple, then we treat that as an error
… That's sad, but I'm not sure how better to do that other than to put it into some sort of matching algorithm, but we don't know what those strategies are matching on. That's sort of the problem with the legacies. We don't know that they have a path property that we could plug into the path. Matching. Um
… But if there are no multiple effective properties, then you use that defined by the property. So if someone has linked resources, then you should go use the linked resources handler. And if you don't know what that is, that's going to be an error. But the handler is. Uh, should be the linked resource handler
Will Abramson: And just to clarify, multiple affecting properties would be like, I have a DID document with, like, linked resources as a property, and linked objects as a property, right? Like, two separate named properties that...
… I know as a dereferencer both affect dereferencing in different ways
… Is that correct?
Joe Andrieu: That's right. And so, you know, if we think about did linked resources and linked resources...
… Um, this is basically saying, if you mix them, we're gonna error out. Because
… Those two features were independently developed, and it's… it's not clear to me even today which one you would… Try to apply
… I mean, theoretically, you would do some sort of
… Uh… secondary salience question
… For example, with linked resources. We do have a path property. So you could say, hey, if that path matches. That's part of the algorithm. Um
… But I don't know an easy way to bubble that up. Um
… And I don't know for linked resources if it has a similar anchor. In other words, is there a way in did link resources to say, hey I do have a did link resource object but does it apply to this did URL? I don't know if anyone can speak to that
… Um
… But we could potentially put into this algorithm that the
… We are actually, if we find properties, we then check to see if those properties apply. Then we do the test on multiple affecting properties
… Because at least with linked resources, you can know if it applies or not
… So I think that is a constructive addition to this
… So a simple step in there between those two yellow diamonds, that is, add a check for saliency. And I might try and find better language when we write that up. But hopefully that's clear to the group that we're talking with right now
… All right, moving on to the green. Metadata properties. Is checked after did document properties. If the group
… So, we could merge this with the one above it, and say, find any properties in the documents metadocu… metadata and treat them as a single bundle
Will Abramson: Right, because at the moment, this is kind of having a hierarchy, a little bit...
Joe Andrieu: I guess edit...
… That's right. And what was important to me was to have a hierarchy. Um
Will Abramson: Yep...
Joe Andrieu: But I don't...
… I don't know that that's a distinction. Like, I do… I very much want service
… to be a get out of this process. mechanism
Otto Mora: Mm-hmm...
Joe Andrieu: Uh...
Otto Mora: I do see Manuel on the queue...
Joe Andrieu: But I'm curious if people agree that we want to elevate the document properties above metadata document properties. Or should we revise this to put those together? Because they're basically both the same. Um, you know… You've got some properties. Um… do we have multiple properties? Then either use the handler if we have a single
property, or we use… or we do an error...
Manu Sporny: Yeah, just because you asked for an opinion, Joe. It does feel like...
Will Abramson: Yeah, that's interesting...
Manu Sporny: the DID method specific handling strategy might need to take, at least to me, gut says it's more important than the metadata-based one, but I could easily see someone, you know, arguing the opposite...
Joe Andrieu: Oh, interesting. The blue one that I haven't gotten to yet, you think should go before...
Manu Sporny: Yeah, because, I mean, like, it feels like metadata is just stuffing the handling strategy into the kind of, like, you know, deepest, darkest hole in all the choices...
<ottomorac> +1 to the diagram being very helpful
Manu Sporny: Um, but I can see how someone would be like, but no, that's exactly, you know, where it should go, and that's, you know, and, you know, we did that so it doesn't get in the way of anything else. I don't know, there's so many different ways that, you know, this could be done. Um
… I don't think it really matters, so it's not a strong opinion. I mean, the other thing that I was, you know, thinking about… so the diagram's great, thank you very much, Joe, for doing the diagram, thank you, Ted, for suggesting we do it. This is so much clearer than trying to, like, you know, wander through
… tons of text. It's much easier to get a mental model on what's going on with this
… Um, I do have a question on, like, you know, which parts of this, Joe, do you think Marcus or Steven would disagree with? Um, I know we've got a lot of comments to kind of take a look at there. Um, the other concern I have is, you know, folks from the TAG, you know, maybe they look at this and they're like, this is really complicated. Like,
can't you make it simpler?
… And I think the response to that is, like, we are documenting reality. We would all prefer something simpler than this, but this is what, you know, the hundreds of DID methods that have been registered, you know, taking a survey from all of them, this is what we think works for. All of them. Um
… So it's very much the HTML5 based. approach to spec development, which is reflect reality no matter how horrible and ugly it is, versus the XHTML2-based approach, which was try to come up with something that is, you know, fairly theoretically pure, but does not necessarily reflect what's happening out there on the. Uh, on the… on the web.
Um… Just some thoughts. That's it
Joe Andrieu: Let me ask Amanda, you suggested maybe putting the DID method, which is the last one we didn't quite get to, before the green one. Um, yeah...
… So do you like then the hierarchy that separates the did document properties from the metadata document?
… You know, I'm just double checking my bias because, you know, that happens, our own experiences and whatever. This does prioritize linked resources over did linked resources, but that's not my intention
… Um, it also prioritizes the new path handling path service stuff above both of those, right? So I think we are making some priority choices. Um, and I was just looking for some feedback as to whether or not, am I just following my bias, or does that feel like, in fact
Manu Sporny: Don't know if I understood the question. My gut says yes, uh, for the question you asked, but I'm afraid I'm misinterpreting the question you're asking. Yes, ma'am...
Joe Andrieu: You know, going from the more concrete to the more abstract...
… Which is what it feels like to me. Like, there's always did document stuff. Um, did resolution may or may not have interesting things in metadata
Manu Sporny: Mm-hmm, yes...
Joe Andrieu: Um...
… So many processors for dereferencing will never look at the resolution metadata
Manu Sporny: Mm-hmm, yes...
Joe Andrieu: Um, so that's… that's how I came up with the hierarchy. I was just looking for feedback to… to check bi...
Manu Sporny: Yeah, I mean, I feel like, you know, if someone explicitly puts something in the DID document, or they explicitly choose a DID method, a specific DID method, they're expecting...
… those things to take priority, right? Like, I don't know if someone, you know, take two different approaches. If one of them is, like, you're gonna end up using stuff in the, you know, result, you know, metadata
… versus something that someone explicitly put in their DID document, I would expect the person that put that thing explicitly in their DID document would want that thing to take priority over
… Some other, you know, um, things that might be kind of… fairly hidden um
… If that makes sense
Joe Andrieu: Yeah, it does make sense. So a principle of visibility here as a rubric to sort of evaluate. What should we look at first?...
Manu Sporny: That's right, and individual choice, meaning, like, I picked this… me, the human, picked this DID method… may have picked this DID method because I really liked the way it worked, and I have said something very explicit about what I want to happen...
… I don't want something else to, like, come in and, like, override that for some reason
… as the general guiding principle. Like, I mean, there may be good reasons that the metadata overrides or did resolution result
… metadata overrides, you know, what the DID method does, but that, to me, feels backwards. We're trying to create technologies to empower individuals and let the individual state explicitly, this is what I want to happen, and it feels like if something that they don't quite see. comes in and gets in there, they might not like that. I know I
wouldn't… You know, like that
Joe Andrieu: Yeah. Interesting. I I agree. So I like that change...
… I invite folks to chime in if they don't
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Yeah, um...
… Sorry
Joe Andrieu: One note of that, Manu. Sorry, I heard you, Ted, but I wasn't quite done. The, uh...
… There's an interesting sort of attack vector in that… in the current diagram that you just spoke to, Manu, and I want to both speak to it and ameliorate it a little bit, which is that we're trusting a resolver
… To resolve that did method appropriately. So on some level, uh, if we chose a did method, then the resolver should be applying the metadata correctly for that did method. Like, we have to trust them to do that
… Um, but if they were to start putting weird stuff in, then, you know
… Yes, rather, the… the
… Metadata and resolution could be an attack vector
… But I'm ameliorating that because, well, so could the DID document. Like, the resolver themselves could manipulate the whole thing if they were a bad actor. Um
… But it is an interesting challenge. I think the visibility feels like a tighter rubric. Did the users who choose this understand what the consequences were?
… And I'm done. Ted, if you want to chime in
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): Uh, yeah, I don't...
… I don't think that we should be doing that much babysitting of people. If they chose the thing, let's assume that they understood what they were doing about it. We can warn them that they should be careful
… But once they do it, let them see what happens. That said. I'm thinking that this
… This last hop out, did method define a method specific handling strategy? That should be the first out
… And it doesn't matter if there's a path handler if the did method says do this
… For instance
Joe Andrieu: How's the queue? Do we have anyone on the que...
Otto Mora: I see, man. Man. I got Manu after that...
Will Abramson: Thank you, Matt...
Manu Sporny: Yeah, I don't agree with that, Ted. I do understand, I think, the philosophy that goes into that, you know, which I can see, right?...
… I think if we do that, though, we, uh, we, we slip down a bad, like, inconsistency path, meaning, like, I think we really want
… this path handler stuff to be the way people use, you know, paths. And if we get, you know, multiple DID methods, potentially a really popular DID method doing something other than that, we fail to achieve that
… kind of unified path handling strategy, uh, approach. That's… that's the only thing I'm concerned about. You know, if we adopt that approach, Ted, then all of a sudden, this… this unified approach
… could fall apart at any point that there's a popular DID method that decides that they want to do something totally different with paths
… That's it
Joe Andrieu: Um, yeah, my take is largely the same as what you just said, Manu. Is it interop, then be...
Otto Mora: Uh, Joe...
Joe Andrieu: Makes us starting with, uh… if we put the DID method bit first. then...
… uh, we're breaking interop across DID methods. Um, we're inviting a broken interop across DID methods. Um, but I think there's also another interesting challenge, which is that. If I choose a did method, and I have the opportunity to impact the did document
… As we expect, most controllers are going to be able to add things to a DID document independent of which DID method, although we know some DID methods simply that's not possible. So there could also be DID methods that make it procedurally not possible or restrict what you can put in a DID document
… But I could put in a linked resource property or a path service property in my DID document that's a DID WebVH or a DID BTCR or a DID whatever, and that gives me interoperability regardless of which particular identification strategy I want to use
… Um so I think it's really valuable that we have these features in the did document that the the controller of the did document can edit and manage
… Um, and I… I wouldn't like that to take a back seat to the scenario where perhaps someone says, oh, it's… it's a… it's a did checked, uh
… um, method, and I understand they use did-linked resources. And so, they stop looking at any other path handlers, they don't look at leaked resources, they don't look at any other data, they're just going on the presumption that because the checked guys developed did-linked resources hand-in-hand with did-checked
Otto Mora: Uh, Will?...
Joe Andrieu: that that is the method handler for all DID checked, uh, DID URLs...
Will Abramson: Uh, yeah, I just wanted to say, like, I completely… I mean, I guess tear hat on off, but I completely agree with what Joe and Manu just said, right? Like, the point… we're talking about the client here who has executed resolution. Like, resolution...
… And the resolver should be the part that handles the DID method-specific stuff, in my view. And they get back this DID document. The DID document should be the point of interoperability that the client has to deal with and handle, in my view. And absolutely, it is right. Like, people
… controllers of DID documents can put whatever they want into that DID document, and obviously, there's some stuff that DID core defines that they expect everybody to be able to understand, and maybe over time, that set of things could grow, but either way
… Like, it is the DID document and the things in there that should be driving, I think, this process. Because the other caveat here is, like, all of this stuff down here, I think, right, like, is legacy stuff
… that really it's not, are there document properties that define a handling strategy? It's, are there document properties that me, as the client, knows to and understands to define a handling strategy, right? So, like, some clients aren't going to understand some properties, and they're just going to ignore them
… And that's fine, but what we do want to have, like, and I think what Path Handler is trying to get to, is most clients will aim to understand Path Handler, and so most
… controllers of DID documents will know that if they want to use a path, a DID URL path, the best way to do that is to include something with a path handler typed in
… That's the direction I think we want to try and get to. Uh, so yeah
Otto Mora: Uh, Steven?...
Stephen Curran: Um, the only thing I, you know, I've said this a couple of times in the past, and I'm concerned about it, I think that...
… If you use the did checked as an example and the resource is on the ledger of did checked. So I realized links resources can work across or did link resources can work across
… methods, and they give examples of that in the spec of a did web that references a did linked resource that thought check. My concern is that if we don't put it a little higher up in the in this flow chart
… you get in an infinite loop. You have no way of actually resolving a
… a chain-based resource like the checked offers. Maybe that's okay, and we leave it to them to figure out what the out is, but I think if you walk through this process
… with an actual example of a DID-linked resource that is pointing to, that is referencing. Hey. An on-chain resource. Um, which is what
… checked was after you get an infinite loop here, and and you never get to the resource. So that's that's my only concern of of
… the method specific handling. But if if we don't, if we ignore that, I think it's not the end of the world. I'm just raising that
Otto Mora: Joe?...
Joe Andrieu: So I think there's a misinterpretation somewhere, Steven. I don't know if we're talking past each other or one or other of us has misunderstanding. But to my analysis of this flow with the linked resources, if there's no path handler, no service, right? So we fall through to the green, check the metadata...
… Um, we're gonna see a DID-linked resource, and we're gonna use a DID-linked resource handler, which knows how to talk to the checked
… Um, chain. And we're done. That resource handler doesn't give you another DID
… It that handler says, hey, here's how you handle a did link resource, which happens to talk to, check
<ottomorac> q>
Stephen Curran: Okay, if you're comfortable that that couldn't get you there, that's fine. That's what I was raising. If you're comfortable with that, that's fine...
Will Abramson: Um...
… Okay, I mean, I see we're kind of getting to time. Uh, I mean, I think this is really useful to just review it. Steven, I think you maybe came in a little late to get the start. We did briefly touch on, uh, your
… uh, question about what happens when it's, like, a… just a DID of the DID URL, and, like, how does it fall through
… Uh, one idea we floated, we didn't, like, get through it, is that if you get to an error state, maybe that the default is from that error state, you are just returning the DID document
Joe Andrieu: Cool, yeah, I...
Will Abramson: Um, because, right, you have a DID document when you go in here. But anyway, I just wanted to update you on that. I see Joe on the queue, but then I think we can close, uh, and we'll revisit this. Yeah, Joe...
Joe Andrieu: I just had a quick question for Steven, because it came up as we were walking through the algorithm...
… Um, I attempted to write the matching algorithm, uh, aligned with what I understood you were trying to do, but I think I missed an element that came up here, which is… if… if you have the… the path part in the service object is, like, slash images. Um, and the URL is just a slash
… Um, and slash images is the longest one
… Is it your desire that that would hit, or should the whole thing have to hit? And then it's the longest one that in… that has an inclusive hit of the path property, which seems like it's more appropriate, but I happen to write it the other way
Stephen Curran: I couldn't understand that from that description. Sorry. Yes. Okay...
Will Abramson: We can revisit tomorrow. I think it's fine, right?...
Joe Andrieu: Yeah, that's… that's fine. I appreciate it. It was a little too confusing to try and get across in 30 seconds...
Will Abramson: Yeah, so maybe tomorrow, you know, we're going to focus on getting to CRR, then if we have time, we'll revisit this, maybe we can just sort of reorient ourselves in this diagram, and then look at the actual text and the comments against the text, and try and process some of them, make some decisions. Great. Thank you, everybody. See
you tomorrow...
Joe Andrieu: Cool. Thanks...
Otto Mora: Perfect. Thank you...