Meeting minutes
Agenda Review
<ottomorac> transcriber-bot, resume
Otto Mora: Yes...
… Sounds good. So, um, yeah, I don't have the
… Minutes from last week, but we can maybe just provide a brief summary of
… what transpired last week, and I think there's some PRs being created, um… Right, Bill
Will Abramson: Yeah, I mean, I can try and summarize...
… Yeah, so… last week, we were focused on, um
… like, I guess, loosely, step 3 of this dereferencing algorithm, the refactor. So I'll just get the spec up, because… Um
… So
… The referencing strategy for DID URLs https://
… Um, and what happened? So we walked through a bunch of examples that Stephen put together. I mean, the outline has now emerged into the spec, so we have these five steps that we all discussed, I think, a couple of weeks ago, and kind of came to, you know, broad consensus on. And we were discussing, really, the. And I think we came to
… consensus on what steps through, you know, like, how we handle these different cases. For example, I think the key one was when there is a path on the DID URL
… what we do is we look in the DID document, or really look in the DID resolution result for all, um, objects that identify themselves as path handling
… And we collect them together, and then we use the path in the DID URL to select
… The specific object that we're going to use to process the path
… Uh, and if there is duplicates, or multiple are selected, then that is an error
… And that's what we decided. And then I think the other one we decided if there's a service query parameter, then that would be processed first. So the service query parameter is targeting a specific service in the deduction by an ID. And
… Even if there's a path, you use the service to select the — you use the service query parameter to select the specific service that you're going to use. Uh, and I believe we said… you either
… ignore the PATH, or, you know, you use the PATH as that service you selected. Determined. So it might use the path, or it might not
… Yeah, so that's my understanding of it. Please jump on the queue if I've missed things. There's Steven there. I mean, since Marcus isn't here, it might be a good place to start
… Um, I think we're ready for PRs on that section at least, so
… Steven? Oh, sorry, I just did your job
Stephen Curran: Yeah, I was just jumping on the queue to say I've been thinking through and planning it out. I should have a PR. By today. By the end of day...
Will Abramson: Right...
Stephen Curran: Um, that is the, um, that...
… that you just walked through, which is all of the retrieval strategy selection, I believe it's called. And I've got, at this point, 4 different
… I think 3 or 4 different, uh, I think it's 4, maybe 3. Anyway, uh, retrieval strategies, I'll have that PR in. built on top of 331, which we merged on Monday
… Uh, for discussion tomorrow
Otto Mora: Perfect. Well...
Will Abramson: Great, yeah, I just wanted to follow up and ask about, um...
… I think one of the things we also discussed was how does, uh, something in a did resolution resolve? Identify itself as path handling
<swcurran> +1
Will Abramson: And I believe where we landed was we are going to define a new type
<JoeAndrieu> +1
Will Abramson: Uh, that would go in the, you know, like, the service has a type property, and then there's going to be a specific type that anything that's path handling would have to add to kind of flag itself as, hey, I handle path
… Uh, I was hoping for Alex, I've messaged Alex, he might join us tomorrow, or at least he's aware that this change is going through. This is going to require both, you know, the did-linked resources and the linked resources approach to make some changes. So be good to have everyone
… I think that's a good approach, because… I'm bored with that, so
… So I just wanted to ask you, Steven, really, is that something that is also going to be in your PR?
Stephen Curran: Yep, yep, yeah, that's fair...
Will Abramson: Great, great...
Otto Mora: Hmm...
<Zakim> JoeAndrieu, you wanted to mention interaction language
Stephen Curran: Yeah, I've got it written out, I just have to go into a respec and put it in...
Otto Mora: Okay, and I believe...
Joe Andrieu: Yeah, I wanted to see if we could spend some time, uh, trying to nuance the language, um, of how we talk about retrieval strategy to address a pretty good point that Marcus brought up...
… Um… If we have at the end of this calculation of the service endpoint something that's like a mail to. Uh, scheme
… It it doesn't I mean maybe technically it's right in some notion because it's a uniform resource locator So we're you know dealing with the resource. But it feels more like we're interacting with the resource when we execute a mail-to handler
… Um, and so I think the language that I had
… And I'm not sure how to clean it up but I I resonate with Marcus's concerns. You know, proposed around retrieval strategy and that we're getting a resource and then using the resource. There is a little bit of dissonance there
Otto Mora: Okay? Uh, yeah, well...
Will Abramson: Yeah, I mean, I guess I'm wondering if Joe thinks we should be looking for other names than retrieval strategy, or at least taking some time to explore that. Um...
… I can't remember what we said in the case, so
… Um, so I have a service query parameter, and I'm targeting a service that is, like, a mail-to or something
… And what did we say the outcome of that would be? Because this service wouldn't have a defined retrieval strategy yet, maybe, let's say. You know, like, there are services out there that don't have this concept of a retrieval strategy
… I think… Did we say we just returned the object, or the URL? Or maybe it was the URL, I'm not sure
Joe Andrieu: Uh-huh...
Otto Mora: Mm-hmm. Manu?...
Manu Sporny: I'm wondering if we can say that...
Stephen Curran: Okay...
Manu Sporny: one of the options, you know, is to retrieve the resource, but that's not the only mechanism that you can use. Like, for example, I think...
… You know, we're really talking about, you know, using the, the resulting outcome, right? So use, use the resulting outcome where one of those things might be dereferencing the resource, right? I think the current language
<swcurran> +1 to Manu
Manu Sporny: It seems like we're saying, oh, you always dereference a resource. And I think maybe we can change it to say like one of the things you can do is dereference a resource. And here's, you know, the retrieval strategy and all that kind of stuff for if that's the path you go down. But another path might be like, oh, it's mail to URL
… open an email client using that, right? It's not necessarily dereferencing, but you are using the result of, um, you know, the process. As one idea. That's it
Otto Mora: Okay, we got Steven on the queue. Uh… oh, sorry, sorry...
Stephen Curran: I just said, I agree with Amanda. Yeah, I jumped off. So Joe can go ahead...
Otto Mora: Okay, Joe...
Joe Andrieu: Um, okay, uh, three things that'll come up. So, um, I… I think, to Will, your comment about if there's not a retrieval strategy, because there's a mail-to...
… The mail to is a scheme on a URL that's going to be in a service endpoint property. That service block should still have a type
Stephen Curran: Mm-hmm...
Joe Andrieu: Now may only have the bear type and no specific type. Like it may say, hey, I'm a service...
… Right? And in which case, we would define, what do you do with a service that doesn't have a secondary type?
… Right? It's not a path handler, it's not a whatever. Um, it's just a type of service
<swcurran> Note that "service" is not a type.
Joe Andrieu: Um, so I do still think it would be within that service to decide how you interact with whatever URLs, um, are appropriate for its service endpoint. Um, I think that… so that's one point. Next point, I think what we do
… rather than returning a resource in those cases, although I think there is some nuance in which
… What you're really doing is retrieving a representation of the resource. I've heard Pierre Antoine use that sort of language. But we invoke a handler. Functionally is like what the browser does, right? If I click on a mail to link and I don't have a mail to handler
… uh, set up, then the browser will prompt me and say, well, how do you want to handle this? So it may be invoking a handler is, um
… uh, language we can use. Um, but I do think, uh, this is a little pushback on what you said, Manu. I think when you have a mail-to URL, dereferencing it means invoking the handler. So I think, I think in the world of
<swcurran> So instead of retrieval strategy why use "handler strategy"
Joe Andrieu: Dereferencing URLs, they process a mail to dereferencing in that manner. So I think the language still applies, even though what comes back isn't really the resource. Like, that's the weird thing. Like, when we think of HTTP or FTP, we think we get back this block of
Retrieval Strategy
Joe Andrieu: a binary something or text something, and that is the resource. But with MailTo and other sort of service-type, um, schemes, that's not quite right
Otto Mora: Uh, Dimitri...
Dmitri Zagidulin: I think invoking a handler, like Joe said, is the best of the options that I've heard so far...
… But to me, this is just more events that were going down the wrong path. Uh, saying
… I don't think any other spec has the words, use the resource
… Inspect shouldn't tell the client what to do with the resource. We in such generic terms
… And… That's not a spec. That's just saying, yeah, do something
… Uh, the invoking a handler
… So, we're in browser territory. Now, we're gonna have to look through the browser specs on how exactly they do the handlers there for
<Zakim> manu, you wanted to note that mailto invokes a protocol handler
Dmitri Zagidulin: for resources and pretend like we're writing browser code, but we're not. All of this is just signs that we're going down the wrong road with. with this whole retrieval strategy. That's it
Otto Mora: Mm-hmm. Manu?...
Manu Sporny: Yeah, just, uh, digging around, um, on Mailto, um, so I don't think...
… I don't think dereferencing applies there, right? So MAIL-2 is a scheme, it's a protocol scheme, and the way that I think most RFCs talk about it
… is you invoke a scheme handler or a protocol handler. And so, you know, there's language around there being a handler, you know, involved there. So maybe, you know, playing off of what Dimitri said, maybe we are talking about handlers here. We're not talking about, um
… you know, anything, uh… anything else. But yeah, I mean, like, you know, I don't know if we have something other than mail, too, right? So for, like, HTTPS
… we are dereferencing, that makes sense. For mail 2, we're invoking, uh, you know, protocol, uh, handler, effectively. Um
<Zakim> JoeAndrieu, you wanted to mention secondary resources
Manu Sporny: I'm trying to think of another class that doesn't fall into the scheme, the protocol schemes bucket, um, because all of those are… you invoke a scheme handler, you invoke a protocol handler, uh, and then that's… that's kind of it
Otto Mora: Mm-hmm...
Manu Sporny: That's it...
Otto Mora: So...
Joe Andrieu: Yeah, one other scheme that has that property, but there are hundreds of schemes. So I'm sure you know that there are tons more, but Bitcoin is also like a mail too. It should open in your wallet and, you know, open an interface for you to send money to that address...
Stephen Curran: Yeah. Okay...
Joe Andrieu: So it's also sort of not resource based. I think, Stephen, did you suggest in here a handler strategy? That may be a good way to rename that this section. So I'd be in support of that...
… But I'm still fascinated, Dimitri. 3986 absolutely talks about secondary resources and what you have to do after you've gotten the first resource. So there is great depth in these systems about what you do with response you get back from your first couple of steps. And that's all we're doing
… We're saying when you get back a DID document, the URL alone is not sufficient. And for linked resources and DID linked resources, it is completely unusable if all I have is the URL and you hand me an HTTP URL because I cannot guarantee the integrity of the object, and that's the whole point of linked resources
… So we need to have some mechanism whereby the the referencing party that did URL client can figure out what to do with the with the result they get back from resolution. And that is going to be looking at the data and figuring out how to invoke what kind of handler
… Which is using the the resource but maybe maybe it's you invoke the handler is what we're gonna say. That may work better and maybe more aligned with where you're coming from, Dimitri
Dmitri Zagidulin: Yeah, I think invoke the handler is much better language...
Otto Mora: Thanks for that. Uh… Steven?...
Stephen Curran: Um, for another example, um, that is much more into the space we're in is Didcom, because when you get a Didcom-type service...
… you aren't going to use it at that point. What you are doing is just getting that DIDCOM information, so when you start interacting with the other party, which you may do a thousand times after you, you know, after you do
… Um… did URL dereferencing, you're just using that endpoint. So you're never going to use it right away. So again, that's a different one than what we're talking
… I liked what I heard, so we said… so, just to be clear, I think we're saying, instead of retrieval strategy, we're saying. you know, handler. Um
… Uh, handler selected, of which we've got
… 4 or 5 of them. that are there, one of which is
… You know, handle the object, process the object you get back, and that will depend on which object you get back, and what its service type is, and what you want to do with it
… Is that what we're hearing? And so it's just that nuancing of that
… The the overall approach is the same, but we're, we're getting away from retrieval as the only thing you can do
<Zakim> manu, you wanted to note all of those are scheme handlers (not resource based).
Otto Mora: Okay. I don't know...
Manu Sporny: Yeah, plus one, that sounds right to me. Um, at the very least, I think we're talking about handlers. Um, Joe, I was somewhat confused by what you said. You said Bitcoin...
Stephen Curran: Okay...
Manu Sporny: you know, doesn't fall into the category, but it isn't… I mean, Bitcoin's a… is a protocol. Um, I think it has a protocol scheme, Bitcoin colon. You might be saying, like, no, like, the… the thing that we're talking about doesn't have that...
… scheme handler in front of it, and therefore, you know, not every one of these handlers is going to be associated with the protocol scheme. Um
… So, general question there, is everything we're talking about here, does it have a protocol scheme involved somewhere? At which point, these are protocol scheme handlers, and that's kind of what everything else
… refers to them as. Um, and if that's not the case, then I think we just back off to, like, handler
Stephen Curran: Mmhm...
Manu Sporny: but, you know, what kind of handler is it? Like, we… I… it feels like we need a descriptive word there for the type of handler it is. Um...
… But if we can't figure out what it is, then just handler for now is fine, probably
Otto Mora: And you and, Manu, you mean BTCR2 in particular, right? Not just Bitcoin generally. You're talking about that that particular dimension. As a sample...
Manu Sporny: Well, I'm looking for an example. Yeah...
Joe Andrieu: That's the intersection. Let me go ahead and answer it. Uh, there is a Bitcoin scheme...
<Wip> this - bitcoinjs/
Joe Andrieu: Which is used like mail to where if a browser were to come upon it, the handler it should select is a wallet, and that wallet will open with the transaction so the individual can decide how much money they're going to send to that address
<Wip> Sorry this is better - https://
Joe Andrieu: Um, but that is not the retrieval strategy or the handler strategy that you would use if you were, uh, given the Bitcoin. Endpoint from a, um… Uh, BTCR2
… service endpoint. So, frankly, we didn't define it when we
… Uh, came up with BTCR2, we weren't thinking that someone might
… index that service, and put it in the URL, and say, hey, dereference this URL that goes to this service
… What I think should happen if you do that is, uh, you know, it's up for debate. In fact, you know, I don't even control the spec anymore. So, um, what I would think you would do is you'd get back the chain of provenance of the edits to the DID that were anchored at that address
… Because that's what the resolver is going to do. So I think you would echo retrieving the set of resources that a resolver does because it has a service endpoint. And so we can't just invoke a handler that it's Bitcoin because it would not do the right thing. And that's sort of the same problem with linked resources
… Which is, a linked resource could provide a URL, it doesn't have to, it's optional, but it could provide a URL at which you can go get that resource. But that URL alone is not sufficient, so the HTTP or HTTPS, um
… Protocol is not the only thing you need to do. The handler needs to know the data integrity components And possibly the encryption or the compression components in order to understand how to process that resource once it gets it back
… So there is still a handler here that wraps around the get of the HTTP endpoint. And so one of the things I've been arguing for here is that whoever is handling this next step, right, to invoke the handler, they need more than the URL
… They can't just use the protocol. They need, at least for linked resources, they need the protocol. I mean, they need the data integrity elements, and for the Bitcoin thing, you need to know that this is a BTCR2 special handling mechanism. It is not just a Bitcoin. Colon URL invocation
Otto Mora: Got it. Uh, Steven?...
Stephen Curran: So, I think what we're doing here is putting a lot more pressure on the… underlying specs...
… that define, oh, here's what you do when you get a service with this type on it. Um, here's what you do, you know, for
… items within the DID doc or the DID metadata. Um, we have not pushed too hard on that before, so one of the things, like, like, I wanted was to put the, um, path service type in
… this spec, and so certain ones would be in the DID resolution spec
… Um, but allowing others to be put into extensions and
… And as appropriate, moved into this specification, so that it, um
… gets consistency in how… how types of things get used. Um, that's
… But I think that's the path we're going down, which… this spec is just gonna say, hey, you got… you know, as a result of this, you're gonna have. an object that's been identified by the DID URL
… handle it as defined in that specification. That's it
Otto Mora: Okay. Kevin?...
Kevin Dean: Yeah, just want to add that the HTTP is no longer just a...
… get a resource protocol. There are, particularly when you're dealing with mobile devices
… apps can register their own URLs, for example, Amazon, and clicking on that URL will actually open the app. It can go straight into the app and trigger. Uh, actions within the app
… Before you actually complete the process that you intend to complete
Otto Mora: Mm-hmm...
<Zakim> manu, you wanted to ask are these "service handlers" or "service strategies"?
Otto Mora: Uh, yeah, madam?
Manu Sporny: as a service. Yeah, plus one, that's a great point, Kevin. So what are these things called? Are they service handlers or service strategies? I'm guessing maybe not, because I forget, it's like resources doesn't actually express itself, is it? Um, yeah...
… And if so, you know, if we pick one over the other, like, what's the driving
… reason. I do like strategy as a general term because it's like, you know, a way of doing something. Handler's fine as well
<Zakim> JoeAndrieu, you wanted to maybe both
Manu Sporny: So, it's really the question is, are these things only about services, or
Otto Mora: Mmhm...
Manu Sporny: Something else. That's it...
Otto Mora: So… Oh, wait...
Joe Andrieu: Um...
… Yeah, I think it… I think, actually, it's probably both on different elements, uh, Manu, in that I think we're gonna use the data that we have back, the data in the DID URL, the data in the DID document, the data in the metadata. To determine the, uh, handler strategy
… And then, they… they use the resource bar is invoke the handler, right? So you're gonna execute the handler. Um, so
… I think it's… it's just two different steps
… That's it
Otto Mora: Perfect...
Joe Andrieu: Right. So figure out the strategy and then find a handler that can execute that strategy...
Otto Mora: I think I know what you're relating to. The both thing ended up on the queue...
Joe Andrieu: That was me, sorry...
Manu Sporny: Yeah, I mean...
Otto Mora: I don't know how that happened. Anyways. Yeah. It's interesting. I've never go ahead...
Manu Sporny: I guess a plus one, Joe, to what you said, um… do we feel like we have enough language to kind of work it out in the PR at this point, or do we feel like it's gonna… Leave the conflict...
… In the PR
Joe Andrieu: Just off the queue. I think it feels good to me. Steven, do you think you could write it without confusion?...
Stephen Curran: Um, yeah, I can certainly take a try at it, and I think this has been helpful. I think, um...
… to clean it up a little, we'll see, but I've certainly not been able to do a PR without tons of controversy before, so
… Oh, wait! No, I did one the other day that was very uncontroversial. So okay, I'll try
Otto Mora: Okay...
Stephen Curran: And...
Otto Mora: The… the big ones are definitely easier, but yeah, when we get into the details, that's...
Stephen Curran: Yeah...
Otto Mora: Well...
Will Abramson: Uh, yeah, so, I mean, maybe last point on this, then we can move on to a different discussion, but, um… I just wanted to… seems like we all have clarity, but maybe people could just tell me, then, the five steps. I mean, I really… I'm looking for step three and step four. What do we call these things? Currently, we call
them...
… Determine retrieval strategy, I'm hearing. That's gonna change to maybe determine path handling, and then retrieve the resource would be. Execute handler
… Question mark
Otto Mora: Mm-hmm. Um… Stephen?...
Stephen Curran: I'll defer to Joe, because I think he's saying what I'm gonna say, so go, Joe...
Otto Mora: Go ahead...
Stephen Curran: Oh. Perfect...
Joe Andrieu: Sorry, I was muted. I think, well, let's just determine a handler strategy and then invoke handler become the names for four and five. If I got my number in right...
Will Abramson: Yeah, both...
<manu> sounds good to me
Otto Mora: Okay. Yeah. Go ahead. I think that...
… Yep, analysis, yeah. Hopefully you have… Steven?
Stephen Curran: Okay, I do have one more...
… Remembering, as well, that
… you know, we can define things in this, you know, the URL, the referencing section, but when a
… So, I think… um, a, uh, client, if you will, retrieves just the DID doc, they still can do all they want with that DID doc, but, you know, they're gonna… we're gonna want them to do it in the same way as if they had added a DID URL and referenced a specific service they want to use, and so on. Um, you know, this idea that we're
… doing specific things, the specs underlying what that service type means, how you're supposed to use it. Those are equally important. And so we do need to stress to the community when you define an extension
<JoeAndrieu> +1 to raise the awareness for defining handling strategy
Stephen Curran: Here's the good practices in doing that. And as well, putting certain things into the resolution spec that we want to be handled very consistently across all implementations. I think those are sort of things we should think about as we go forward on this. That's it
Otto Mora: Uh, Joe? Uh, yeah...
Joe Andrieu: No, that was just a plus one...
Otto Mora: Oh, okay...
… Okay, great
… Uh, next topic was, uh
Continue discussion on DID Resolution Algorithm Inputs
Otto Mora: the actual… I think it's the actual inputs… um… to the
… algorithm, right? I guess that's sort of, I think, the next big one. I don't know, Joe, if you wanted to first touch upon that, maybe. Just generally, I think we
… There was a conversation about that last week, right?
Joe Andrieu: Sure...
Otto Mora: Whether it was a video or a rail or a vehicle...
Joe Andrieu: Sure. So...
… Right now, we have, um, Resolve taking a DID
… Um, and we have, in my view, unfortunately, taken all the parameters that were in the DID and forced the client to process them, and then pass them back as options. And I think that step is a step we can get rid of, and it is a step which creates the possibility of
… Bugs and errors, um, and, and confusion
… And I don't think it creates any real value for us. Once we acknowledge, and this was actually fairly early on. that version ID and version time
… Must go to the resolver because it could affect the selection of the did documents
… Um, so I think… I think we should clean that up and make it… So that we are doing the the least amount of processing on the client as possible. Then really we've we've never been resolving just dids even though we spoke about it that way
… And I think the most we can reduce it to is to strip off the fragment. Like, I think we're all in agreement that you don't send the fragment to the resolver, just like you don't send the fragment to the web server
… But I'd very much like to to not do any other processing on the client if at all possible for most of the use cases is just send that whole did URL to the resolver with the information that you need if the client has. reasons or, um
… reasons to override any of those properties or to add properties that aren't there, such as you have a DID URL that doesn't have a version time, and your VC is of a particular time, and so you want to bound resolution to that version time, then the client is the one who understands that, and they can certainly
… in the mechanism that we've, you know, sort of modeled after the HTTP headers, we can add an option that, uh, lets that sort of version ID parameter get passed. I think that's still, you know, uh, positive. But I'd really like to get rid of that, um, what feels to me an extraneous processing loop on the client side
Otto Mora: Uh, yes, Will?...
Will Abramson: Yeah, I just wanted to say, like, I don't think we're gonna be, um...
… Actually, it doesn't matter, I won't say that. I think I'm broadly in agreement with this approach. I think I agree that
… the like. it makes the client's work simpler. I'm just thinking, like, when I'm doing DigiURLD referencing, I guess the client only cares about the query parameters that it knows about, right? So it only needs to process the ones that it knows how to process, and all the others it just would ignore
… Is that right? I think that makes sense to me. And also, I wanted to add, I think we're saying that if the client does specify options
<JoeAndrieu> +1 to options overriding
Will Abramson: then those options override any options that are also in the URL. But that is
Otto Mora: Okay, uh, I see Marcus is next...
… Marcus
Markus Sabadello: Okay, yeah, as I said before...
… I'm really against making this change. I think it's not backward compatible. It's a huge breaking change to change the inputs of the
… of the function, um, that would break a lot of existing implementations and existing DID methods. We've always been telling people that we resolve DIDs, we don't resolve DID URLs, we resolve DIDs
… And the result is a deep document and that's as simple as it can possibly be. Didn't really understand
… chose explanation of how what the client would do instead or how
<swcurran> So how do we deal with versionTime?
Markus Sabadello: how this is problematic or how it would change
<Zakim> manu, you wanted to agree and that our resolver will be implementing accepting full URLs
Markus Sabadello: But I think it would be a big mistake to make such a breaking change
Otto Mora: Manu?...
Manu Sporny: I guess a couple of points. Plus one to what Joe said, I think the feature is not really buying us anything. I know that our implementation will, our resolver implementation will support DID URLs being passed in its entirety...
… Uh, and the driving reason for this is that, you know, we're looking at, kind of, the interface and developer
… uh, developer experience. Um, and, you know, when… if we just look at HTTPS, like, we pass the entire URL. Most clients pass the entire URL
… to the libraries that we use today, including fragments, right? I mean, like, developers typically just, like, shove the entire URL in there, they don't do any kind of processing, and they expect to get back
… you know, something reasonable, and I think we should follow the same pattern that, you know, has been established
… on the web for many, many years now. Okay, so that's point one is that, you know, our resolver will implement this. We think it's good for, and by we, I mean, you know, Digital Bazaar
… thinks it's good for the developer experience, so the developer doesn't have to think about, like, processing all the query parameters, and which ones they understand, and which ones they don't. You could just throw the whole thing
<swcurran> +1
Manu Sporny: Uh, at the… at the server, and we do expect people to not even strip the fragment identifier off of there. They're gonna, you know, they're gonna pass to the library, hopefully the library strips it out. Um
… Uh, before sending it up to the server. Um, okay, so… and, and, you know, to get through REC, all we need is another implementation to do that, and we've got, kind of, demonstration of, of interop, uh, on that
… So that's the first point. Second point, uh, is this a breaking change? Uh, no, I don't think it is. Uh, we defined an abstract interface and did core. Um, we were not allowed to, like, you know, specify, you know, what, uh, what the concrete, you know, interface was. It was outside of our charter
… Uh, did resolution has not met 1-0, we can break anything we want to in the spec, right? I do think Marcus has a point in that, like, people have implemented this, um, but all of the people that have deployed this into, uh, you know, the, the, the world and have clients that implement it, they're just sending up
… DIDs with options. So that's not gonna break, right? That… that will continue to work, even in the… even in the new things. The… the danger here is that those resolvers might get a DID URL… DID URL in, and they're gonna have to do something, but
… I don't think it is a it's it's a tall ask
… to ask those implementations to update themselves, because they're going to be updating themselves anyway to make sure that they're in line with the DID resolution specification, and we're not talking about a tremendous amount of work to, you know, update those things. So, I think for those reasons, it's fine to make this change
… disagree pretty strongly with the… with the notion that, you know, it's a breaking change in the spec sense, um, and I think, you know, we should give, you know, DID… DID implementers, DID resolver implementers
Otto Mora: Mm-hmm...
Manu Sporny: uh, you know, some credit here, they'll… they'll update their implementations. We're not asking them to do something that's really difficult to… to change, right? Um, that's it...
Otto Mora: Marcus?...
Markus Sabadello: Uh, to comment about the analogy with HTTP and, uh, and the web, uh, I know that in HTTP you pass the path and, uh, and the query, but...
… When you resolve it. That's dereferencing, that's not resolving, so in my mind, saying that
… did URL, and you passed a path and the query in the resolution process, to me, the analogy would be a little bit like passing a path and a query to a DNS resolver, right? When you dereference an HTTP URL, then the first step is resolving the domain name to the IP address
… And you wouldn't pass the path and the query to the DNS resolver
… And so in DIDs and DID URLs, we've always had the same
… kind of separation, where resolving the… the DID means to… to resolve the DID, and then, uh, the URL and the path is, uh
… is then the dereferencing process, which comes after that, and then
… Really surprised to hear that these things are changing now. I think some of the other working group members have been arguing for a long time that the deeds should just be about
<swcurran> That analogy breaks with versionTime
Markus Sabadello: getting the deed document, and getting the public keys, and the service endpoints, and everything else should be a separate step. That's the
… That's the separation, that's the layering that we've always had, and in
… I mean, that did one recommendation. We have defined these interfaces, so I don't really understand either why it would not be a breaking change, because we have these functions with inputs and outputs
… Already in the in the recommendation, not just in the in the TD resolution draft and everybody has been implementing that for a long time
Otto Mora: Okay. Um, I believe, yeah, Manuel...
Manu Sporny: Yeah, I think the, and Steven said this in the chat channel, where the HTTP URL analogy breaks down is that we have included things like version time and a bunch of things that affect resolution, right? Like that's why...
… all of a sudden it matters. You know, when you do, like, a DNS query and a DNS resolution, like, the HTTP URL query parameters don't come into play at all, right? Um, however, with our spec, it does, for better or worse, and that is why
… you need those things to be passed through, and whether they're passed as options, or whether they're in the URL, passed as a URL parameter, they are used by the resolution process
… And again, to push back on the whole, like, you know, this is going to break things and people are going to be surprised. Like, I think we're not giving implementers enough credit. Like, this is not a difficult change to make in their libraries
<Zakim> JoeAndrieu, you wanted to say the deep dive on these matters is what we were chartered for
Manu Sporny: you know, not gonna break, um, uh, I don't think it's gonna break the ecosystem in any kind of significant way. And if it does, we'll hear about it, right? But I don't think that's gonna happen. And that's what, you know, CRs, CRs for, uh, is to get that, to get that feedback. Uh, that's it
Otto Mora: Okay, thank you. Joe?...
Joe Andrieu: Uh, yeah, I want to talk to the breaking change aspect as well. Um, I do think in the first round of our work, when we came up with DidCore, we were… we explicitly avoided the deep dive on the protocol that would be resolved. We called it a contract, not even an API...
… And I think that this group was chartered specifically to do this kind of deep dive. Now, I appreciate that it's frustrating that it took this long for the working group to get enough eyeballs on the spec to understand
… you know, where we might want or need to change some of these things. Um, but we've made quite a few changes once we've gotten to this point in the conversation. And so I think what matters more right now is having a coherent
… Spec that implementers can understand and implement easily. And I think
… Since we haven't even gotten to candidate rec yet. Believing that breaking software that's out there is, you know
… a crime or malicious or otherwise sort of negative, I think anyone who has implemented the spec today should be well aware that this is not yet standardized and that it will change. In fact, I would bet that this specification says that itself
… Uh, are already out there in the field. Um, and the status of this document. So, uh, I think we should figure out if it doesn't prove anything, and make a decision, regardless of whether or not it's a breaking change, to certain implementations who
Otto Mora: Markus...
Markus Sabadello: Again, I agree that whatever we have in Peach Resolution was never a standard, and everybody has to be aware and has to expect that things might break or might change...
… in the in the did resolution specification. But it's a it's a fact that in the in the did core
… one standard, we defined a resolution function, which takes a DD as an input, and it doesn't take a DDRL as an input. We even defined. Error codes, um
… Yeah, that, uh, like, the invalid DID error code, right? So today, if you
… If you invoke a resolver that's conformant with 1.0.0
… and you pass a DTURL, then a conformant resolver would return an error that says invalid DIT, because a DTURL is not a valid DIT, and if we change that, we
… I don't know, what does that mean? It means we're defining a new resolution function that takes a different input and behaves
… differently, I… I don't get how that would not be a breaking change, and I… Don't get how
… how it would simplify anything if we
… if we say now we define a function that takes a DID URL plus options as an input, how would that be simpler than passing a DID plus options, say?
… I really don't understand the explanations
Otto Mora: Uh, Will? Yep...
Will Abramson: Sure, um...
… Yeah, Marcus, I do appreciate that you don't understand the perspective, but I think, well, the simpler approach is that me, as someone who comes across bids in the wild and did URLs
… no longer needs to worry about passing those DID URLs, I can just pass it to a DID resolver through a standard interface, and get back a DID resolution result. And only then
… do I need to check the DID URL to see if there are any query parameters in there that I understand? As a, you know
… I think that is simpler. I agree it changes the abstract interface that we defined in did core, but I don't think that is an argument that this is a spec breaking change really. Like I think there was no tests against that interface. It was just a
… A placeholder for this work, which is the work of defining the
… way that we do digit resolution and digit URL dereferencing, in my opinion. And I also speak as an implementer who has developed a library that does digit resolution
… I would be happy to make this change, I don't think it's gonna be, uh
… Much effort on my part. And I ought to think like other implementers who don't want to make this change, I think they're still going to to work
… Like, like, DIDs are DID URLs. The only thing that will fail is when people are expecting resolver interfaces to support DID URLs, and they don't yet support them. And I think if you're not willing, if those influencers aren't willing to support them, make it at least
… Well, they will throw an arrow, won't they? They'll throw, like you said, invalid did error
… um… I don't think it's a huge failure date
… I also think, like, the invalid did error message is
… is for, like, or should be for, when the DID itself is invalid, not when the DID is a DID URL
… I mean, it's a side comment, but I think, you know, like, that is kind of misleading, because a DID URL contains a DID, and that DID might be valid. I'd rather know if the DID itself is invalid
… Anyway, last thing I'll say is Marcus, what everybody really, we as a group need to make a decision against this. I agree that there is strong feelings on both sides, but tomorrow, I hope you're going to be able to join us because we will be running a
… a poll, and, like, documenting this decision, and moving forwards, because this is taken
… I mean, there's been a lot of discussion going on, but this is the last thing that we need to get through that discussion and finalize, you know, getting to finalizing the spec, right? We're already a month over our charter
… Um, we have 5 months left, we really need to be wrapping up the spec, you know, getting to final review, and, like, tidying, just on tidying up
Otto Mora: Mm-hmm...
Will Abramson: That's all...
Otto Mora: Marcus?...
Markus Sabadello: Okay...
… Okay, I wanted… I'm trying to understand the argument about making it easy for a client if
… if I understand correctly, the idea is that if you pass the… if you pass the whole DTURL to a resolver, it makes everything easier for the client, because the client wouldn't have to parse the DTURL and understand. certain parameters, but
<swcurran> Right now, they have to convert all parameters into options.
Markus Sabadello: But I don't see how anything in the current design. Makes this hard for clients, because if you want to
… deal with… if you're dealing with DDRLs, then you can do exactly what you just said. You just pass the DDRL to a dereferencer, right? If you
… if you're dealing just with deeds, you… as a client, life is easy, because you can pass the deed to a resolver, and if you're dealing with deed URLs, then
… life for a client is also easy, because you pass it to a dereferencer, which does not have to be a remote service, right? Just to… just to explain that again and again, nobody says that a dereference is an external
… remote service with an endpoint or anything that the reference I can also trust the
… a library. But again, if you're if you're worried about developer experience, then
… Then yeah, use a dereference library, pass the entire DPURL to a dereference library, and
… And your application doesn't have to… do any complicated processing. I think that's already… In the specification, I
… Just don't get how this is an argument for… for making the change about the. The resolution function
Otto Mora: I know...
Manu Sporny: Just real quick on that point, Marcus, from a developer experience perspective, if I'm using a client, I don't want to have to think about all of the different parameters that might come into play and might need to be split out and might need to be put in options because I don't have all of that knowledge in my head...
… It is not something that as an application developer I want to be exposed to. I just want to shove a DID URL into the library and have it do the appropriate thing. Unfortunately, I think we're starting to repeat ourselves now. The thing I put myself on the queue for
… is to look at DID version 1.0, right? This is the resolution section. And, you know, this is going back to the is this a breaking change or not? We we do explicitly say their exact implementation is out of scope for this specification. So we define the inputs and outputs DID resolution URL exact implementation is out of scope for this
specification
… We also say that, you know, details of how this process is accomplished outside of the specification. We do say, you know, all conforming resolvers implement the functions below, but we also say they have the following abstract forms
… Right? Like, this section was a massive hand wave, and I know all of us can remember that it took… we had formal objections because it was so abstract. The formal objections were basically, you guys have not properly defined this, right? And so, again, like, is this a breaking change?
… no, we had a giant year-long formal objection about how abstract this thing was and how, you know, wishy-washy we were being about, you know, the definition of this stuff. So I'm just pushing back on that point of, like, is this a breaking change? Like, eh
… I think the only place that argument sticks is with implementations that exist today that did something. Yes, but I think we're saying, like
… you know, we're… we're trying to suggest to the ecosystem that a better way is to just simplify what applications have to do, application developers have to do, and just have them shove a dead URL at the libraries, um, and then the libraries, or the people that have all of the important details in their head
… They're the ones that will parse the URL out and use the appropriate query parameters and so on and so forth. That's it
<Zakim> JoeAndrieu, you wanted to say it creates a threat we can remove
Otto Mora: Mm-hmm. Cool...
… You're on mute, Joe
Joe Andrieu: That the client misparses the options. Yeah, sorry, I was muted. I do think we're getting in the territory, repeating ourselves, and we're at the top of the hour, so I'll try and be short. But I want to introduce where this came from was trying to threat model, did resolution, and looking at what the back and forth were between all
the components. And quite simply, there's a threat...
… And we have lots of responses that we could do for that. And the response that I favor is don't make the client do that. Like we can completely remove that threat. Um, and that's my motivation. Here. That's it
<manu> +1 to take the burden off of the client
Otto Mora: Mm-hmm. And then Marcus has the last word on this. So go ahead, Marcus...
Markus Sabadello: I don't know why any of you think that the client has to parse options or parameters, or why the client needs to decide which parameters it understands or doesn't understand...
… I fully agree that it should be possible for a client to just pass the DQRL to a library
<JoeAndrieu> the current spec requires parsing the query parameters
Markus Sabadello: And the current design fully supports that. That's the dereferencing function. So I'm sorry, that's really not an argument for making this kind of change
Otto Mora: Okay, well, I think, yeah, we've laid out both sides, and then… We can meet tomorrow to...
… Uh, more, uh, take a decision as a group?
… Thank you all