Meeting minutes
<Wip> https://
<TallTed> "Proposal for discussion" doesn't look like "upcoming vote" to me. I do see the word "vote" in the message.
<ottomorac> transcriber-bot, resume
Otto Mora: Absolutely. Okay...
… Yeah. uh
… Alright, uh, thanks for that, Gracie, I appreciate it, and uh
Agenda
Otto Mora: Check that. We've got, uh… Alright, yeah, I started the transcription. So, yeah, for today, um
… Conversation around the inputs to the debt resolution
… Uh, we also have… Algorithm. The vote on the resolution
… And we've got a conversation around a dip resolution tech review
… Uh, then we've got a PR from Steven
… Is there, um, anything else that anybody… Uh, that we've been discussing yesterday, that we also want to talk about. We want to add?
… Yep
… Okay, perfect
DID Resolution Algorithm Inputs Discussion
Otto Mora: Alright, so… Let me just move to the next topic. So, for this topic
… Yeah, the resolution algorithm inputs. I want to, uh, before we vote on the proposed resolution. uh… first emoted here. And
… So folks have it as a reference. I'll also paste that into… from chat
… But before we go into deep discussion of that, I wanted to yield the floor to Marcus, who had requested, uh, given 15 minutes to discuss. Uh, his take on it. So, Marcus, you wanna go ahead?
Markus Sabadello: Yes, thank you. Can you hear me?...
Otto Mora: Yep...
Markus Sabadello: Okay, then...
… Share my screen now, can you see?
Otto Mora: Uh, just...
Markus Sabadello: as an input...
… I want to start by saying we've had this layering, this kind of separation, forever, basically. We've always had it like this, that we said we have a resolution function that takes a DID as an input, and separate from that, we have a dereferencing function, or
… Okay, so yeah, thanks for the opportunity to present a little bit my thoughts on this. My understanding is that this here is the proposal that we would change the resolution function to take a deed URL instead of a deed as an
… algorithm or whatever that takes a DIT URL as an input. Even in the first versions of the DIT specification we already had something like DIT URLs, we called them DIT references back then and the DIT documents were called DDOs. But we've always said that the input to resolution is the deed and plus options and nothing else
… I don't remember this proposal or this topic ever having come up in the past. I think this is the first time this idea comes up that the input to resolution would be a DTRL rather than a DIT. I also asked this explicitly when this working group started in 2024, we went over the specification
… And this has never come up before, or at least I don't remember. So I think it's a very problematic change
… We've been telling all the DEED method authors that the method specifications must specify how a DEED resolves to a DEED document. So I think this change would potentially impact a lot of existing DEED methods
… we've had… we have this separation, basically, at the core of everything we do, right? I mean, look at what our
… specification is called. It's called deed resolution. The subtitle is about resolving deeds. The abstract says that we take a deed as an input. The charter says that we resolve deeds and dereference deed URLs. So this. Um, as far as I know, other standards, uh, build on top of this in… This layering, in my mind, has always been very
fundamental to the entire architecture. We resolve DIDs and we dereference DID URLs
… the European Standards Body in ISO. Otto knows this better than me, but I think there are other standards that build on
… on this basic idea that we take a deed as an input plus options and we get a deed document out of it. I would argue that a lot of infrastructure, a lot of projects that are being built on top of deeds don't even know about deed URLs or don't
… I don't care much about path and query. So the idea of
… of not just resolving a deed to a deed document and having an entire deed URL potentially as input to deed resolution, I think would also affect a lot of other standardization efforts
… Um, is this a breaking change? So, we've talked about this in previous calls, some people have said that this is not a breaking change. Now, I know that, theoretically, we can make breaking changes, so I understand that the deed resolution specification is not final, and I know about the class 1 and 2 and 3
… A TT is a TTRL, so it's true that, for example, in this first
… changes, so I'm not saying that we're not allowed to make breaking changes, but I want to try to argue that this would be a breaking change. So, it's true that
… diagram, if you have a DIT 1.0 conformant client that calls a DIT 1.1 resolver, assuming that we make this change, things would still work in the sense that you can still send a DIT and get back a
… a DID document, so that would still work, but some other things would, uh, would break, right? So a DID 1.0 client, if they send a DID URL, they would expect an invalid DID error, but instead, with this proposed change, they would be getting a DID document
… And in some cases, instead of getting an invalid DID error, they would get an invalid DID URL error, right? So there's some
… I think changes that breaking changes like that
… if we turn this around, and we… in the future, we have DID 1.1 clients, after we make this change, after we say the input to DID resolution is a DID URL
… And we have a DID 1.1 client talking to a DID 1.0 resolver. If we still… if we just send a DID, then yes, nothing breaks, we'll continue to work
… But a DIT 1.1 client may in the future send a DIT URL with a path and a query
… to a DID 1.0 resolver, which may not have been upgraded yet, and then this will break, right? Because the resolver will return an invalid DID error, whereas the client would actually. expect at the document
… So, and I've tried this with several existing implementations, and they all return errors. The existing implementations, they don't know how to handle DTRLs in a resolver
… uh, the W3C test suite also, right? So some of the existing tests in the, in the W3C test suite, um
… would break in the sense that previously conformant results would not be conformant anymore
… There are many other parts of the specification that build on the assumption that the resolver takes a bit as an input
… For example, we say the… Value of the ID property must be equal to the deed that was resolved
… the ID property in the DID document must match the DID that's being resolved. If we say that what we're resolving is a DID URL, not just a DID, then some of these things would have… Some would require updates or some unknown implications potentially
… We'd have to think about what this means for things like also known as and canonical ID and equivalent ID
… like, the DTRL that we are sending as an input, would that be an identifier for the DT document? How would that relate to the subject? Things like that
… example, I don't want to spend too much time, but if we look at the DTRL. I think the change would lead to some ambiguity, um, it's a bit more of a complicated
… that, uh, that uses the DEET linked resources stuff, then
… the inputs for… Resource, but if we make that change… at the moment, the way things are now, it's clear that the DID alone would be resolved to a DID document, and the DID URL would be the reference to an image
… resolution and dereferencing would be… would be the same, and in… in my mind, I think there would be some cases where you… if you pass the same string, the same DDRL
… to the resolve function, you would get a D document, but if you pass the same DTURL
… to the dereferencing algorithm, you get an image resource. I think this could have some problematic implications, for example, for the HTTPS binding. If you pass… if you
… resolve or dereference this DTRL, what would you get, right? Depending on whether it's resolution or dereferencing, you wouldn't necessarily be able to tell which one it is, because the inputs. The function signature would be… Would be the same
… I think it would have potential privacy implications if we're sending unnecessary information to a resolver, right? So we would be
… sending the entire DT URL including a path
… to a resolver, and at the same time, I think we would say that the path
… would be irrelevant for the resolution process. The path would be used for the dereferencing algorithm, but would be irrelevant for the resolution process, so we would be sending information
… to the resolver that we would say the resolver must not use
… And I think this is problematic for a number of reasons. Um, I think some people would, uh… would actually mistakenly, or… Or for whatever reason
… might start to use the path and return different D documents, depending on what's in the DTRL
… Which I think we would not want. I think some people might, by mistake, even send the fragment, if we say that the resolver receives the entire TTRL
… And I think it would lead to tracking. I think this —
… In the identity community, there's been some effort to try and prevent phone home, right? Don't phone home. Um… architectures this is this is the opposite this is a please phone home please send more information to a resolver that can track you that it doesn't actually need
… heard a lot of explanations for why this change should be made. To be honest, most of the
… explanations didn't… didn't make much sense to me, most of the explanations I've heard. In my mind, we're not really a reason for
… confused deputy attack argument that if we
… dereference at the URL, and we have the parameters, and also… making that change. I'm spending too much time on it. The one thing that I understood was the
… options that that could lead to a resolver being called with
… options that were originally parameters. And so there's this whole discussion that a resolver
… Must be able to distinguish what was originally a parameter
… And what is passed as options, which at the moment, in the current design
… it's true that this is not preserved, right, in the… I have examples here in the current design
… If you have start with the deed URL, then the parameters get turned into options. And if you start with the deed plus options, then those options are also options. So it ends up looking the same. The resolver and the current design cannot be changed
… to make this change. I think there are a number of other things that… That can be done
… Maybe we should just, uh, warn about this in the security considerations. tell whether something was originally an option or a parameter, so I understand that part, but I don't think it's a good enough reason to
… Maybe we should change the algorithm to say that did parameters should just not be passed to the resolver, or only known did parameters should be passed to the resolver
… passed to the resolver as additional options. We could have some certain syntax to differentiate what was… what comes from an potentially untrusted DTRL and what is passed. Uh, by a client as options. So I think the number of. Or, uh, in the resolution options, we could even indicate which options are really options from the client, and which
options were originally parameters from a deep URL that could be
… of solutions to these security problems, and I think, for the reasons I mentioned, changing the input to the DID resolution function to DDRL
… would really be a big mistake. I would not implement it, and to be honest
… I think even if we make the change, most implementers, I think, will ignore it. I think it will be a little bit like
… The abstract data model that we had in the past that made some sense, but nobody really. really implemented it
… So that's it. Thank you for the time
Otto Mora: Okay. Uh, and, and is this, uh, uh, presentation, uh, Marcus, uh...
… Is it uploaded somewhere, or are you gonna… or maybe send it to the mailing list or anything? You just wanna… See if there's
Markus Sabadello: Uh, not, uh, not yet, but I can, I can upload it, of course, yeah, I can upload...
Dmitri Zagidulin: Thanks, Marcus...
… Um, Mike, I just have one question about the, sort of, trust model, uh, in your presentation, about the phone home part
Otto Mora: Or just to have it somewhere that we can reference it after. I think that would be useful for the record. Uh, okay, so let's see. I see Dimitri first in the queue...
Dmitri Zagidulin: Yes...
… So, so my impression was that the resolver
… Is part of the client's trusted infrastructure
… Right, so it's not part of the… like
… You can't phone home to the resolver in the same way you can't for… the client can phone home to itself
… Different mental model with it. It's within its trust boundaries, its trust zone. I was curious if you have a different security model in mind
Markus Sabadello: Well, sometimes it is, and sometimes it isn't. Of course, it's preferred to have a resolver to be a local thing, but...
… Sometimes it is, it is not. Um, sometimes people use remote, uh, services as, as resolvers and, and I mean, we. We, we said that
… Resolution is also what individual bid methods
… implement. So, remember, at some point, we merged the resolve function with the read operation. We used to distinguish between a resolve function and the read operation in the bit method, but now… now that's the same thing. So, if we. say that the input to DID resolution is a DID URL, then in my mind, it means that that will also get passed
to
… whatever infrastructure the method uses, so
… And yeah, sometimes resolvers are remote services, sometimes they're not local
<smccown> I think he's saying that a resolver can be used as a surveillance point and the same thing is true of the DNS
Otto Mora: Okay, thank you, and I see Joe...
Joe Andrieu: Yeah. Thanks, Adam. A couple of things...
… I don't think we've collapsed the read and resolve
… If you look at the recent PRs that I've put together, we make it clear that resolve is a call to the resolver, and the resolver then calls the VDR
… And it calls the read function of the VDR. However, that read function needs to happen
… So I think we have been sloppy with this language, but I also think we've been sloppy with DIDs and DID URLs. We often, when we're talking to each other, say, hey, this is something we do with a DID. But the reality is what is very clearly understood is there's a whole DID URL that has parameters and stuff
… So I don't think the long term historical vernacular that we're using should be considered a strong guide as to how we should architect the system
… Uh… Um, but I think, you know, I've talked a lot about the technical complexity here. I appreciate that, um
… The
… So, necessarily, whether
… Privacy angle was interesting here, Marcus, but I agree with Dimitri that we've always said that you have to trust the resolver. Fundamentally, if you think you're relying on Bitcoin, but you're actually calling a resolver that you don't control, then you are relying on that resolver. Either you bring it into your trust boundary and you're
running it or you are by inclusion making that, service provider, a trusted party in the system
… So the path thing was interesting, but I don't think it's as big as a privacy risk as the confused deputy problem that we have when we're conflating parameters. But what I wanna close with, 'cause I think a lot of us have gone around and around about these technical differences
… Is it… it's very clear in the spec that this is a draft document, maybe updated, replaced, or obsoleted, and it's literally inappropriate to cite this document other than as a work in progress. So I fear that may be what you're doing here, Marcus, is you are treating this as something other than a work in progress
… But it is a work in progress. And as we went through the threat modeling exercise and we identified the different components and the workflows between the components, that's when these issues became clear and were brought to the group. So I feel like this is the natural place in the conversation
… Where, having published ADCOR previously in a different charter, we're now figuring out what resolution means. So I think this is absolutely the right place to challenge our assumptions, to make sure that our architecture is correctly described and discussed. And to address any holes that we find in that process
Markus Sabadello: Okay...
Otto Mora: And just one thing, you're saying...
… Even if we make the change to the input
Joe Andrieu: So, I think this is an improvement that will reduce complexity, and will increase interoperability, and I think we should switch to DID URLs instead of DIDs...
Otto Mora: You could still strip out the, uh...
… the parameters out in the… in, like, one of the first early steps in the algorithm, is that right, Joe? Or
Joe Andrieu: I didn't… I'm not sure what I said that may have triggered that. But certainly, if I know that a resolver is not conformant to the current spec, because maybe they're, you know, aligned with Marcus and are refusing to adopt the spec as published...
Otto Mora: Got it...
Joe Andrieu: Then if I want to use that resolver, sure, I'll mangle whatever I have to do on the front end to use that pattern. You could map from one to the other. It's just not going to be interoperable...
Otto Mora: Okay, thanks, Joe. Okay, see, uh, Steve… Steve McCann?...
Steve McCown: Yeah, just a real quick comment. Marcus, I really appreciate your presentation. Thank you for explaining all of your thoughts that way. Um… I'm...
… Generally in in favor of the did URLs, but I did pay particular note to your
… Presentation of the confused deputy attack. I think
… Yeah, of that, that potential problem. We ought to separately address that issue and talk about how it can occur and different things that we can do to help mitigate that to make developers and users aware
… and address it going forward. So I just wanted to point that out, even though I'm still in favor of the did URLs. I think we need to study that problem a little bit and
Otto Mora: Uh, I see… Marcus?...
Markus Sabadello: Yes, I agree with Steve that...
… we should explore this more, and I've… I've outlined a few potential ways to handle that, which I think we haven't discussed at all in the group, and
… We're addressing that, and it should not be
… By itself, a reason, and uh… Changing the input to the DTRL, in my mind, is complete overkill
… talk about Joe's point regarding the interoperability
… Of course, this resolution has always been a draft, and it's not appropriate to cite it
… or use it as a basis for anything stable, and I don't think anyone has done that
… But the inputs to the resolution function were already in the bit 1.0 standard, right? And that has been implemented by many people
… And, uh, that will break, um, so unless everybody upgrades their… their implementations, it will… it will break in the sense that
… If you implemented it… if we make this change, and we implemented it 1.1
… Conformant client
… it will, in some cases, not be able to talk to all the existing OneDid 1.0 infrastructure. That's what we're breaking
Otto Mora: Okay...
… So, okay, we got, uh, Will, and then Manu, and then, yeah, this is, like, the last set of comments before we go ahead and vote. Uh, so, Will?
… That might be a
Will Abramson: Yeah, I just want to throw it...
… I just want to say, with my chair hat on, I think
Otto Mora: Okay...
Will Abramson: we found ourselves in a very unfortunate position, right? We have four and a half months left. I think my biggest concern about...
… Have this discussion, it didn't come up. making this change, it's who is going to take on the work to do all the things that Marcus has just highlighted to make it possible. So that's the only thing I want us to consider. You know, it's unfortunate, as Marcus said, we did
… earlier, but that is the reality that we find ourselves in. We have also spent months now discussing this. Unfortunately, we just need to make a decision and
… move on, even if that's going to be uncomfortable for folks. We really need to
<Zakim> manu, you wanted to note "in favor of didURL" and there are other things that need to be discussed downstream from this.
Will Abramson: Just focus on getting this spec done and wrapping up this group
Otto Mora: Uh, Manu?...
Manu Sporny: Uh, yeah, I mean, uh, plus one to that. Um, I think there is a group of, uh, new editors that have stepped forward to do the work. Um, so I think that addresses, uh, your, um, you know, latter question, uh, Will. Uh, I wanted to highlight that we have been talking about this for months. This is not a new thing...
… Um, it is coming about because we actually do have engagement around, uh, you know, the details of the specification when that was not true, you know, uh, last year at this time
… Um, uh, and, you know, Marcus, you know, did a good job highlighting many of the things that we have talked about, uh, over the last couple of, uh, months. I don't think these are, you know, new, uh, uh, revelations to the group. We understand
… uh, you know, those concerns. We've discussed them at length, um, and agree we just, you know, we need to make a decision here and move on. And it doesn't mean that we're done with this one decision. It's this one decision is going to impact algorithms needing updated and things like that. There are other discussions that we need to have after
it. Uh, but this decision is blocking our ability to
… For a significant number of us, improve the specification in a way that allows us to finish it. That's it
Otto Mora: And one more thing, Manu, there's nothing to say that you're following the previous. But the resolver can connect in...
… Kind of read backwards compatibility and and just understand when one version of the specs being used versus another, perhaps based on the input or anything like that
<ottomorac> PROPOSAL: Modify the DID Resolution algorithm to receive a DID URL and options as input.
Otto Mora: It's possible? Okay, thumbs up. Alright, well, then, uh, yeah
<ottomorac> transcriber-bot, pause
Otto Mora: The proposal is, uh, laid out here
<manu> +1
<markus_sabadello> -1, breaks interoperability with DID 1.0. many implications of this not considered. potential charter violation.
<JoeAndrieu> +1
<smccown> +1
<Wip> +0.5
<pchampin> +0
<TallTed> +0.7
<dmitriz> -0 - i don't like the overall direction of the did resolution algorithm, but non-blocking
<swcurran> +0.75
<ottomorac> +0.7
<danpape> +1
<Wip> transcriber-bot, resume
Markus Sabadello: If it's okay, I don't want to answer that right now, because I'm not sure, but I think that...
<pchampin> my point is: the fact that there is dissent should be recorded, in the text of the resolution
Markus Sabadello: a really big
Will Abramson: Okay, thanks...
Markus Sabadello: it may be a violation of the charter. That's my potential interpretation. So I would have to think about it. I think the consequences are really… a lot of people who are voting may not be aware of all the implications. I think it's even a… it would also be good for the chairs, maybe, to discuss if this...
Otto Mora: Okay, yeah, so I will just, yeah, note that, yeah, we didn't have overwhelming, sorry...
… Absolute consensus, but we did have, uh
RESOLUTION: Modify the DID Resolution algorithm to receive a DID URL and options as input.
Otto Mora: More of a majority, and we noted that
… the same thing, opinion as well, uh, on the record. So, with that, it's resolved, uh, and… I will open to this now
<Zakim> JoeAndrieu, you wanted to mention https://
Otto Mora: I think a few folks… Was it Joe that you wanted to… Yeah, go ahead, Joe
Joe Andrieu: Yeah, I just wanted to give the chair a pointer to the section in the W3C process document that deals with where we're at and what we just did...
… Just take a look at that, that'll give you some background
Otto Mora: Thank you. Mm-hmm...
Joe Andrieu: So, this is part of dealing with dissent, so I think we have appropriately acknowledged that Marcus has a dissenting opinion, um, and the chairs decided to, uh, vote, and there's a section that describes how that works, and so...
Otto Mora: So now the question, I guess my immediate question, which is the next topic...
Who will make the changes to DID Resolution inputs?
Otto Mora: It's, uh… Okay, um
… inputs, right? I mean, is it
… part of the work that Steven was thinking about, or how are we thinking about this? I know Steven's already been… Who would make the changes to the date resolution?
… volunteering a lot of his time, so I don't want to just presume that he would, but… Yeah, uh, I see Joe
Joe Andrieu: Yeah, so a couple of my PRs already have language that we can use for this. I know those PRs are too monolithic to adopt as a whole, but we can certainly mine the language in there...
… And as one of the editors, I'm happy to help with that
Otto Mora: Okay...
… Okay, sounds good. Unless anybody else has any comments on that
… Uh, well
… Go ahead, sorry, you're on mute
Will Abramson: Sorry. I don't like you muting myself. I was just pointing out that we will also need to make changes to this call. I mean, as Marcus showed us, but there are… There are sentences in there that we'll need to change to...
Otto Mora: Phenomenal...
Will Abramson: So probably one of the tasks we'll have to do is just do a thorough review of all of these specs to check the language...
Manu Sporny: I can make any changes to did core if we want to issue. If it's not already raised, we can raise one and then we should...
… point to the resolution made on the call today, and then instruct the editors to update didCore, and I can do so
Otto Mora: Okay. Alright...
Manu Sporny: uh...
Otto Mora: Okay. No one on the queue, and we...
DID Resolution TAG Review
Otto Mora: Okay, uh, next topic is the date resolution tag review
<ottomorac> w3ctag/
Otto Mora: On this one, uh, I know that we have a comment from Lola
… It's here. uh… And, uh
… we wanted to
… see how we best respond to that, so I see, yeah, go ahead, Will
Will Abramson: But the problem is...
… I can't also say, but we still have this… well, I mean, I kind of need to say, we still have this section that needs to be reviewed, but that section isn't done yet. So… I don't know if people have advice for how to… navigate this situation. But… Um
… That's where we are
Otto Mora: Mm-hmm...
… Let's see what it should say. Mano?
… Oh, sorry, no, I thought about it. I was thinking, never mind
Manu Sporny: Comments that you made? Yeah, I think, uh, I think that's fine, Will, just to say that. I mean, you know, the TAG are friendly people, they don't have sharp teeth, um, so we can just give them an update. Are we positive we've responded to all of Jeffrey's...
Will Abramson: Yes, well, what I will do is I'll, like...
… Bye-bye. Itemize them and point to the issues, but
… Right, right
Manu Sporny: Yeah. Yeah, and just… and then just let Lola know that, hey, we're still at it, working on the resolution algorithm, which is one of the things that, you know, Jeffrey mentioned, but we… you know, it kicked off a lot of discussion in the group, and we're rewriting it in the hopes of going beyond...
… You know, what Jeffrey was talking to about getting real, real crisp clarity around what exactly resolving and, you know, resolution and dereferencing means and does, and we will let them know. when that last piece is done, because we'd really like them to review it
Otto Mora: Okay...
Manu Sporny: I think we should just leave it at that, you know, it's not, yeah, and do it sooner than later...
Will Abramson: Yeah, I'll do it tomorrow. Great, that's great. Um, yeah, and then the last thing I'll add is, you know, it's just another flag, but we are in time pressure...
… Because… So hopefully, let's try and get this dereferencing algorithm done in the next month. That would be wonderful
DID Resolution PR review
Otto Mora: Mm-hmm...
… Thank you
… Uh, okay, so the next topic is the debt resolution PR review, including, uh, the conversation from yesterday. So yesterday, we had a special topic call
… Uh, discussing PR335, which was introduced by Steven. Uh
… We talked about the, you know, his proposal text for the algorithm and the various changes
… Then Joe had also raised some concerns about the order of the operations, and
… Really helped me visualize
… what the implications are, I think that's really helpful to do. For those of us that maybe are a bit newer to the spec. Some of the other folks, and then having… kind of… Uh, we had some feedback about the way he had ordered the steps. Uh, I think there was some useful screen sharing we did, which
… and the logic, and I think, uh, Steven
… It helps to follow things, just when you're screen sharing. Um, then we talked about the broader implications of that. I was gonna perhaps rework the PR, but I don't know, Steven, if you had a chance to do that yet or not, but maybe asking you if… It's worth
Stephen Curran: Yeah, so, um...
Otto Mora: reviewing now...
Stephen Curran: Yeah, so what I did, there was… there was conflicts based on previous PRs, so I closed, um, the first one, um, and opened a new one...
… Um, the… Um, Will's gone through it, so I opened it yesterday. Um, Will went through it this morning, um, invited others to
… The changes are listed in the… in the comments, so it, um
… Removes what were the first two steps. Um, narrows it down to just 3 types of things that get… that happen. Um
<ottomorac> w3c/
Stephen Curran: And that happened in the next phase, which is either the resolution doc is returned
… um
… dereferencing of some other resource other than the DID doc, or there's some DID method specific handling
… a an object in either the did doc or did metadata drives the. Um, there's some extra wording to say, you know, like, if you pick a service
… Um, and then it opens… I'll open a can of worms question on… on… at this moment, which is, um
… and there's a path. even though you don't get to the path selection. You're you stop it at at the identification of the service, that service, the processing of that service may involve the path
<ottomorac> https://
Stephen Curran: In the overall processing, there's various stages that we've talked about and the algorithm describes various stages. And one of the things that comes up is that at the different stages. The
… Um, elements of the DID URL, the parameters in the path, get used
… And what becomes tricky is, and probably is a security risk, is the fact that
… Those stages are kind of invisible to one another. And so there is no global picture of what parameters are actually processed and which ones, if any, are ignored
… And and that is, is kind of interesting and something that I think we need to talk about and figure out. So I'm trying to figure out how best to do that
… Um… Will had proposed, um, some categorization of parameters, and I've got some wording that I'm gonna propose for that. But I think, fundamentally, we have to make a decision that. Then
Pierre-Antoine Champin: Bye...
Stephen Curran: did URL be referencing is...
… A, um, do you want to pass back the fact that you've ignored a parameter, and B
… Um, how does that get passed back? And… and that could lead to the requirement that there be
… The referencing metadata pass back that says, hey, here's the, the parameters or the path that I ignored. In… in the overall process
… So I'll stop there
Otto Mora: Yeah, sorry, go ahead...
Manu Sporny: I'm next on the queue. I guess I'll go. Otto, you might be muted, acknowledging people...
… Uh, uh, plus one, Steven, I think that is a, uh, it's a good call-out. I, I'll highlight that the algorithms that we have in the spec
… are general guidance. Um, implementers can do something wildly different, as long as the end result is the same. And we can't
Stephen Curran: Mm-hmm...
Manu Sporny: tell implementers every little thing that they might have to care about, especially if they're in different, you know, programming environments than others, different libraries being used, you know, all that kind of stuff...
… Um, so… I do agree that we should call it out, but I don't think we need to… I mean, the algorithm does not need to be perfect and cover every single case. It just needs to cover, kind of, the basic stuff
… Um, and we can talk about implementation, uh, you know, security and privacy considerations in the threat model, um, and we can highlight places where we're kind of like, hey, you might want to, you know
… let different parts of the process know when different warnings are kicked up from different subsystems, right? But unless it results in, like
<swcurran> +1 to Manu -- I just felt it important that we have the discussion.
Manu Sporny: critical change in the output. One, we don't have to document it at all, but it's usually a good idea to at least write a note or two, you know, about it
… So even though everything in the algorithm is a black box to other parts of the algorithm, it's up to implementers to try and like, I mean, you know, figure out the right thing to do. We need to kind of trust that, you know, the good majority of them are going to do
… a decent enough job implementing it and have processes in place that will find bugs and refine their implementations and make new releases. And if software projects don't have those
… processes in place, people might not use that software, right?
… So anyway, I don't think, you know, yes, we should speak to it, but I don't think we need to be perfect in the first go around. That's it
Otto Mora: Okay...
Will Abramson: Yeah, no, I mean, I think this is good step in the right direction. I just wanted to flag folks. I mean, please take some time to try and review this over the weekend, so we can talk about it on Wednesday. The one thing that I want to draw people's attention to in there is...
… This idea that, Steven, you've got about process objects as this… as this handling strategy, I still don't fully understand that
… And… it… I think… so, like, they set the handling to process objects. Like, for me, that is, like… I mean, for me, the purpose of this step 3
… That is
… Uh, handling object. And then that object is the thing that we really need to, like, return
… In quotes, from this
<swcurran> +1 -- that is exactly what I've tried.
Will Abramson: And I think what you're getting at here with process object is about, like, identifying an object in the DID resolution result, so that's the DID document or the DID metadata. What the handling strategy is. out from this algorithm here, because it's that object that tells us the strategy, right? Like, the object, the type of the object or
something should be the thing that says
… That was my reading, but I would be interested in what other people think of that, so just pay some attention to that
Markus Sabadello: I like the modularity of this. I think this is going in a good direction. This is, I think, an...
… improvement over the previous structure that was more like a if-then-else kind of algorithm. So this approach with the strategies, I think, is good
… I'm worried a bit about the path handling objects, I'm not sure if that's
… going to work very well. I wonder if that shouldn't be an extension, or it feels to me like a change to the document data model, which, as you know, is based on the controlled identifier
… data model, and I wonder if it's a good idea to… to introduce new… new properties, or new… Types into the, into the core data model
… But I look forward to
Otto Mora: I don't know...
Markus Sabadello: Reviewing the PR in more detail...
Manu Sporny: Um, right, uh, on that, two things, uh, well, response to, uh, Marcus, and then a very tiny nitpick about the language on the screen. Um, it is, um...
… I mean, you know, what we're trying to do here is provide a generalized mechanism for path handling that feels more intuitive to developers, right? And that's what the debate is currently. Is this more intuitive? You know, what are the ramifications, all that kind of stuff
… But we can add new things to the DID context. Our charter allows us to do that. We've done that, you know, in a variety of different JSON-LD contexts, you know, before. So I don't see that as a big issue
… Uh, you would have to use the new DID V11 context to… to get this, uh, kind of feature and functionality, uh, which is fine, right? That's why we created this extensibility mechanism, um, that we did. Um
… Okay, so that's the first thing, is, like, we can do this. I don't see any reason why we wouldn't be able to do this and get it broadly deployed and working in a unified way across many different DID methods, where the DID document author gets to choose whether or not they want to use
Stephen Curran: Mm-hmm...
Manu Sporny: uh, it or not, so that's good. Um, and then the… the second thing, Steven, the… calling… I'm… I'm concerned about calling everything an object, because, like, you know, in computer science, everything can be called an object, and so it's kind of a...
… not very useful, uh, word to use. Uh, I'm particularly concerned about path handling object, um, and just not calling it something like a path handler
… Um, I, I do a object being, you know, lowercase, um
… And it being called a path handler, uh, and a path handler, you know
<swcurran> +1
Manu Sporny: It has an object form and it's got properties, key value properties in it. So again, super tiny nitpick, but like it's grading on my screen
Stephen Curran: That's it...
Manu Sporny: Senses, unfortunately. That's it...
Otto Mora: Excuse me...
… Done. Okay. So, yeah, so that's… yeah, so just in the interest of time, I close the queue, but I'll let Steven have the last word. So, please, Joe, go first, and then Steven
<Zakim> JoeAndrieu, you wanted to discuss query parameters
Joe Andrieu: Um… Yeah. I don't I don't want this to be a whole can of worms, but I I I wanna read in in more detail what's going on with the query parameters...
… I think that was the biggest unresolved thing in our conversation yesterday. Um
… Because we don't necessarily, like, for if the query parameter is a service, we know how to deal with that. If the query parameter is something else, I have concerns, and I want to read through this more clearly about, you know, what does that mean for our models for extensibility, and how would you know
… That a query needs to be handled in a particular way or used in a particular way
… So that's just a note for a future conversation we need to have
Otto Mora: Okay… it's good...
… Just
… Uh, Steven, any reaction to that, or
Stephen Curran: Yeah, the two comments objects, I'm totally up to whatever we want to call it, but yeah, we're finding them in the did doc and so I'm fine with that. On the parameters, Joe, one thing I would suggest is. Go through the, um, set of extensions...
… And, um, like, the current extension registry, and you'll see
… um, various parameters, some of which will affect how you choose, some of which will come into play after you've chosen a strategy and you start to use it. Um, some of them obviously happen at deed resolution, so I think that comment that, um, Will made in the previous spec
… of the categories of parameters is is really
… You can then see how to use them
… interesting and and relevant. Because once you see that and you start to see where people have actually created parameters
Next Time: Threat Modelling Discussion
Stephen Curran: So that was my suggestion as as far as evaluating, yeah, use of parameters. That's it
Otto Mora: Okay...
… Okay, uh, yeah, so on this one, I wanted to ask, uh… Joe is
… Are we now at a stage? I mean, I appreciate things that are very much in flux, but… ah
… Is it possible to maybe have that conversation on the third month and pick that up again in some sense?
Will Abramson: Oh, I have something else that I do want to get to before we end the call...
Otto Mora: Will, do you want to talk about this?...
… Okay. So, Joey, is it possible to pick up the print modeling discussion now, or do you think we need a little more? Sure
Joe Andrieu: Um, I think, uh, yes. I mean, I think the main thing we need for the group is to, uh, start ideating and capturing and enumerating threats, so I think we could do that at any time. Sure...
Otto Mora: Okay, so maybe 20 minutes next time? Some… Pretty sure, okay. And Will, go ahead, last word...
Will Abramson: Yeah, I just want to bring to the group's attention, uh, something PA mentioned to me that...
… TPAC is coming up, and, you know, we will be at the end of our charter around then, right, maybe even we'll be done by then, so, like, the question is, do we want to have any time at TPAC to
… discuss. I think we need to make a decision very soon. It kind of crept up on me, but, um
Otto Mora: Yep...
Will Abramson: I think me and Otto are thinking maybe just like half a day or something, but yeah, open to the group if you have an opinion. I see Manu tried to speak, so go for it...
Otto Mora: Uh, madam?...
Manu Sporny: Uh, yes, uh, I think we should plan some time, uh, in Dublin. Uh, we may want to, uh, combine it with a DID working group meeting, and then a discussion about, uh, the DID methods, uh, charter. That's it. And/or what to do there...
Will Abramson: at...
<pchampin> we have until 17 June to book a slot, i.e. before our next call
Otto Mora: Excellent...
Will Abramson: Okay, how much time do you think we need?...
… Okay
Manu Sporny: And if… and if there's, you know, charter discussion. Yeah, a day, a day at least...
… Well, a day at least
Will Abramson: Okay...
… Great
… Thanks
Otto Mora: And with that, yeah. Thank you all folks. Appreciate it. Cheers...
<ottomorac> transcriber-bot, pause
Joe Andrieu: Thanks, Chairs...
<pchampin> a day will necessarily clash with VC WG