Meeting minutes
<ottomorac> transcriber-bot, connect
<ottomorac> transcriber-bot, pause
<ottomorac> transcriber-bot, resume
Agenda
Joe Andrieu: Howdy. How's it going?...
Otto Mora: Good morning, Joe...
… If
Otto Mora: Alright, so I think then we would be good. Let me just, uh
PR 344
Otto Mora: And then transcriber part
… So, uh, yeah. So the topic for today is, uh
Stephen Curran: Okay...
Otto Mora: a walkthrough of a presentation, uh, prepared by Steven, uh, to help us kind of review some of the comments and suggestions on PR344...
Stephen Curran: Oops. Yeah. Okay. Hopefully, people can see that...
Otto Mora: Um, and then we'll be walking through that. The link to it is here. Paste it here and in the zoom app...
Stephen Curran: Um… let me see...
Otto Mora: And...
… I guess, uh, that would be the main topic, any… suggestion from anybody before we dive into the presentation. Let's even do the driving
… Okay, any suggestions?
Stephen Curran: I can remove this. I'm in section 611...
Otto Mora: Uh… perfect. Go ahead, Steven. Yeah...
Stephen Curran: Hopefully that'll help. So trying to get to merge, that's our goal here. What I did was scan the PR, collected the open points of discussion, put into slides with links. Um, and then...
… User of the implementation get to that selecting of the resolver
Manu Sporny: Yeah, I...
Stephen Curran: So let's see how this works. So the 1st issue is. Section 611. So if I click on this link, takes me to Joe's PR...
Manu Sporny: Okay, thank you...
… Uh, yeah, um… It's fine to be vague about this, um
Otto Mora: Go ahead...
Joe Andrieu: Sure. The implementer is whoever is writing the client software. The client software is executing this algorithm. The algorithm must choose a resolver to talk to...
Manu Sporny: But we do need to be clear about, you know, what's actually doing the selection. I think the text is pretty clear. as if… the text could be clearer. At the very end, it says, implementers must enable users to choose the resolvers they trust...
Stephen Curran: Um...
Joe Andrieu: And the user has to be able to, um, decide which resolver is used...
Stephen Curran: Number two here is to select a resolver that is capable of handling the DID methods. And the question that comes out, let me make sure I can jump back. Yep. The question that comes out is...
… Um… Who is selecting the resolver and what is the mechanism they are using to do that? And
Manu Sporny: for a specific DID method...
Joe Andrieu: In some manner, in the same way that you get to pick which website your browsers go to...
Manu Sporny: Um, okay...
Stephen Curran: And related to that is, how did that… how does an implementer, as it say, have a must involved? And that's where I wasn't sure. I think I'm the main one asking about this one. I wasn't sure how...
Manu Sporny: I don't know how we actually enforce that in a testable way in the test suite...
… uh… I would suggest we remove that must statement, and just make it a statement of fact. Um, you know, implementers enable users to choose the resolvers they trust. Um… and then the… I think that the thing that's tripping me up is, like, who selects a resolver? Um, it could be
… You know, it's the software selects a resolver based on user preference would be one way to state it to make it a little more clear, because everything that we're writing here is for the software implementation, I think
… anything testable here that we're writing is for the software implementation, right? Um, that's the only thing I'd suggest here. Like, I think it's fine to be vague about, like, how the selection happens, but we do need to say, like
Stephen Curran: Um...
… Who the… who the implementer is in this case, and then how does the
Manu Sporny: Ultimately, the software chooses a resolver based on user preferences...
… And then this could be a remote resolver or local resolver
Otto Mora: Alright...
Stephen Curran: So, over to Joe, I think, to start...
Otto Mora: Okay, so we see Joe in the queue, and then after that, Marcus...
Joe Andrieu: Yeah, uh, Manu, I wasn't clear about what you thought was just clear, so, um, might be useful if you have some proposed language. Um, I really just didn't follow. Um...
Stephen Curran: Okay, Manny? And we're using the queue. So go ahead. Sorry...
Joe Andrieu: To me, this seems easy to test. In your test suite, you have included the profile of what test is happening, the resolver that the test writer wants to be tested for that. And if the software can't handle that the resolver is being set in some way, um… then, uh, we would know that they're not able to be, uh, reflexive to using
different resolvers than what the software is already configured for. Um...
… uh
… The
… The point here is that it's the… if the user doesn't… isn't choosing the resolver, either through some preference interface, or by specifically selecting it in real time. Then we're just building a walled garden where the the client to resolution decides for the user And that is, I think, not only antithetical to our decentralized mission,
it violates our security model
… Where the user fundamentally has to be able to trust the resolver that they're using because they are not the ones who are going to be able to validate what the resolver is doing. You have to have a trusted relationship there. So the client software should not be mediating that question. The user should be in charge of
… Pointing to whichever resolver we go to
Otto Mora: Okay, Marcus...
Joe Andrieu: Um...
Markus Sabadello: Yeah, I think it's good that we say something about this. And obviously, I also believe it's important to be able to choose what resolvers to use...
Joe Andrieu: And I I think it's it's core to our security disposition...
Markus Sabadello: Um, I'm… I'm not sure if this is part of the algorithm itself. I… I feel like it's… it's a little bit out of scope of maybe this section, at least. It's...
… It's a bit like, if you imagine the HTTP specification, that doesn't say that the user must be able to choose between browsers. I feel like it's not part of the algorithm itself, but it's something that we can
… Uh, covering
… in, uh, architecture section or security considerations. I'm… and I'm not sure if I agree with the must statement here. It would be a bit like saying that if you want to be
<manu> Maybe we could change the text before the list needs to add something like: "An implementation does the following:"?
Otto Mora: Yeah, go ahead, man...
Markus Sabadello: conformant with DNS and use DNS, then you're only conformant if you allow people to choose the DNS resolver, but I think in some cases. there are also applications, uh, where you just have a built-in resolver, right? And let's say for these, you have some...
… constrained IoT device that wants to use this, and now you maybe can't build an elaborate system to configure what kind of resolver to use, because you just have a built-in one that's working fine. So I think it's a good idea to say a lot of things about this
Manu Sporny: Yeah, I suggested some language in IRC, Joe, uh, that doesn't have a must in it. I think maybe in prepare for resolution, we just have something before that that says an implementation does the following...
Markus Sabadello: Just not sure if it's...
Manu Sporny: Um...
Markus Sabadello: A strict must statement...
<pdl-asu> +present
<Zakim> JoeAndrieu, you wanted to say that's the entire section
Manu Sporny: Because I think that is what we're saying is like, the spec is written for, you know, an implementation, an implementer that's implementing an implementation and the implementation must do the following four things, or the implementation does the following four things. I'm taking must out of there. The… I… it sounded… what you
said sounded workable, Joe, but I was working on the text and I missed it. How… how...
Joe Andrieu: Um...
Manu Sporny: How does the test suite work?...
… Test that statement at the end of two
Joe Andrieu: The...
… To answer your last question, the… the… my understanding is how we're testing any of this is that
… The, uh
Otto Mora: Go ahead...
Joe Andrieu: The software being tested...
… Provides a profile of the test that it has implemented so that we can test it just for those things. And they include in that the metadata needed to do that test. Um
… Because we've not standardized how you set it
… There would have to be some way to communicate that to the test algorithm. And so the part of part of what maybe is confusing here with our previous test regimes that we had
… Is that this is the implementation algorithm. So it actually got on the queue because you use a phrase saying that we need to add the language. Um that an implementer that's implementing must do or does these things
… That's what this whole section is
… Like, that's what the DDDRLD referencing algorithm is, is that client software and implementation of the spec does these things. So we could repeat it on any number one of these bullet points, but that is the point of this section to explain what a client does
… Um
… I'm I'm confused why the I mean, if if the if your opposition to the must is just that it's hard to test. Then we probably need to rethink how we are testing this implementation
… And this algorithm. Because we're not testing an endpoint like we will be for resolve. Right. The resolution endpoint has clear inputs and outputs. And we can run against that. But this whole implementation algorithm
… Is what a client needs to implement. And we haven't really talked about how do we know that that implementation is happening. Because there isn't a clear input and output. That's part of the design algorithm here is because reducing it to the inputs and outputs led to more arguments than
Otto Mora: Uh, Steven?...
Stephen Curran: Um, I'm...
Joe Andrieu: clarification, and I think created… concerns about security and function and privacy and all sorts of things. Um… so maybe there is a bigger question about how we test this algorithm in general?...
… Um
Stephen Curran: I'm not so much questioning the why, but the how, as I think Marcus and Manu have mentioned, is the difficulty there. Your use of the term client threw me off, but then you used the term user. So, are you envisioning that. Did URL dereferencing is an algorithm?...
… As is the resolution, and that something in
… invokes it, and that's what you call the user. So the use… so there's this standard software, a client, and a user invokes it. And… and then it… that client, as you called it, takes over
Joe Andrieu: But I'm not sure best how to resolve that...
Stephen Curran: and runs through all of these steps. And and so the and and so I'd like to clarify that. And then...
… somehow the user has to signal to the client, hey, I want you to use this resolver, and it's that that I don't understand. So I… that… my model was that, that
<Zakim> manu, you wanted to ask where we say that? I'm looking...
Stephen Curran: Something is calling a implementation. And, it's got to somehow. convey to that implementation, hey, I want you to use Fifth Resolver, and that's what… where I'm a little lost
Otto Mora: Okay. Thanks, um, bye now...
Stephen Curran: That's it...
Manu Sporny: Yeah, so just to be clear, Joe, I'm not opposing anything. I'm trying to help with the language here. I'm fine with the way a lot of this is written, but I'm thinking about our company has to implement this and I don't want us to get tripped up implementing it in some of the things I'm seeing here...
… you know, I can see our engineers coming back to us and going, like, how do I do this, right? And I agree that it's the test suite that needs to figure out a way to test this, but again, like, you know, we need to, we need to figure that out. So I don't want this to be, like, an adversarial, like, I'm opposing this, it's, I'm trying to figure
out what kind of
… language would not have our engineers coming back to us repeatedly asking us what, you know, particular statements mean. Um
… The… I also agree that, you know, this entire thing is supposed to be for… You know, implementers… It's meant to be instructions for, uh
… uh, implementation… implementers implementing implementations. Uh
… Sometimes in our conformance section, we have four different classes of things this could be talking about. And in the conformance section, we do specifically call out did URL dereferencing and a conforming did URL dereferencer does. You know, these, these things, um
… But then, when you go down to the section, there is no text in there. I'm saying the text is missing where we're like, Hey, you know, this is what a conforming blah blah blah implementation does. You could argue that that's repetitive, and we don't need to repeat ourselves there. But currently there is no text specifying like this section is
<JoeAndrieu> to your Q in chat, that particular section that explains the algorithm's purpose should be at the top of 6. Agreed. That is missing.
entirely
… you know, for people doing implementations to do. So an implementation in 6.1.1 is expected to do all of these things, or an implementation in section 6.1 is expected to do every subsection
… in here. That's the clarity I'm trying to get to
… I think it's easy. We just stated clearly, right? I'm just looking at Section 6
… No text section 61 no text you know and then we go right into validate that the input did URL conforms to OK who's supposed to be doing that validation. Is it the implementation? Is it the I mean clearly it's not the user but we don't
… you know, it could be any class of, uh, uh, the conformance criteria. That's what I'm trying to get to, is, like, we need very clear statements saying who's supposed to be doing these, these four steps. Um… That's it
Otto Mora: Um, Manu? Oh, sorry, Marcus. Go ahead...
Markus Sabadello: Yeah, about the testing, I didn't really understand why...
… I'm not sure you thought that the referencing was hard to test. I mean, you also said there are no clear inputs and outputs, but
… That's not really my understanding, I think, for dereferencing, just, like, for resolution
… We have inputs and outputs. We also have the HTTP binding. There are multiple implementations of that. I think we even have a test suite already for. Some of the dereferencing, uh
… functions, so while I… while I agree that the referencing, just like resolution, should happen on the client side as much as possible, I don't think it's, uh, hard to test
<Zakim> JoeAndrieu, you wanted to note the current text is in conformance A conforming DID URL dereferencer is any algorithm realized as software and/or hardware that complies with the relevant normative statements in 7.2 DID URL Dereferencing.
Otto Mora: Okay. Joe?...
Joe Andrieu: Right So to to go maybe in reverse order...
… Marcus, what's hard to test is that we do not have a function with clear inputs and outputs
… That is what this algorithm is dealing with, which is the fact that reducing to specific functions and specific outputs made common usage of how you use resolution results non-conformant with the specification
… The fact that we had this strict input and output idea that implementers must implement broke common implementations that nevertheless were doing things like verifying a proof on a VC without ever having this kind of function that was required in the specification
… So the design here is to talk about the algorithm that is executed, which could have many side effects, such as rendering something on a screen, which is not a returned value from a function. So that's you and I have always had a
… a different way to think about this algorithm. And this is an implementation, so that we get around the complexities that we'd otherwise have to fight about in terms of what options are passed and what return values go to whom and what is required in that whole process. We are not talking about a standalone library. This is maybe jumping to
Steven's comment. We're not talking about some sort of library that someone calls. We're talking about a process that runs
… That a user interacts with, like a browser
… Most people do not use browsers in the way that we might use Curl or Wget or something like that. We run the application. And in the application, we do things, we have gestures, we click on things, and as a result of that, we go to the websites that we choose
… And there are issues with sometimes you can get phished and you go to a website that was fraud, but that's because every system has failure modes. But the browser is based on the fact that I don't have to just go to the places that are vetted by the browser maker. Right? Um, Safari, I'm not restricted to only the places Apple likes. Um, if I
use Chrome, I'm not restricted to only the places Google likes
… Um and so the the client is run by the user
… And the client needs some way to be able to, indicate which resolvers they wanna use for which did methods. And it's perfectly fine if there are defaults but the user has to be able to override those defaults or we're just allowing every client implementation
… to override the resolver choices, which I think would be really unfortunate. To get to Manu, who's in the middle, actually, we could and should have some language. I think the legacy reason we don't have the language is in conformance
… The pattern that we have had is, um, actually in there right now, it's pointing to the wrong section, but that's because our document is not coherent right now. So the language about conformance says that a conforming, um, a URL dereferencer
… implements the the algorithm in did URL dereferencing
… Um, so I'm… I'd be happy to copy that over, I agree. I… I actually thought it was in 6
… Um, and I thought you were asking it to be in that particular line, and so that… that was the redundancy I thought was there, but it's not. I agree with you, we should add some clarifying language
Otto Mora: Thank you, James. Uh, well...
Will Abramson: Uh, yeah, I just want to maybe add some… a different analogy to show you the browser, but just speaking to Steven, like, I like to think of this like MetaMask, or something like that, right? You install this thing in your browser...
<markus_sabadello> Existing tests for DID URL dereferencing: https://
Will Abramson: And then Metamask is acting as the client, right? And it's, you know, dealing with the blockchain and, like, the addresses. But in Metamask, in your client's application, you can go in there and, as Joe says, override the default rate. And in this case, you're talking about
… Which, like, blockchain nodes are you talking to? Ah, for which blockchain?
… So, you know, they have some defaults which talk to, like, sort of hosted nodes endpoints, but you might want to run a local node, and you might want your Metamask client to talk to that local node. And absolutely, it would be terrible if Metamask didn't allow that, right? People wouldn't accept that, they wouldn't use it, they would use
something else
… I… but I think, like, that example to me also does make me think
… like, the place where we have this text in the spec today doesn't… like, it does feel a bit out of place. Like, I think we definitely want to be talking about this, but I don't know if it makes sense to, like, talk, like, in… the… in a step of the algorithm? Because that kind of, like, makes me think, like, every time this algorithm is
executed
… we should be asking the client, like, which resolver you're gonna… which resolver do you want to use? It's more like these… this client should have a list of resolvers that they use, the specific bid methods, and they are selecting from there, and that list should be
… Uh… Editable. Configurable. By the… User of that client
… So I don't know where that goes. I mean, I don't know what Joe thinks about, like, moving it somewhere else. Like, maybe just moving it to the top of this section as part of the introduction to this entire dereferencing algorithm. um… I don't know if that helps, that's just how I think about
Otto Mora: Is that akin to almost, like, uh, your DNS servers on your computer? Kind of like list of resolvers...
Will Abramson: Mmhm...
Otto Mora: No. Maybe. Okay. I just wondered...
Will Abramson: Yeah, maybe...
<Zakim> manu, you wanted to speak to details.
Joe Andrieu: Yeah, I would say, yeah, I think it is why we have the flexibility and problems we have with DNS...
Otto Mora: Got it. Thank you. OK, Manu...
Manu Sporny: Yeah, I mean, plus one to that. I think we agree on...
<JoeAndrieu> I wouldn't mind moving that MUST up to the top of the dereferencing section and out of the flow of the algorithm
Manu Sporny: what we're trying to achieve here. I think we're just talking about the language. Um, I guess going back to, you know, the implementers must enable users to choose resolvers they trust for specific DID methods, I think we're all on… we're all on the same page there. We want that to be
… true. Joe, one of the and we don't have to address this right now. Right? But I'm just noting my my, you know. What about if an implementer knows that a particular did resolver is attached to a botnet or a criminal network, or whatever. And even though the user wants to use it, the implementation is like, no
… You should not use that. I know it's a known bad actor. Just like, you know, when you go to a known compromised, you know, site, the browser renderers jump in, and they're like, hey, sorry, like, this is a known phishing site
… Uh, you know, or, or HSTS, you know, it's like, hey, you turned on HSTS, and now things have changed, and I don't think you should go to this website. It's, it's stuff like that, where a line like, implementers must enable users to choose, and it's solved by something
<swcurran> +1 to Wil's comment -- very helpful analogy -- and the config idea is good as the mechanism I'm looking for.
Manu Sporny: Saying, like, you know
… reasonably choose or or choose safe, or which which opens up its own, you know, can of worms. So I don't know what level of nitpicking we want to do on this right now. I think you know we we've mentioned the concern here. It's on the
… You know, minutes, maybe we can move on. I'm sure there are many other slides for us to get through and we're halfway through the call
… Going back to Steven, do you feel like we've addressed the concerns that you've raised, or do we
… Is there something that has remains, you know, unresolved?
Stephen Curran: Um, yeah, I finished my comments on it. Um, I loved Will's… Will's analogy, and that was very helpful, and, like, the idea of repositioning it, but yeah, I'm done, and I see there's people on the queue, so...
Otto Mora: Go ahead, Marcus, and then we'll let just Joe close the section, and we'll jump back on the presentation...
Markus Sabadello: No, just I agree with what Will said. It would feel better if this was part of the introduction, not in the algorithm itself...
Otto Mora: Nope...
<Zakim> JoeAndrieu, you wanted to discuss "known bad actors"
Markus Sabadello: That's it...
Joe Andrieu: Um yeah so plus one to moving it to the front um I think the language explaining you know that this is the conformance class uh algorithm that implementers implement at the top of six I think that's a fine change to get it out of the flow I agree with Will's point like it reads as if...
… There's a pop up every time, and that would be horrible. But I did want to gently push back against the idea that someone else should be telling me what known bad actors are. I have benefited from Google doing exactly that interruption when I click on a link at Google search
… Um, and it was useful, and so warnings are fine, but if Chrome doesn't let me go
… Um, that's… that's a real problem to me. Um, and they are currently implementing things like that, and I think it's atrocious. I think it's a control framework. I don't… I think the moral authority about who is good or not is up to the user, um, and not to some nanny state architecture, whether it's a corporate oligarch or it's the nation
state. So
… But let's move on. I think these are hopefully what I'm hearing is if we could move that must into the description, we have a better description about how the implementation of a conformant dereferencer would use this algorithm
… If that addresses folks concerns, then I think we can move forward
Stephen Curran: Cool...
… Alright, uh, next one
… Um, part three, we're up to part three of that same section, so we'll jump back to that section. Um, remove any fragment. Um, I think
… The intention, and I think Marcus has raised this in his comment, I mean, ultimately what we're doing is removing everything except the DID, and I think an alternative wording that might be better would be because the query parameters in the path also need to be removed, simply extract the DID from the DID URL. So let's jump to that, um
Joe Andrieu: Uh, yeah, plus one. That's an easy fix. That's just legacy...
Stephen Curran: Item 3. So remove any fragment. I think we actually need to remove more than the fragment. And that was the where that comment is. And we'll go to Joe. Cool. Excellent. Any other comments from anyone?...
… Jump on the queue
… Excellent
… 2 in 30 minutes, look at that, averaging 15 per
… Okay. Prepare did resolution options
… Um, a couple of things on that, um
… There aren't any details about preparing the data resolution in the link section, so if we look at the text
… It says see the resolving algorithm for details, but there's really no details about preparing good resolution options. There is
… Um, specific data resolution called out, and there is… um, the… the resolving algorithm looks for often, but this is preparing those oftens. That's one. And then my comment adds to that, which is, any
… Options that the client sees as being… or, sorry, any parameters that the client sees as being
… part of bid resolution should be converted into auctions, and to me, that's what preparing the bid resolution auctions is about. And so, I wanted to raise that
Joe Andrieu: Yeah, I think there are two things going on here. One is this PR was just to be about dereferencing...
… So my presumption is that the definition of resolution and the section on resolution options explains what options you would choose and when
… What I do push back on is that the disposition should be that the user translates all of the query parameters into options. I think that is the security problem that we're bumping up again when we blindly pass options we don't understand
… And so the client's job at this point is to understand the options and to pick those that are appropriate
… Um, and those may or may not come from the query parameters. The query parameters themselves may not be relevant to what I'm doing. I may have a query parameter that has a version time, but I'm looking at a log file from a month ago, and so that version time is not appropriate to the analysis that I'm doing right now. And so I should not
propagate the version time forward. I should think critically about what options, and I should use the section about resolution, resolution options to figure out which options are appropriate. That's why I just hand this
Will Abramson: Hey, Ryan. Uh...
Joe Andrieu: section over to the resolution algorithm...
Will Abramson: Yeah, uh...
… I just had one comment around, like
… I just had a look at this text and where the link goes. I mean, currently this link's going to the algorithm, right? Section 4.4. I think
… Probably it would be fine if it went to Section 4 on Section 4.1. You know, Section 4 is all about the data resolution options, and maybe we need a little bit extra text in there, but at least it defines what those options are so that you can have some help when thinking about. The structure of the options you are trying to prepare
… um
… That's all I have
Stephen Curran: Um, Marcus?...
Markus Sabadello: Yeah, I think we've talked about this topic...
… several times. I remember not long ago, we had this proposal that the entire DTRL should be passed to the resolver. One of the arguments was that supposedly only the resolver knew what to do with the parameters and with the options due to. The confused deputy risk. Now I'm
… I'm happy that we're back to a design where we don't pass the entire URL
… to the resolver, and now I'm hearing that
… Client should somehow decide
… which parameters to pass as options to the resolver and which ones not to pass
… I'm not sure, I also had a presentation about this a few weeks ago in the
… In the current algorithm, the currently referencing algorithm, the way it's written is that the… Client passes all the parameters as options to the resolver, plus the… The reference in options that the
… Client wants to
… I want to use separately, and those would override the. the parameters, that's how it's written right now, which I think… is a start, but I also recognize some… Potential security aspects here
Stephen Curran: Okay, um, I'm on the queue, um...
… Yeah, it's… to me, the con… This doesn't say anything about what
… the client or the user are supposed to do, and that's what's throwing me off. Um
<markus_sabadello> Language in current DID URL Dreferencing algorithm:
<markus_sabadello> "All dereferencing options and all DID parameters of the input DID URL MUST be passed as resolution options to the DID Resolution algorithm."
Stephen Curran: I've got an example that I gave that I actually did put in here, which is about a proof. I've got a proof and it's got a DID and a key ID in it. When I reference the DID URL, I want to stick version time in. As the time that it was signed. I think I'm a user in that case, and I want to pass that, and I expect the client to pass that on to the
resolver. That's my expectation. Now, that
… Same URL with the time and the ID could be what's in the proof
… But that's up to the user to decide, not the client, and that's why I'm confused as to where
… Um
<Zakim> JoeAndrieu, you wanted to say the resolution options does link to 4.1
Joe Andrieu: Sure. So to your point, Steven, I think we're on just opposite sides of the aisle on whether or not we trust the URL writer...
… Um, I do not. I see them as a potential point of attack, and that manipulations of the URL can be used to bypass expectations of the client if they blindly pass through the parameters
Stephen Curran: what is supposed to happen in that section? And as far as I can see, there's no, A, guidance or warning that, hey, this could be problematic. Or, um, how the transition of a...
<swcurran> Who Is the "URL Writer"?
Stephen Curran: Query parameter that is intended to affect, um… resolution is treated when included in the URL. So those are the… that's my confusion
Joe Andrieu: And so the client should be intentional about what parameters get passed through. And I think I agree with you. Maybe in resolution it doesn't explain the consequences of of choosing options correctly...
Stephen Curran: Um...
Joe Andrieu: But I think that should be covered in the resolution section, not here. But we could add extra things like be careful about what options you select. The client should understand them thoroughly and know that that's appropriate for the particular use case. We could add some language like that...
Stephen Curran: Let's go...
Joe Andrieu: Um, to… to Will's comment, uh, actually, there are two links there. The first one does go to 4.1...
… Um, and the other one is a follow-up if you want to understand the resolving algorithm. Um, so
… I think those sections maybe are underspecified if they don't clarify the question Steven has about what do I do to resolve a DID, and we're not explaining how you should choose the version time that's appropriate for your use case, i.e. the version time that you believe that VC was issued at as opposed to the version time right now
… Like, those sorts of complications are, I believe, about how you properly prepare resolution, which I think should be with the algorithm. But I wouldn't be opposed to a sentence here if we wanted to add something like that
… The other thing, Marcus, you said something that threw me off because you said that the current algorithm that you still feel is what we should be doing sends dereferencing options to the resolver
… And absolutely, that shouldn't happen. Um, the whole point here is to cleanly separate, you know, what goes to the resolver, and I think we've… we've come to an agreement that that's just the DID
<Zakim> manu, you wanted to note "such as" language with a reference might be helpful. and to note "client should be intentional" is close to "browser should block"
Joe Andrieu: Um, and so whatever dereferencing option should not go to the resolver. The resolver's not going to dereference for me. The client is doing the dereferencing, and they may understand, um, uh, certain parameters in a particular way, but that's up to the client, not something that gets passed through
Stephen Curran: Uh, Manny, sorry. Go ahead...
… Awesome
Manu Sporny: Uh, no problem. Um, so plus one to the, you know, prepared DID resolution options is not very descriptive. You know, if someone's just reading through this, I don't really know what that means, and then when they click on the link, they go somewhere and it doesn't explain what that is, and I think, Joe, that speaks to your, like...
… if it's under specified there, we should, um, we should be a bit more, uh, you know, clear about that. Um, uh, sometimes it helps to provide such as language, um, like, you know, prepared resolutions options, such as, you know
… whatever. We can put some… it's so terse right now, it does… it requires the person to go somewhere else to figure out what the sentence actually means, and I think that's the… that's an issue. Uh, it's just an editorial one. So that's item one. Item two is, um, Joe, on your… you know, the client should be intentional
… um, you know, statement, and I'm not saying this is… I agree with it, um, but it's also very close to the browser should block or the browser should warn in
… Here, we're kind of talking about… processes that don't necessarily get user feedback before they execute, and we need to be careful about not creating systems that could fail open from a security standpoint, right? Um, so I agree with the point, like, the client should be intentional, it should not allow things to
… uh, you know, go through that it, um, that could be harmful to the user, like, you know, um, uh, and detect, and, you know, and if it's an automated process, block by default, uh, always allowing the user to rerun the commands
… you know, saying, no, I know what I'm doing, do the thing, right? Um, so
… I know that's at odds with maybe what some other folks in the group, you know, think, but I think we need to get crisp about what
… is allowable behavior, allowable protective behavior for a client and what is not, right? And if we had something that spoke to that generally, then we could kind of point to that section and say, this is what we mean. We mean individuals should have choice
… and they should have the option to override their software if… if they so choose. I think, Joe, that is your position. I agree with it. Um
Otto Mora: Steven?...
Manu Sporny: But, you know, we don't, I don't think we have that in the spec right now. And I think that's what's causing some of this, like, when is it appropriate to step in and protect the user versus not discussion?...
Stephen Curran: Okay, yeah, similar to Manu, I don't see how, for example, in the example I gave in the slides, how...
… the generic piece of software, a client can know whether the user is being intentional or not. Maybe that's a flag or something like that that's put in. But in the example I give, like, you know, I
… the, um… in particular, and it did YVH in the way we're using it and have suggested using it, if we just pass in this, this part of it, without the version time, this will
… result in a failure, because there's no key ID at… in the current dead dock that has that. It has to be at the version time that I want, and… and there's no
… the user has to be able to convey that somehow. Perhaps that is that they can affect the options. But I don't see where in this there's a way to affect the options. So I'm not sure how we get around this idea that you can't
<Zakim> JoeAndrieu, you wanted to say this is analogous to setting HTTP headers
Stephen Curran: as a user specify those things. You have to be able to do it somehow. And I don't see in this current spec text how that's done. And that's what's throwing me off. That's it. I'm Joe
… Whoops
Joe Andrieu: So, you know, it might help to think of this as HTTP headers. Um, HTTP headers should not be added willy-nilly, um, when the browser or a, um...
… You know a command line tool or you know some server side tool that's that's creating an HTTP request
… They intentionally construct what headers they wanna send. But they don't filter which URL they're going to. Those are two different things I I think they got conflated here. The which URL you which resolver you rely on for particular DID methods is a security modality that the user needs to be involved with They need to have some override
… What I'm saying is that the URL should not be treated blindly to trust all of the option parameters
… Because it's the clients who knows what the task is that's the business purpose of this dereferencing right now. If I am, um, verifying a proof on a VC, then I know something about version time, and I should not use the version time in the URL
… If I am authenticating a historical record from a log file, also, I'm going to know the version time that I believe that log was created at, and I need to apply that version time. If I just use the version time that is in the URL, I'm subjecting myself to potentially
… I'm using the wrong version time for the particular business case that I'm in. And so this is, you know, if you think about how browsers work, the user is usually not involved with the HTTP headers. What happens is people writing web apps
… um, construct HTHP headers that then are executed by the browser on behalf of the user. So in that case, it's the software that's the web app that says, oh, hey, I know that if I set my headers, um, uh, uh, accept type to a certain way, then I'll get back a different result from the server, so I'm gonna set that header
… So that I get back the right data type. Right? That's that's what I'm talking about is that the client software is the one who's in the business use case and understands what's appropriate. Whereas the the URL author or writer should be considered potentially an attacker
Otto Mora: Okay. Marcus?...
Joe Andrieu: Um, because that URL may have been manipulated in context before it got into the client...
Markus Sabadello: Yeah, Joe, what you just said resonates a lot with me. I've also always thought of the options here as being analogous to HTTP headers, and...
… I also think it's something that's basically set by the application and by the client. Kind of feels a bit
… unnatural to just blindly copy parameters from a URL into this option data structure
… Um, so I… like the way you think about that, but I would also have to point out that. In the dereferencing function, we have clear inputs. The inputs are the DTRL
… and dereferencing options, and the fact that there is a function or an algorithm with clear inputs, it doesn't mean that it's a remote service, it doesn't mean that it's a separate SDK or anything like that, but we have this. dereferencing, let's call it function or algorithm, and it has these two inputs, the DRL. anti-referencing options,
and… I
… I think we should not consider changing that in any way because I think that would yet again be not supported by our charter so we have to work with these inputs somehow and figure out. where do the resolution options come from, right? We have DTRL and dereferencing options, and
… then we need to invoke the resolver which needs a date and resolution options
… So we, we must fit this, uh. this algorithm somehow into… into the into this frame
<Zakim> manu, you wanted to note definitions of "client" might be different here
Manu Sporny: Um...
Otto Mora: I know...
Manu Sporny: I was listening to what Joe was saying, and I think I see one potential point of miscommunication is I think we may be overloading the term client. In my mind, client is this thing that is very like it's executing the algorithm...
… Um, and it has no business logic about the use case that's being executed. Joe, when you were talking about client, I heard you say, well, it's the one that knows, you know, uh, the business process that it's executing. And so it feels like we've got two kinds of clients here that we're talking about
… One of them is the software that's executing, you know, the logic that's in the algorithm, and in my mind, it has no knowledge of external business rules, the use case that's being executed. That's a different type of application logic. So I'm wondering if that might be one of the reasons where. You know, we're
… Because I agree with you, Joe, like there is a set of software that understands the use case at depth and it knows exactly what it should be feeding into the software to get the result that it wants
… But then, once it feeds it into the software, I think that business logic is expecting that. other software
… to execute as it has asked it to do
… And to make it, you know, slightly, you know, more complicated, that piece of software might act… try to act in the best interests of the business application logic by blocking, you know, certain sites that it knows are bad, or certain options that it knows would
… would result in something bad happening to the business, um, you know, the business logic software, because it doesn't specialize in that part of the problem. So, I think there… when we're talking about clients, we need to be very careful about, like, are we talking about use case application logic, or are we talking about the thing that's
… meant to just have ultra-specialization in running the dereferencing algorithm, um, and making that a safe process to the downstream, um, application
<Zakim> JoeAndrieu, you wanted to say unfortunately we don't have "dereferencing options"
Otto Mora: Joe?...
Joe Andrieu: Yeah, so that is the disagreement between me and Marcus. Um, and it's not clear where you end up on that, uh, although your proposal is...
… I think not the right way to go about it
… The spec today defines the client as the software calling resolution
… And, um, in the attempt to define a standalone function
… What became clear to me, and I have come to oppose, is that requiring specific inputs and outputs is too constraining for most use cases. Then we would have to provide all of the types of outputs for all the possible use cases for this dereferencing function
… And that is not a burden we are going to be able to finish in time. It just isn't. Like when I need to verify a VC and I know the time, I don't need all the other crap
… That the previous dereferencing algorithm was requiring me to do. I can have a simpler set of code, a simpler set of implementation of this algorithm where I prepare for resolution, I perform resolution, I handle the results of resolution
… And the fact that the side effect for me is marking a database as this VC is verified, means I don't have to specify that there's an output that is, hey, your proof was correct
… Because the proof is correct coming out of a dereferencing algorithm doesn't make any sense. So… so the idea that what we are standardizing is the interface to a library is something I've been opposing, because it is confusing
… Then you do have a question of, well, what is a standalone thing, this library, whether it's remote or local or whatever, and now we have to bundle all the inputs and outputs in a concrete fashion so that people can implement it in an interoperable way. That's the tension that I don't think we can get through, because the set of those options
and outputs, um
… Uh, frankly, is, is overwhelming. And, and I'm, I, I, I keep hearing things like, all you need is the URL back from the dereferencing algorithm. And I'm like, no, that is not correct. There are, uh, there are many cases where the URL itself is not sufficient
… And that leads to this argument, okay, what other parameters have to come back? And I just don't think we have time to tease out what are all the different return values that we need to be able to support for all the different use cases
… So to me, the client is like the browser. And the browser could be making these choices based on the HTML that you have, or it could be implementing results of a complicated web app where JavaScript is constructing a particular request object that has particular headers and options
… Both of those are consistent with the web architecture. And so it's just the client who is preparing for resolution, who it's their job with whatever set of objects that they use. And if they want a library that's a reusable library that lets them focus just on that, it handles
… dereferencing in a way that works for the client software that's great. But I don't think we have consensus on what the standard for that interface would be and I don't think we have time to figure it out
<swcurran> I think this is the core confusion -- of many questions.
<Zakim> ottomorac, you wanted to ask perhaps we should define the actors in the algorithm
Otto Mora: Okay, I just put myself in the queue. I would agree with the comment from Manu about defining client better...
… Uh, is it the user agent, to use a browser analogy, or is it… is it something else? Or maybe these actors, or these
<swcurran> +1
<Zakim> manu, you wanted to ask if we've drifted from the question/slide? Also, to queue something up for tomorrow.
Otto Mora: Purse entities need to be like, maybe specified at the beginning of the algorithm. Perhaps just just my 2 cents. Okay, I saw Manu
… Yep
<JoeAndrieu> From the spec: client
<JoeAndrieu> Software and/or hardware that invokes a DID resolver in order to execute the DID resolution and/or DID URL dereferencing algorithms. This invocation is done via a binding. The term client does not imply any specific network topology.
Stephen Curran: Yes...
Manu Sporny: Yeah, I have forgotten what was on the slide and what we're talking about. I don't know if we've drifted. Maybe this is exactly what… We do need to talk about this, clearly, but I don't know if we're actually answering. I feel like we're way off...
… off, uh, target at this point. Um, uh, so that's, uh, item one. The other thing I wanted to do, uh, uh, chairs, is, uh, queue up a discussion for the, did, um
… Uh, uh, main did call, uh, tomorrow. We have a request in from the
… verifiable credential working group, the Recognized Entity Task Force, who is trying to use PATH service in WHOIS service
… And they want to be able to reference
… uh, the specifications that this group is working on. We don't have a stable reference for them. I'd like to put aside 5 to 10 minutes on the call tomorrow, uh, to discuss
Otto Mora: Sounds good...
Manu Sporny: What our response to that group is going to be...
Otto Mora: Thank you...
Manu Sporny: That's it...
Otto Mora: Steven?...
Stephen Curran: Um, yeah, just to wrap up this, I mean, I think, you know, Manny, your question of, you know, are we still on this quest slide we're on? I think this...
… what is a user, what is a client, is absolutely core to my confusion. Um, I think we are very close to defining. all
… you know, pretty much the inputs and outputs, and very close to that, and Joe, you're absolutely right. That's what I thought we were… you know, if you're not aiming for that, I thought we were, and that's the source of many of our confusion, because I don't know when you say. Um, client… what it is
… what's the scope of that term? And so, I think coming up with that might be very helpful, because I think a bunch of the questions that follow from here
… Weigh on that one question, and it's come to light in this particular slide, but that is the core. of, I think, the confusion. I'll leave it at that
… minute
Otto Mora: Uh, Mano?...
<Zakim> manu, you wanted to note "user agent"
Manu Sporny: Yeah, and maybe to draw a finer point on that, you know, Joe, you said, you know, we wanna be aligned with web architecture and that sort of thing. So plus one to that, like, I think we all wanna get there. I'll note that, you know, calling the browser a client...
… uh, it confu- I mean, you know, from way long ago, it's XHTML2 and HTML5 days was a confusing thing in that group as well, right? Because, you know, you call it a user agent, but the user agent is doing multiple things. It is executing
… website code that it it didn't have any authorship over and whatever. And there's a whole bunch of business rules there. And then the user agent also has another side of it, which are the APIs that it exposes to that web page, to the business logic to get certain things done
… And it is very, like, there's a huge, you know, whole security model built around, like
… the security model around the business logic and that code, and then how it crosses over to the client logic that, for example, Fetch ends up implementing
… that's where I'm seeing, like, you know, calling it a client, like the browser client, um, tripped that group up as well, and we had to break it down into, like, okay, what are the actual pieces that we're talking about here? Um
<Zakim> JoeAndrieu, you wanted to say client isn't just the user agent. it's also the web app.
Manu Sporny: So anyway, food for thought. Like, I think we should spend a little bit of time talking about, you know, those two things, because if we can break those concepts apart and put clear boundaries around them, then I think the interfaces between them become much easier to talk about. That's it
Otto Mora: Okay, closing word, Joe?...
Joe Andrieu: Uh, uh, yeah, plus one to… we need to tease that out. Um, I don't think we're talking about a user agent, because we are talking also about the apps that are run by JavaScript, which then call the user agent. Um, and so what we're… the client here is the logical… process that is invoking Resolve...
… I think that's the legacy of this document and what I've been trying to get us back to. Instead of having multiple potential things that you might have a client for a resolver versus a dereferencer, which was a new thing that came out of nowhere for me
… Um, and so to me, the client has always been the one who's calling the resolve function. And what we're talking about is how do you prepare, um, perform, and then respond to what that resolve function gives you back
… So to me, the boundary of the client is is in that space. Maybe we need better language about it. But I think it's not quite user agent, but we can still tease it out
Otto Mora: Okay, perfect. Thank you so much. To be continued tomorrow...
… Thanks, folks