Meeting minutes
Agenda Review, Introductions (5 min)
<ottomorac> transcriber-bot, resume
Otto Mora: Okay, um, great. So...
… Uh, we have a few topics today, um
… We want to do a proposal from conversations that we had
… Yesterday, at a special topic
… Uh, meeting. We'll also do just a brief summary of the conversations. That we had the week before
… And just, kind of, generally
… Uh, yeah, present, like, the current status, and then… Then based on that, we can run to the proposal, and then
… We want to talk generally about the referencing algorithm at a high level, and then I think Will will be helping us with that
… But, uh, that's the general gist of today. Anybody have any inputs? Or
… Jump into that
… Okay. So, um… Let me just, uh, I guess… I think… summary of… Special
Summary of Special Topic Call and Previous
Otto Mora: Now, revisit
… So, okay, so first off, the previous call of last week. was, um… Sort of, uh
… Conversation around the refactoring of the dereferencing function
… And its signature, um
… We debated around that, and a significant portion of that was, uh
… how to do that, and how to do path processing, how all of that would fit. Um
… Steven Curran had submitted a detailed proposal for that, and we discussed that, and then also Joe had provided some inputs
… And then we sort of landed on, hey, let's not create, like
… really big PRs, like, really complex PRs, because it makes it kind of harder to
… Uh, process those, and so let's start with, like, smaller chunks, more
… Uh, concrete proposals that we can get through
… And then yesterday, um
… We spent some more time talking about that, and the need to start moving things, and uh
… You know, we do need somebody to be more concretely taking on the editing role
… And so with that, I think we… we're sort of, uh, considering, um, nominating two co-editors
… Uh, namely Joe and Steven, uh, have, uh
… Gracefully decided to volunteer, uh, their effort into this
… And so, this will be kind of, uh, a way in which we can start to get some more progress
… So, that's, uh, generally the idea here, uh, to nominate
… Both Joe and, uh
… even as co-editors of the DID resolution spec
… And, uh, then we can start to get some more progress
… And afterwards, then we talked about the
… dereferencing function signature, how we can maybe think about replacing that. Uh, Joe had voiced some concerns that
… Maybe we shouldn't be forcing specific outputs, uh, and then Manu just worried that
… You know, we also need return values, and that might degrade. Interrupt. Um
… And then, uh, we just landed on… on Will, kind of helping us out with the high-level refactor, but
… Well, keep me honest here, did I miss anything around, uh… Yesterday's call is not a fair
Will Abramson: No, that's great. I just wanted to sort of add, I think there was consensus yesterday that we are going to remove the dereferencing function signature...
… We're going to remove the text that says you must implement this function signature, and we are going to have an algorithm
… that has inputs and outputs, and those outputs will be optional. I feel like that's what we landed on, so we obviously have to execute that, but
… Um, that's what we got. And then also Joe had some good context from his discussion with Marcus in IRW
… Around the compromise around that, where we could define this function signature
… And the HTTPS binding for it as, like, a helper thing that's not in the main algorithm, but it's like, here's how you could do it if you want to do it like that, to still support. the stuff that MOX is doing
… So, we haven't actually talked to Marcus about any of this, but, um
… That feels like a good progress in the direction we want to move
… Uh, and then the last thing I put in… we said we would run a proposal today, so I put in some text. Is that text okay? Should we just run it? Just so we get it on the record
Otto Mora: Uh, do you put it in the chat? Or...
Will Abramson: Yeah, I emoted it in the chat...
Otto Mora: Oh, my bad...
Will Abramson: There we go...
Manu Sporny: Wow, where is it? I can't see it...
Will Abramson: Okay, great, yeah, let's run it on that...
Otto Mora: Let's run it then. Topic...
Proposal on editors
Otto Mora: Those are my head first
<ottomorac> transcriber-bot, pause
Otto Mora: Yeah, and then transcriber box
<ottomorac> PROPOSAL: Make Joe Andrieu and Stephen Curran co-editors of the DID Resolution specification
<manu> +1
<TallTed> +1
<JoeAndrieu> +1
<Wip> +1
<dmitriz> +1
<swcurran> +1
<wilou> here I am
<wilou> +1
<smccown> I was distracted, from the vote .... I downloaded the latest .ics (cal) for this meeting and apparently my email client is spamming the WG email group. SORRY! I'm trying to figure out what it's doing
<ottomorac> grace: +0
<smccown> +1 for the new editors
RESOLUTION: Make Joe Andrieu and Stephen Curran co-editors of the DID Resolution specification
<ottomorac> transcriber-bot, resume
Otto Mora: We're assuming, congratulations to both of you, newly minted co-editors. I'll be thankful for your help. Yes, Will...
Will Abramson: But, yeah, just to say, you know, thanks, and uh, we'll be in touch to add to the meeting. I do appreciate it. I think it will really help us move… the workforce...
Joe Andrieu: Cool, glad to help out...
Otto Mora: Yeah, congrats...
Will Abramson: Okay, let me just get these slides and share them first. If not… Um...
… Yeah, okay, so this is actually Manu's suggestion from last week, but, uh
… We try to get some
<Wip> Slide deck: https://
Will Abramson: So, let me put the slide back in
… some clarity on at least the high-level steps for this algorithm. I think based on the. Um
… the Google Doc that we did, where we looked at, you know, like, all the individual bits of Joe's proposal
… There seemed to be good consensus that the
… at least direction that Joe is heading in, in terms of refactoring that algorithm into some sort of much more chunked up steps
… was a good direction. So, last week, Manny suggested, can we at least try and
… get some agreement and some content on what those high-level steps are, right? Probably, inside those high-level steps, there are things that we will want to argue about. We are not going to do that today
… I hope, right? Like, first, we want the steps, 1, 2, 3, 4, their names
… Maybe what they do, and if we can, what goes into them and what comes out of them, right?
… Um, so, I tried to do that, I mean
… Actually, maybe this will be frustrating for some folks, but I ended up just really rehashing much of Joe's PR, but I did try to contrast with the current spec text
… So, if I slideshow, will you still be able to see that?
Otto Mora: Yeah...
Will Abramson: Yeah, okay, so...
… First, I want to highlight the existing spec text, right? Like, the existing spec text, so the DID URL dereferencing algorithm says, consists of three steps
… Resolving the DID, dereferencing the resource, and dereferencing the fragment. The spec currently defines two algorithms
… Derecessing the resource, then derefacing the fragment
… And, like, the resolving that did happens inside the dereferencing, the resource
… Uh, algorithm, which states today. I also just know, like, maybe this is a distraction, but
… The function signature that we have been discussing is really the signature for this algorithm 1, the dereferencing the results
… Your fragment doesn't return what you would expect from that
… I think that kind of is a little bit about where this confusion comes in, because there's this big URL deration that really is just implementing the. Be referencing the resource output
… Um, and then there's 326, or… I mean, there's a bunch of different PRs from Joe, but I think it's 326
… Uh, and in that hour… in that, uh, PR, there's 5 steps
… So prepare to resolve the URL, resolve the DID URL, determine the retrieval strategy, retrieve the results. And use the resource
… Um, so we want to get to R5, like, on the group. We don't have to use the 5 here, or maybe it's not 5, right? But we want to get to something. Like this, I hope. Uh… And there is some good news. I think the first two
… I mean, let's stop and talk about this, but for me, the first two, we are aligned on. Like
… Both… both the current algorithm that we have today. and Joe's algorithm, and Steven's PR
… all do this in some form, right? They first do some preparation, they validate the did URL
… Joe added this resolver selection. I mean, the details don't really matter, but they do some steps before they can resolve. the same. But I think
… Uh, we're aligned there, but we can often check. And then secondly, they all resolve
… the DID URL, with the caveat that some of them resolved the did, but they execute a resolution request, maybe we can say, and they get back. A date resolution result
… So… Dallas, Paul's in Tokyo
… Oh
Stephen Curran: So, quick question, just to verify. Oh, sorry, I...
Will Abramson: Yeah, Manu is on the queue, but...
Stephen Curran: I thought because we were… yep, go for it. Sorry...
Will Abramson: Yeah...
Stephen Curran: The quick question I have is...
… I want to be sure that when we're saying the did URLD referencing algorithm
… Begins before we have
… the DID doc that we're gonna use
… And that step 2 is retrieval of the did doc
… Are we agreed on that? That's part of where I think we've had confusion. We're all agreed that the did URL
… Whether it's just a plain naked did, or has a question mark version time equals, or
… a path or anything else. The first part of it is
… get the did doc that matters, and that's what step 2 here is. Agreed? I'm happy with that
Will Abramson: Yeah, that's my understanding. I mean, I don't...
Stephen Curran: Beautiful...
… I want it to be very explicit, so thank you
Will Abramson: Yeah, so the resolution result is the did doc plus the metadata that comes back. But most importantly...
Otto Mora: Okay, I see my notes...
Manu Sporny: Yeah, plus one, that's my understanding as well. Um, so we should ask explicitly, does anyone disagree with this?...
… And if you don't know yet, like, you're still trying, you're like, maybe there's something on the next slide, like, that's fine, but like, I want to make sure that we're pulling consensus as we go through this
Will Abramson: Mm...
Manu Sporny: Because if we have agreement on these two things, like, that's… Great...
<dmitriz> +1 seems fine.
Manu Sporny: So is anyone disagree, or does anyone… is like, I don't know enough yet to have an opinion, but I might have a strong opinion later
Otto Mora: Yeah, I'm in… I'm in the… might have strong opinions later, camp, for sure...
Will Abramson: Hmm...
Otto Mora: Okay. Um...
Will Abramson: So, I do think this is uncontroversial. I mean, like, the controversial bit is this did URL piece. But I'm saying, like...
… like… like, by agreeing to this, I think we're not agreeing to the did URL bit yet, like, that's not part of this
… Discussion, or maybe… maybe it should be, but, like, for me, it's… there is this pre-step that you take the thing that you're dereferencing, and you do some preparation to it
… Then there's this second step that you resolve and get back the did resolution result. And then you can continue. Okay
… Steven? Yeah
Otto Mora: Yeah...
Stephen Curran: Um, the only thing was, uh, I would highlight is, um, Marcus has definitely hammered into me that we dereference URLs...
… And so, saying resolved it URL is… I think we agree on what you're meaning, um… But there you go. Um
… Yeah, and that's it. No matter what, in order to get the did doc, it's a URL
… It's not just a did. So, um, we're dereferencing
… all the way, um, you might say retrieve did document
Will Abramson: Yeah, or execute resolution request...
Stephen Curran: Yeah...
Joe Andrieu: Uh, please, sorry, don't use retrieve...
Stephen Curran: Okay...
Joe Andrieu: Like, I think it's important that this step is resolution. This is what didcore defines as what happens here...
… And it would have a name conflict with the retrieval
Will Abramson: Mm-hmm, mhm...
Stephen Curran: Okay, that's fine...
<KevinDean> +1
Joe Andrieu: Uh, parts, which… which maybe we need to rename anyway, I just, you know, don't want to introduce that. Dual naming right now...
Stephen Curran: And then the first step should be prepare to dereference the did URL...
Will Abramson: Do you agree?...
Joe Andrieu: I don't...
Stephen Curran: Oh, okay...
Joe Andrieu: Uh, because this is dereferencing. Like, I think the first step of dereferencing is you have a URL and you need to prepare so that you can send it to Resolve...
Will Abramson: Yeah, so, um, I see you on the...
Stephen Curran: Okay, I see, yep...
Will Abramson: on the queue, I just want to highlight that this is… yeah, I… I mean, I know what mine is going to say, like, we are deciding on the did URL piece, um...
… maybe you should say that, but… I still just wanted to get, like, there is some alignment here that there are these two steps, like, we… there is some details about the steps that maybe we still need to discuss about, but
Otto Mora: Mm-hmm...
<Zakim> manu, you wanted to say we are agreeing to DID URL bit :)
Will Abramson: I guess the URL is an input. Anyway, neither...
Otto Mora: Man, yeah...
Will Abramson: Yep...
Manu Sporny: Yeah, so let's not get hung up here, and let's move forward. I'm asserting, like, Marcus is the only one pushing back that I know of on the URL as an input to all the algorithms, and I think we should just accept that and move on. I don't hear anybody else...
… objecting to that. I'd love to hear on the call if anybody else objects to that, but, um
Will Abramson: Um… my...
… Yeah
Manu Sporny: But… but we… let's keep going, because I think we're dangerously close to getting wrapped around the axle if we keep talking about this slide. Let's get to the other slides...
Will Abramson: Yeah, okay, yeah, yeah, good. We can go exactly, let's come back to that later, but uh… that's easy, right?...
… Uh, okay, and then I have some, like, sort of some, like, informational bits, so we can try and understand what we mean about the next bit, right? So we have the referencing did URLs
… The URLs might contain query parameters
… Right? And there are known queried parameters that we have to decide how to handle in the dereferencing algorithm. The service
… And the service type, and the relative ref, right? They're the only known query parameters that are part of the dereferencing algorithm
… And, you know, my observation was they're all related to services in the DID document. Like, we also have version ID and version time, but they're really part of DID resolution
… and one of the arguments why we should pass the URL, I think
… And then there's this weird one, which is really an option, and I put this in there because Joe's algorithm has completely removed it. There's this
… option, which actually I propose, like, verification relationship, which is a way to, like, target verification methods
… Uh, they're authorized for specific relationships in a document. And I just want to find out, if this is just getting confusing, maybe we just ignore it for now, and I'd be happy to remove it. Like, it's not like a
… critical thing, I just thought it would be a useful feature. Um
… And then… the other caveat is, like, we can't know all query parameters
… that we're gonna have to handle, right? Like, in this algorithm, so we have to have some space to support extensions. Um
… Yeah, and then just the existing spec text handles query parameters first in step 7. And even in, uh, 326
… the query parameters are really the things that are handled first, at least service and service type. I know Joe handles relative breadth a bit differently. Is there any other questions?
Otto Mora: Yeah, Steven is first...
Stephen Curran: Um, the only thing I'd like to add to this, and I don't want to go into any...
… Great conversation, but… and so we can… we don't need to
… dive on this, but Path should be part of… Um, this list
Will Abramson: this next, but I just wanted to separate them out, because I couldn't film the same slide...
… Yeah, yeah, totally
Stephen Curran: And again, not path service, path. We need to handle a path, and the spec just needs, and I don't care if it's path service or not, but...
Will Abramson: Yeah, yeah. I just wear them all. Uh, money?...
… Mhm. Hmm
Manu Sporny: Yeah, just to speak to… and this is a final analysis, Will, to speak to, like, relative ref, I really dislike it. I think it was a mistake, and we should remove it from the spec, but, you know, I'm happy to keep it there for backwards compatibility or any of that stuff. I think the PAT stuff is a much better way to...
… To deal with it. Um, and then the service and service type bits, I don't know how useful
… And the verification relationship thing, I don't know how useful that… those features are. Like, we put them in a long time ago. I can't even remember why we did it
… Um… I'm sure people have use cases for them, but I'm kind of like
… why can't that just be a part of, like, what you do during dereferencing locally? Like, do we… do we really need
… you know, maybe we define other algorithms to get to that data. Anyway, just a thought, like, I don't know who's got, like, some absolutely critical
Will Abramson: Oh...
Manu Sporny: Use cases for service… and service type and verification relationship. Um, that's it...
Otto Mora: Uh-huh...
Will Abramson: Yeah, you said something confusing to me then, because you said, uh, why can't it just be part of...
… what, like, the dereferencing that you do locally, but I think it just is part of dereferencing, right? We handle this query parameter. I mean, if we removed it, then
Manu Sporny: No, I'm saying, like, remove it as a query parameter, like, what's the worst thing that would happen if we removed it as a query parameter? Would people be totally unable to achieve their use cases?...
Will Abramson: Hmm...
Manu Sporny: Or would they just go about them in a different way? Like, I think the reason we put this in there is to, like, very specifically point out, like, a service, or a verification relationship, and be able to get, like, a subset of the did document out...
Will Abramson: Hmm, mm...
Manu Sporny: But I'm like, I can't even remember why we did that. Like, what use case was so important that we...
… we felt the need to do that. Um
Will Abramson: Joe?...
Manu Sporny: I've forgotten. I don't know if anybody else can remember, and if none of us can remember, then… and nobody's using it, then it's kind of like, oh, wow, we should probably remove that feature that...
<Zakim> JoeAndrieu, you wanted to ask Stephen about path
Otto Mora: Uh, okay, so we have Joe. And then afterwards, Dimitri...
Joe Andrieu: Okay, um, on the verification thing, uh, relationship real quick, I, uh, I...
… Um, I think I'm with you, Manu. It feels like it's
… It's something the application who's dereferencing is going to know
… Um, and needs to know, like, how you inspect the did document. Um
… It doesn't seem to affect either resolution or retrieval. Um, so those are the two litmus
… test that I would, um, consider for standardizing a service parameter that has, you know, that key value
… Um, but I was curious, um, Steven, about your suggestion that path be here. Did you mean that there should be a question mark path equals blankety blank?
Stephen Curran: No...
Joe Andrieu: Um… okay, because that is what we're talking about here. This is about the query part of the DIDs...
Stephen Curran: Um...
Joe Andrieu: So… that's good. I think we maybe are aligned. I thought maybe we were misaligned, because I… I interpreted your comment that way...
Will Abramson: And you shouldn't read into the ordering of this, like, I could have put path first, right? This is just information...
… If that was confusing you, Steve
Stephen Curran: No, the only thing was, I was seeing it as handling the non-fragment parts...
Joe Andrieu: Oh, the path part...
Will Abramson: Totally, yep...
Joe Andrieu: Yep...
Stephen Curran: So that's all. And so PATH would be included as a...
… As a thing that gets defined in this specification, that's what I was calling for, is making sure that
Will Abramson: Yeah...
<JoeAndrieu> +1
Will Abramson: Mm-hmm. Dimitri?
Otto Mora: Zoom Meetings...
Dmitri Zagidulin: I can only take a guess, uh, at why the verification relationship. was added to...
… Any sort of did client
… Does have, or many of them
… Do you have, uh, let's say a method, a function that says
… gave me a key for a given verification relationship. Meaning
… I'm fetching, uh, did, but really, I want an authentication key. Or, really, I want a, um, assertion method key to sign a verifiable credential
… So, that function… that abstract function
… is useful and does exist on most… on most did methods
… So that would be my closest guess for why it was added. Now, does it belong on the crane parameter level? No, I don't think so
… Oh, you added that. Oh
Will Abramson: Yeah, well, to be clear, it's not a… I added this this round, right? Like, it's, like, maybe a year ago, and it was exactly for that reason...
Dmitri Zagidulin: Oh, it's not a query. Ah...
Will Abramson: But it's not a query parameter, like, I first proposed it as a query parameter, and instead, it's like an option that you can pass in currently, in the current spec tape, it's an option that you pass into the dereferencing algorithm to say...
… to specifically say, like, I only want to find a verification method if it's part of this
Dmitri Zagidulin: Okay. Got it...
Will Abramson: But I agree, like, you can definitely… we don't… maybe we don't need to find that at all, like, people understand that, and… You know, this is just that, you know...
… Okay, great. Let's keep going, because we're out of time
… Um… yeah, so then I just want to talk to the path too, right? Like Steven says, we absolutely want to have a way to handle the path. Uh, the current spec
… is kind of hand-wavy about the path, right? Like, because we hadn't really figured out how to do it, and that was what Stephen tried to do with path service
… To figure out a proper way to handle path. I just wanted to highlight some of the different ways that path handling might happen, right? There's this
… Specific service types that are around or define how to handle a path
… There's these property extensions of the DID document, like this linked resource property
… There's, uh, you know, did document metadata, that's a did link resources approach, and then there's this other, like, again, hand-wavy thing that did method-specific
… Things might define path handling
… I think this is the question that really Joe has been trying to grapple with, like, given a path and a did resolution result, how do you identify and disambiguate the path handling approach?
… Right, or, I mean, here he says, how do you determine the retrieval strategy for this given path? Um
… So, I think that's the… the thing, like, how do you know what this path should be targeting? Like, where does it target in the resolution result?
… like, is it a specific service? Should it be applied to a specific service in a specific way, or is it a
… Document property extension, or is it applied to, like, some metadata?
… Uh
… That's all I have on that. Let's anyone on the queue. I'll keep going
Otto Mora: Um… No, no, no one on queue...
Will Abramson: Yeah, so then I'm like, okay, so what is step 3 of this algorithm, right? So we've done step one, we've done some preparation, then we've resolved...
… to get back the did resolution result, which includes, hopefully, the did document, right, unless it's failed. It includes the document
… Uh, so in the existing spec text, right, steps 7 and 8 of the dereferencing results algorithm
… Um, are handling the path and query parameters
… Right, currently, step 7 handles just the query parameters, and then step 8, sort of
… Hand-raised a little bit about how to do the path
… And in 326, there is this step 3, which is, you know, determining retrieval strategy
… Um… so, a retrieval strategy adds, like, okay, how do we actually retrieve this result? Like, if we
… Uh, found that the… the object that is targeted by this path
… or we found the retrieval… I think it's really, we found the retrieval strategy, how can we use that strategy to interpret the path, maybe?
… Um, and then just to keep on, like, identify resources might not be HTTPS URLs
… So, retrieval is not necessarily, like
… known, right? Like, the type of the thing should be explicit about how you
… how you use the hash in the… use the path in the did URL, combined with something in this thing that you've identified, to. execute a
… The retrieval of the results
… Uh, I think this is the most complicated one that we're definitely gonna have to dive into deeper
… But I wondered if we could just agree that the
… the purpose of Step 3 is, like, handling the did path and query parameters
… In order to identify the resource to be retrieved and how to. Go about retrieving it
<Zakim> JoeAndrieu, you wanted to mention we missed this: the type of the service needs to specify the retrieval strategy
Otto Mora: Uh, both, uh, Joel first, then Adam...
Joe Andrieu: Okay, um, yeah, it turns out, I think this was a very big gap in, um, our thinking about how service endpoints worked...
… Um, we have, for example, in the BTCR2 service endpoint
… Where we advertise the beacons for getting, um, uh, updates, or for
… for getting publishing of updates to a DID document. Um, we use a Bitcoin colon
… Uh, URL, and the default retrieval strategy that is to construct a payment
… address. Like, it's treated as a payment address, and you're expecting the wallet is going to populate a form that the user can just put in how many Bitcoin they want to send
… But that is not how you would use it if someone used the service parameter that pointed to that beacon
… And we did not define what you do, because we are just using that URL as a URI in BTCR2. Um, so that's sort of connected back to this work. Like, if someone put in
… Uh, question mark service equals, you know, my beacon ID that's in a BTCR2 document. Uh, we have woefully underspecified how you would retrieve that
… Um, and so that sort of just opened up the whole fact that for all of our service types
… Um, I think there were presumptions about how you might use it, um, and I think we need to
… Um, sort of socialize that, hey, these different service endpoints may have different mechanisms for interacting with what the endpoint value is in that service type
Otto Mora: Manu...
Manu Sporny: Yeah, plus one, uh, to what Joe said, um...
… Step 3 of the algorithm is the step after we have gotten the DID document and are exploring it
Will Abramson: Yep...
Manu Sporny: Right? That's… is that… right, that's… that's the step, and then… and then this is… this is the retrieval strategy thing that I think Joe's...
Will Abramson: Yeah...
Manu Sporny: talking about, right? Like, you have to figure out how you're gonna actually get the resource, and...
… Um, you know, the resource that you get back might be
… it's highly dependent on the service type. Is that correct?
Will Abramson: Yes, it's highly dependent on the...
Manu Sporny: Yep...
Will Abramson: the thing that your… your retrieval strategy, to use Jose language, and that might be… might be defined by the service type, or it might be defined by, like. Some of these other approaches...
Manu Sporny: Yep...
Will Abramson: Um...
Manu Sporny: Okay...
Will Abramson: So, so yeah, the input to step 3 is you have a did URL, and you have a did resolution result...
… and you're trying to get to the resource. Like, you're trying to find out, how do I get the resource using this information?
Otto Mora: Mm-hmm...
Will Abramson: So… do we agree?...
Otto Mora: Uh, Steven? Oh, sorry, sorry, not bad, not bad...
Will Abramson: Okay. No, no. Yeah. Thanks...
… I'll see this on mute
Otto Mora: Yeah, Steven, go ahead...
Stephen Curran: Uh, oh, okay, uh, thumbs up from Manu on… on that, by the way. Um, I… I don't quite get… Joe, what you meant by...
… Um, you get to a URL and you don't know what to do with it. Like, wouldn't the
… The prefix, bitcoin colon, tell you that you need a Bitcoin dereferencer
… Um, and that's what you do with it, and if it's HTTP, you do that. If it's a did. You would then
… Um… call another DID dereferencing operation to
… to process that did. So I think
… It's, it's the, the, the URL
… Um, protocol defines what you do once you have
Will Abramson: And...
Stephen Curran: Um, the resource that you're… that you're interested in...
… And it may have stopped at just the did itself, and you just returned the did doc
… Um, but if it's something… if there's a path and… and some query parameters that yield… that
… That get to another URL, then you process that URL, I think
Will Abramson: So...
Stephen Curran: that's… and I'm not sure that's what you said, I guess, and that seems...
Will Abramson: Yeah, so this is a little in the details, but let's take the queue, and then I do want to try and get through all of the steps, so… No, we shouldn't...
Otto Mora: Give me… oh, sorry, Joe...
Joe Andrieu: Um, yeah, so there… there is not a URL that can represent the resource, um… Uh, that is retrievable...
… in the way that you're imagining for BTCR2. Like, the… the
… That was what I tried to explain. Bitcoin colon is an IANA-registered scheme for URLs, so that's all good. But we… but in the BTCR2 method, it is not used as a payment
… Endpoint, which is how it is used everywhere else
… It is used as a URI simply to identify the Bitcoin address where you are going to watch payments
… And you are going to, uh, look at payments to that address
… to find announcements of updates to the DID document
… And so the way that you would retrieve the information if someone
… Identify that service endpoint as a query parameter, um, is just undefined
… It does not mean that you should make a payment to the payment address
… Um, that is not the intention of that URL, that is not how you would use that service endpoint
… Um, we need to define explicitly, for that type of service endpoint, how do you use that URI?
Otto Mora: Images...
Dmitri Zagidulin: And I think that last sentence there is key, about needing to...
… define it on the service endpoint level on how to use the URI
… So, I raised my hand, because I want to own a voice my… Sort of strong disagreement
… Uh, with the others on the spec, and it's right at this slide
… Uh, it's a… it's a minus .9, it's non-blocking, I'm not gonna formally object, but I do want to… Yeah, my objection on the record, which is
… This is where our spec should exit, and application code takes over. once you have the URL
… The… the did client
… gets the URL and passes it over to the rest of the application logic
… to the appropriate client that knows what to do with this URL. In the Bitcoin colon beacon
… sense, it'll be passed to whatever you can infrastructure. If it's, uh… BitTorrent?
… URL, then hand it over to the BitTorrent client. In no world do I want. Those kind of complex
… Clients and systems to be part of the dereferencer
… To me, the dereferencer just arrives at the URL, and it's the URL-specific client that takes over from there
… So that, that's, that's my main, um, point of disagreement. I don't think
… Uh, complex clients need to
… With their own authentication and authorization, with their own, uh, like
… full blockchain nodes or light blockchain nodes. With all of that, I don't think that stuff belongs in the dereferencer
Otto Mora: Mm-hmm...
<JoeAndrieu> you need the context of the DID document. the URL is not sufficient (keeping off the queue)
Otto Mora: Uh, Will, we have a handout from Steven that I'll let you decide
Will Abramson: Yeah, it was two savings, I mean, that was an interesting comment, thanks...
Stephen Curran: Yeah, I think that's really at the core of this, which is where does this specification not… and this specification doesn't talk necessarily about a comp...
… that does a set of things that this specification says, but where does this specification stop?
… Um, I… so I'm very much in favor of
… having Dimitri's conversation completed so that we get to agreement on where it stops
… Um, I would add that if you get a fragment that points to a verification method
… the spec says, here's what you do when you have a verification method. So… The spec doesn't really stop
… even though you finished it, you know, you finished return to DIDDOC with a fragment on it, because the spec also tells you, hey, now that you've got that verification method, here's what's in it that you can do, and here's what you can use it for
… So, it really is an interesting question as to where the spec stops. I definitely agree with Dimitri that. The
… A component that is a resolver should not go off and arbitrarily
… Um, try to process arbitrary URLs, so that is, you know, a completely rational
Will Abramson: Mm-hmm. Yeah, I see Joe on the queue, but I do want to just go on, because I think I get to that also, right? So, like, this step was to follow Joe, like, to determine the retrieval strategy, in other words, that, you know, maybe might be, like, construct the URL. Although I thought maybe there were some things that...
… might not result in a… you might have a retrieval strategy that doesn't use a URL, maybe? But I wanted to go on
… Because the next question was, what do we do next? And I think that is, to Dimitri's point, like, do we actually
… go, you know, once we've got this URL, or we have some retrieval strategy, are we actually
… doing the retrieval. And currently, in the current spec tax, we do not do retrieval. We return
… These are the things that we return in the spec. I did document… I did document with updated services, so that might be, like, you targeted specific kinds of services
… in the document, or an array of one or more URLs
… Um, as far as I could tell, that's the only thing the current spec, um, returns, right? Nowhere in the spec are we actually
… executing a retrieval on any of those URLs. Whereas in 326, very different. There is
… You've determined the retrieval strategy, and then you are retrieving
<Zakim> JoeAndrieu, you wanted to comment (if we going to talk about this now)
Will Abramson: Uh, so, I don't know if that is to what you want to say, Joe, but you can speak now
Otto Mora: Joe?...
<swcurran> +1 to Will
Otto Mora: Joe, you're on mute
Will Abramson: Maybe a mute?...
Joe Andrieu: Oh, I was going so good, too. Um...
… I want to say, I think the URL is not sufficient, so Dimitri and I are in pretty strong disagreement here, um, and in particular, in the linked resources
… The entire point is to provide the metadata to do data integrity on the results… the resource you get back
… So, if all that goes back to the outside world is a URL, then who's doing the integrity check?
… And so, um, that whole use case is invalidated if we strip away and just give a URL to the caller
… the dereferencer needs to understand that, hey, from the did document, I'm using these properties
… after I get the resource back to make sure that I got the intended resource
<Zakim> manu, you wanted to note it wouldn't be the end of the world if we just stopped before retrieving the resource and deferred to other specs to fill in the gap?
Will Abramson: Mine?...
Manu Sporny: Yeah, I mean, plus one to what Joe said, like, you do need that information to make sure you're getting the appropriate resource back. Um, I'm wondering if it… I don't think it would be the end of the world. If we just stopped...
… short of retrieving the resource. Like, we could define how to retrieve some resources, but for other resources, I mean, clearly we need, you know, extensibility here, and we just say, like
… you know, you may have another spec that you care about to retrieve the resource, right? And I know this is a massive hand wave, but, like, do the appropriate thing according to that
… Uh, resource retrieval strategy that is not in this spec, but clearly, you know, you, the implementer. Um, a client want
… I think there's a, you know, a point of diminishing returns here, right? Um
<swcurran> +1 Manu -- but the spec COULD have the "what to do"
Manu Sporny: I don't… like, not defining something is not the end of the world. Like, people will figure out how to achieve their use case, right? It does harm Interop a bit, but, you know, I don't know if
… And I'm sure there's disagreement on it, but, like, if we get to 80% of the cases, I think we're in good shape
… Right? And the other 20% of the cases are defined in other specs, are implemented in other ways, and we get some
<swcurran> +1
Manu Sporny: you know, um, and we don't prevent them from doing what they want to do. Like, so the, like, the Bitcoin beacon stuff, I think, is a great example of that, right? I don't think we'd ever
… write exactly how that works into this spec. We would probably just make sure that it is possible to define that elsewhere, and this spec doesn't get in the way
… of that… that other spec, that details, um, how you get that information, and make sure, you know, make sure that you're getting the right thing, and so on and so forth. Um
… So, I want us, you know, ideally we… if we can't get to agreement on this
… I don't think it's the end of the world if we… if we leave some… some parts of this out of the spec
Will Abramson: Yeah, okay, thanks. So, I see the two on the queue. If you could try to be brief, because I do want to get to the last slide on this, but, um, let's go through it. I think...
Otto Mora: Mm-hmm. Let's see, meet you first...
Dmitri Zagidulin: Uh, two things. Two things. Uh, one is, I don't think Interop is harmed in any way. It's just that interop is handed over to another spec. If the resolved...
… URL is FTP, it's handed over to the FTP stack for, uh, spec for interop. If it's a bit… if it's a Bitcoin, over to the Bitcoin stack. Same thing with BitTorrent, HTTPS, and so on
… Interop not harmed by the fact that we don't embed. The infinity of other specs into this one
… Uh, the other thing I wanted to address Joe's point about content integrity. Content integrity is absolutely a really important use case
… that doesn't mean that fetching the resource should be the provenance of the spec. It just means that, okay, don't return just a string URL, return a tuple of
… string URL, whatever content integrity, and then pass that over to the client that knows what to do with it. That's it
Will Abramson: Yeah, I think there's a little talking past each other here, but I think Joe will speak to it, so… Joe?...
<Zakim> JoeAndrieu, you wanted to say that is the language in #326
Joe Andrieu: Um, yeah, I think we are talking past each other. No one is suggesting that we define all of the strategies here...
… in this spec, certainly not how you interpret Bitcoin, um, as a URL
… Um, the, uh
… This… what… particularly what Will has been trying to get our attention on is that the how is determining how we retrieve it, which means which specs
… are we going to rely on to define how we do it? Not that we are writing all those, um
… uh, mechanisms for retrieving. We're not trying to pull all those specs into here. We're just saying, at one point in the process, in order to get a resource back, you have to figure out how to get the resource
… And the type property is, um, a really good anchor for a service endpoint to understand how to get that service endpoint
<dmitriz> "how we retrieve it" -- again, that's the jurisdiction of the app logic, not of our spec
Will Abramson: Yeah, great. Okay, I'm gonna whip through this, because this also speaks to, like, why we might want to retrieve the resource, I think...
… Uh, right? Like, it's the fragment, and currently, in existing spec, we have this, like, dereferencing the fragment
… section, and the fragment either identifies an element in the document, or currently it's appended to
… uh, selected bid service endpoint URL, and I said, oh, I guess all of them, if there is an array. But the thing is, the result is never retrieved here, so, like, the fragment really is targeting something. In… in that resource
… uh… you know, I think we all are in agreement that the fragment is handled… this process last, after
… the primary resource is retrieved, but it seems like in the current spec test, we kind of are thinking that the primary resource is just this URL, almost
… Um, so… there's that. I think I have another slide, so I don't think I'm here, I'm just gonna keep going
… Uh, there's just one more. Oh, right, there's a couple more. But I think I wanted to get to… I mean
… This was my attempt to just put language on Joe's and see if we have agreement. Um… So maybe I'll stop there, um
… And… or we can go back to the fragment and discuss that in more detail. Oh, I had a different slide, actually
<dmitriz> and same thing with the fragment
Will Abramson: I mean, we don't have long. I mean, these are literally Joe steps, and I think all of them could be open for
… Uh, renaming or, like, debate, but, like, for me, going through this and having both specs side by side, this did
… make good sense to me. I think Joe did a good job here, at the high level, and I think, you know, the hard part is
… is 3, we're going to have to do this similar kind of thing and dig into, like, okay, what are the steps in 3, and how do we want to prioritize that?
… Yeah, and
Manu Sporny: The input in 4B is unknown right now...
Will Abramson: Uh, yeah, I wasn't sure what that is, like, I mean, I think it's the same with his output, like, what is the output from the retrieval strategy? I feel like it...
Manu Sporny: Yep...
Will Abramson: I… I don't have full clarity on it. I think it's, like, there is the retrieval strategy, but is it the object that, like, has a type and a URL, and the type defines the retrieval strategy? Uh, yeah...
Dmitri Zagidulin: I, again, I think the fragment handling is also easy...
… In the sense that URL spec, uh, tells us that fragments belong to the media type
… Of the resource, which means it's the client that knows how to fetch the resource will also know how to
… process the fragment. Meaning, you hand it off to, let's say, a JSON-LD client, it'll know how to process JSON-LD fragment
… if you hand it off to a PDF client, it'll know how to
… process that fragment. Again, this is outside the scope of our spec
Will Abramson: So, Dimitri, are you saying we should stop at 3?...
Dmitri Zagidulin: Yes, and 3 was not in our spec, but in the outer application code...
Will Abramson: So then it's like, what is… we're not really defining anything here, it's dereferencing, we're just saying resolve… you know, prepare the URL and resolve it...
Dmitri Zagidulin: Well, and that's my whole point. Uh, point of our spec is to get the URL, and then hand it off to the client that knows what to do with it...
Will Abramson: I think that's what we're trying to find, isn't it? This client that knows what to do with it?...
Stephen Curran: Mm-hmm...
Dmitri Zagidulin: But that shouldn't be… we can't define it in our spec. That's in the outer code...
Will Abramson: I see there's just 2 minutes, so, uh… Manu?...
Manu Sporny: I mean, plus one for this being, you know, the five algorithms that are under discussion, and we're gonna go 1, 2, 3, 4, 5 until we get disagreement at...
… the later algorithms. Like, you know, for example, I think Dimitri's disagreeing with 3, you know, I might disagree with 5, but, you know, 1 and 2 is… we can definitely break
… the algorithm up into those things, and plus one to the purpose inputs and outputs of each. I mean, I think that's clearly defined. So, I mean, if we break it into PRs that are split into each one of these pieces
… At least, you know, they layer on top of each other, it's very clear, you know, what we're doing in each step, and it's not some giant massive algorithm, which is. Currently, what we have, right?
<dmitriz> again, I'm not going to formally object. so if everyone else feels that the dereferencer also needs to include the resource clients, I can live with that. (and by live with that, I will ignore the spec in my implementations)
Joe Andrieu: I'm… I have to… I have to interrupt, Manu. These are not separable from the current algorithm. Like, the current algorithm...
… Doesn't map to these 5
Will Abramson: I think we have to almost...
Joe Andrieu: like, I think you would break the current algorithm if you just tried to put one in...
… Anyway, I'm open to people suggesting PRs, but I literally tried to do that and ran into a brick wall, so
Will Abramson: I mean, I think at this point we almost should break, or maybe we should leave the current algorithm in, redefine it, and then delete it, I don't know...
… Anyway, I see we're out of time. This was… Oh, you wanna go, man?
Manu Sporny: Plus 1. I mean...
Will Abramson: Yeah...
Manu Sporny: No, clearly we need more discussion on this, but I'm just trying to get to, like, concrete steps that we can actually start raising PRs on. Um, I didn't quite understand what...
Will Abramson: Okay, well, maybe we can talk about tomorrow in the editor's call as well. Uh, I think this was really productive, actually, uh, and it was helpful for me, just...
… go through it in a little bit more detail. Hopefully it was helpful for others. It's a shame Marcus wasn't on the call, but
<ottomorac> transcriber-bot, pause
Will Abramson: Um, yeah, we will talk more about this, and we'll certainly be talking about what free contains. Uh, in a lot more detail