Meeting minutes
<pdl-ASU> present
<ottomorac> transcriber-bot, connect
Otto Mora: The, uh, first one being a proposal on debt resolution...
… Uh, and reviewing that text… I'll actually share my screen
… Okay. Be our focus for today
… So we have the text for that. Then we're going to discuss the… part about… which did URL referencing section we can keep
… We have some ideas here. That we we're gonna discuss
… And then we were hoping to
… end the meeting, uh, with a… a presentation from Joe, kind of an explanation of
… why this concern around the the confused deputy attack, and why we might need to revise our approach to the inputs to the resolution algorithm. So
… That's the conversation for today. Anybody have any… Okay, yeah, I see Will's got his hand up, so go ahead, Will
Will Abramson: Yeah, I just wanted to clarify that we're not going to be running this proposal today, right? Like, this is… I think we should run the proposal on Thursday on our main call...
Proposal on DID Resolution\
Will Abramson: Just because I think that's best practice. Uh, but it would be great to get, you know, we can have a brief discussion about the proposal text I did send out by email. It'd be good to hear what people think, like, softly, whether that's good text, or whether they have. um… Changes they would like to see
… Uh, yeah, I was hoping today we could focus on, like, this… primarily on these big resolution inputs
… Um, to get that description, I asked Marcus to join. He says he can join in the next, uh, 5 to 10 minutes, so… That's great
Otto Mora: Okay, that's that's great. Yeah, I know. um...
Will Abramson: Yeah, just one final thing, yeah, on the DID resolution inputs, if we can, it would be great to get to some, like, draft proposal text, because I think if, you know, if we are all in alignment that we have to roll back the resolution we passed, we're going to need to also pass. another resolution to invalidate the previous...
Otto Mora: Mm-hmm...
Will Abramson: Yep...
Otto Mora: Right, right. That being the goal of the third point. Absolutely. Yeah. Yeah, absolutely. Uh, okay. Anybody else? Let me see...
… No, okay, cool. So yeah, so let's get started on the proposal text. Does anybody have any comments on this one? We did share it ahead of time via email. And I know in one of the technical groups as well
… Uh, is there any comments from anybody? Or they pretty much agree with
… That being the also that we'll try to run tomorrow
… Okay
… Not seeing any
… Buddy reacting. I'll take that as positive silence. uh… Point two would be
… Um, around… oh, yeah. Well, go ahead
… Were you going to jump in, Will?
Will Abramson: Sorry, I was muted. Yeah, I just wanted to emphasize again, I mean, I have already mentioned this a few times, but like we are not saying...
… Did URL dereferencing is not getting done. We are just saying we want to just get something into DR
… that we can show W3C staff like, look, we are making progress. Here's our CR. And we all know as a group that, yes, we want the URL dereferencing in there. We fully intend to make another CR that will replace this one
<pchampin> not just staff, but also (and mostly) W3C members
Will Abramson: But just at the moment, I think the best course of action is to get something into CR. And I guess also on this
… we were talking with Pierre yesterday, uh, on Wednesday, and one of the things we talked about is
… The trap modeling work
… And, right, like, if we're following fully by the book, to move into CR, we need to complete the threat model for DID resolution. One of the questions that we had, or Pierre raised, and I think it's a good one, is maybe we can
… ask Simone if we can complete the threat model while in CR. Like, just like we are doing for the DID core work, um, right? Like, DID core doesn't have a threat model, but it is in CR. I think Simone would be open to that. um
… Because, you know, we didn't have as much time
… to prepare this. Uh, so it's, like, similar with DIDCOR, right? Like, you can't leave CR until you have a threat model. Um
… Rather than us, like, holding back. Because I think if we can say that that is the case, and we don't need to have a threat model complete to move into CR, then I think there's very little we have left to do to get a candidate REC that we can propose. Which would be great
Otto Mora: Mm-hmm...
… Exactly, with this, like, uh
… Reduce focus, we would be able to achieve the date. Excellent. Let's be positive
… Got reactions here from folks. I'll assume
… Any comments there, Joe? I mean, I believe
… like trying to reach the the threat model completion during Cr. Period or. Any comments on that or? Sounds reasonable to you as well
Joe Andrieu: Um, sure, I mean, I can't speak for Simone. Um, I think the chair should ask him. Um...
Will Abramson: Yeah, I'll send an email...
Discussion: Which DID URL DeReferencing section to keep
Otto Mora: We'll do that. Thank you. Okay. So… On to the second topic...
… um… So… If all goes well, and we do have the, uh
… proposal being passed, we would like to then have a conversation around
Phillip Long (GU, T3, ASU): Thank you...
Otto Mora: How do we manage this idea of two-digit URL dereferencing...
… sections being there. One is being the current one, and one being, like, the work-in-progress kind of one. And to avoid
… Making things more complicated like we wouldn't want to take out
… the in-progress one, because that, logistically, like, we just know how hard it is sometimes to get PRs merged in, and that's complicated. So, there is a potential idea here being floated, um
… where we could maybe hide or or just mark one section as as
… has to be hidden so that the… the version that's published in CR isn't shown. So that… that's an idea that we had from, uh, a conversation between myself, uh, Pierre, and
… Will yesterday. I see Will's got his hand up, so that will speak more to this
Will Abramson: Oh, I see PA… yeah, actually, I will have PA to speak to, I didn't know if he was on the call...
… I think it's an interesting proposal. I would love to hear what the group thinks, so I'll let PA speak to
Otto Mora: Go ahead, Pam...
Pierre-Antoine Champin: Yeah, so that's something that we've been doing in another group. Basically, we have some things in the document that are just for the editors, but that we don't want published on working drafts...
… Furthermore, that group is not near CR, but that's a similar issue. So basically, rather than removing it before we publish a CR snapshot, which again might raise concerns that if we remove it, it will be harder to put it back
… Just add some CSS, well, not CSS, some JavaScript that would convince Respec to mask it from the finalized version, so the ones that end up on TR
… but the editor's draft on GitHub pages will still contain both sections, and we can continue as we do right now. So I think it's a middle ground. It's the versions on the… especially the candidate recommendation on. W3C.org slash TR will look more tidy
Phillip Long (GU, T3, ASU): Bye...
Pierre-Antoine Champin: Uh, less work-in-progress-y, because that's not what a CR is supposed to be, but the editor's draft could keep all the content that we have, and we could keep iterating on that...
Otto Mora: Thank you, Pierre. I appreciate it. Will?...
Will Abramson: Yeah, so I think the proposal here is, um, both DGRL dereferencing sections would be marked at risk...
… Uh, but the one that is currently provisional in the spec would also be hidden from the candidate recs. ah. like, Polish version. ah
… But it's going to stay in the document, like, and we are believing that we are going to move to this provisional version. We definitely don't want to remove it from the spec, but… ah
… from talking to PA, like, obviously, it would be nice to just… from people reviewing this, W3C staff and stuff, it just looks like it's more of a… All I should say
… So, is anyone opposed to that direction? Um
<pdl-ASU> Is there any downside?
Otto Mora: I see Joe's got his hand up...
… And I see also asking Phil if there's any downside. So I'll let Phil go ahead and try to answer that. Sure
Joe Andrieu: Yeah, I'm not gonna pose this if the rest of the group wants to go there, but I do question the ethics of it. It feels intentionally deceptive, so that makes me uncomfortable...
Will Abramson: Upload...
Otto Mora: Yeah. Go ahead, Will. Yeah. If you want...
Will Abramson: Yeah, I just wanted to know, like, what, um...
… What direction would you propose, then?
Joe Andrieu: Well, I think we should have some text that we're going into CR with, and that's the text that should be put into TR space. um...
… It's the gap between
… what we're presenting as being NCR. And what is actually in TR
… That's… That's where my concerns
Will Abramson: Mmhm...
Joe Andrieu: But I won't oppose it. I just, it feels… Like, we are intentionally running around. Um...
… The process. So that we look good
Otto Mora: Yes. Pierre?...
Pierre-Antoine Champin: I understand that feeling, Joe, and I see things slightly differently, but I sympathize with this view. The way I see it is that anyway, we are marking this thing as at risk...
… So we are signaling, this is ideally part of the final rec, but at the moment we can't guarantee that it will make it to the rec because, well, in that case, because we are not quite clear on the consensual way to
… to put in… on the consensual version to put in the spec. Another option would be to just take it off of the CR altogether, and maybe that would be more honest
… In your opinion? But I think marking it as at risk
… is what makes it honest still. This may not go to Seattle. We actually know that probably this version won't make it to Wreck, sorry
… But we are willing to show that there is at least a subset of the spec that we consider
… stable and relatively final, and this is the signal that we want to send. So, yep
Otto Mora: Mm-hmm. Uh, yeah. Thank you. Uh, Will?...
Will Abramson: Yeah, my sense is that we do want to have something that is labeled DGRL dereferencing and is marked as at risk in the spec, because we want to signal both that we have something stable that we are happy with, and...
… Also, that we are fully intending to, but we don't yet have it, you know, stable enough
… But we intend to make this digital dereferencing thing
… and continue working on that. It's just that risk element. I think if we didn't have it at all
… I think that probably was worse for my, you know, like, the W3C stuff, and be like, well, why are you not moving this to REC? Maybe
Otto Mora: Mm-hmm...
… Uh, Phil?
Phillip Long (GU, T3, ASU): Yeah, I have a tendency to be as concerned with Joe's perspective about we're not exactly being candid about where we stand, but I think the at-risk compromise, I'd kind of forgotten the meaning of...
<pchampin> also, the fact that the current ED contains two versions of the Dereferencing algorithm is just an artifact of how we worked so far; there is no intent (I think) to publish a REC with 2 such sections!
Phillip Long (GU, T3, ASU): the significance of that. I think that flags the fact that it is not unanimous at this point, and while we have a sense of, amongst perhaps the majority of the group
… where it should end up. It is not there yet, and so the extra time, once it's in CR, is essential to make sure that we can get there, if it's possible to get there at all
… So I guess I would go with the at-risk, publishing it, acknowledging Joe's perspective, and maybe even making a comment that we are cognizant of the issues here
Otto Mora: Phil, I think that's sensible...
… Um… yes, Joe
Joe Andrieu: Um, yeah, either… either I missed an adjustment to the proposal, or I'm misunderstanding how people are, um, speaking about the at-risk. I'm… I'm definitely...
… In support of marking the dereferencing algorithms, whatever we publish about that, um, as at risk
… Um, it's having a gap between what we have in our editor's draft and what we have in TR. Um, so… maybe I missed a shift in the proposal there, but
… I'm… I'm confused what's being proposed right now
Otto Mora: I'll let Bill, yeah, go ahead, answer that...
Phillip Long (GU, T3, ASU): Okay...
Will Abramson: Uh, yeah, I mean, I… we are having a gap. I… maybe I can speak to the optics of that more, but certainly, currently, we are proposing that we would, um, surface one did your LD referencing algorithm to CR, rather than having two. You know, like, which we have in our editor's draft, we have two digital LD referencing
algorithms...
… I mean, we could service both. I just think, I mean, maybe Pierre can speak to that. I think that it might work worse on us. But yeah, maybe that is being deceptive
Otto Mora: Mm-hmm...
Will Abramson: I don't know...
Otto Mora: Um, okay, it sounds like Paris… Acknowledging...
… Yeah, the same company. Yeah. So yeah. So that would be the idea. Okay. Okay, so
… Unless anybody else has any other comments. I think we
… And you'll have agreement. Yes, well
Will Abramson: Yeah, just, uh, want to flag something else that we talked about, like, we are only intending to run a single proposal tomorrow, like, and, like, marking in stone this direction, you know, like, focus on moving did your… did resolution to CR with did your LD referencing marked at risk. um...
… That was our current plan, and then
… We just need to have a conversation in the group about what
Otto Mora: Mm-hmm...
Will Abramson: like, this second point, right, which did your LD reference infection to surface, or whether we surface both. And we can revisit this tomorrow too, uh, but I would like to get a sort of agreement in the group so we can move forward, because especially if Simone gets back to us, like, I'm hoping by next week we can have something
that we. Feel ready to move to CR...
Otto Mora: Right...
… Okay
… I don't think that's clear, not seeing any other raised hands. Okay, so maybe
Discussion inputs to the DID Resolution
Otto Mora: Yeah, uh, we can, uh, move to this third topic, and I will… Just, uh… Oh
… on share here. And so I'll let kind of Joe
… Dwell more into the confused deputy attack, and and
… you know, a situation that he started to look into where we may need to reevaluate our whole approach to the inputs to the resolution algorithm. So I'll let. I'll let you kind of… Walk us through that
Joe Andrieu: Okay, cool. Folks can see my screen?...
… Um, okay, so, um, this conversation about Confused Deputy is really just to give… get folks on the page with the conversation we've been having as editors. Um, context
… Um, and I don't… I don't know that we have any good answers, but I'm gonna get to the four proposals, uh, or options that have been discussed. So, I'm just quickly gonna
… anchor to what is a confused deputy, talk about how that relates to, uh, URL parameter injection for DIDs
… Um, with some of the language from the spec today, some general framing, and a couple of specific examples. Then I will talk about the options that have been, uh, brought up as, hey, maybe we could solve it that way
… And then we'll just hand it off to group discussion. Feel free to interrupt if you have a question on any of my slides, but I only have about half a dozen slides. So a confused deputy is when a trusted, highly privileged program is tricked by a lower privileged entity into misusing its authority
… That's a distillation of what's in Wikipedia. In other words, you're configuring, or you're using this low-privileged app, um, to get a naive, high-privileged app to do something weird, because it was naive about some aspect. That's the confused
… deputy part. Um, the simplest example that I like for this is talking about uh if you in Linux
… Um, if you set folder access to the group developer
… Um, then you've now separated, um, the notion of who is authorized to that folder and what is in the folder. And so, um, people can put resources in there or have applications point to that folder
… Because they have an idea of who developers are. But if the actual group of developers diverges from what is… the people who are managing the resources think, then we could put resources in there that we thought were appropriate for all developers, but it turns out it's only good for American developers
… And we didn't realize that there were non-American developers in the developers group, and so now the system that's, you know, using access to that folder is confused about who's actually there
… So this is in essence sort of an abstract discussion of the confused deputy with this one example. For
… Did URLs
… In the spec today, we have this function resolve, which takes either did or did URL. I'm just noting there is dissent about passing path and query part into that function. And this touches on that. So unfortunately, we're still sort of in that, wait a minute. Uh, can we still address people's concerns here? Um
… The other thing that is in the spec today is that all query parameters become options. So all the queries in the query part of the did URL, all get promoted into options in the call and resolution that's in normative spec right now
… And then the client has the option to replace query parameter values to override
… Um, so we're going to talk about version time. It's an easy parameter to, um, reference. So if there's a version time in the DID URL, the client, before they pass it to resolve
… If they want to change that for whatever reason, then they have to intentionally override it
… And in the spec today whether we're we're using data or did URL, the fragment is not passed
… in any of the concrete proposals that I think are on the table. So that's
… That's sort of the source of this potential, um… Uh, confused deputy problem
… Um, so incoming DID URLs are a commonly a low privilege interface. So, you may not know who wrote the DID URL, you may come across it in the wild, it may be in a presentation you see, it may be on a business card, it may be an email that you get
… Um, and it may be modified in transit, right? So, if you got that as an email, or you got it on a business card, um, both of those can be manipulated. Um, and so that's… it has to be taken as a potentially risky source
… And there's a possibility that if you manipulate those DID URL parameters, that might compromise resolution, um, especially when promoted without consideration. So I'm going to give some examples for that. So
… Um, I think the lightest weight example is DidAuth. Um
… Imagine that we have this DID document here on the right. It's super simple. It's got one verification method. I've cut out all the other details so it can fit on the slide. And that verification method is identified as how you authenticate for this DID, right?
… Uh, key one is compromised on May 1st. Uh, rotation realizes that it was compromised, or just through normal process, rotates it on June 1st. Um, and now the dead
… Author manipulates version time
… to trick DDoS on June 10th
… So, on June 10th, the attacker, uh, constructs this did URL, and it says, hey, don't use the current version time, use the version time for May 10th, which is between this May and June deadline
… So, in this DID auth exercise, the DID URL that's provided doesn't have a key reference
… Um, it just has a version time reference. Um, and if it did have a key reference, actually, that… that complicates things, but it doesn't necessarily change it with regard to Resolve, because Resolve doesn't see the key, um, because the fragment doesn't go over there
… In this situation, um, a naive resolver client who isn't thinking about, hey, it's DID auth, and I should be using, um. Uh, a different, uh, version time
… Either by emitting version time or setting version time to now. Then what's going to happen is the resolver is going to return the did doc with a compromised key. Instead of the current doc. So we'll get a did doc back. That's the did doc that existed on June 10th
… Um, which has a key that's compromised. Um, and we know it's compromised. Uh, I'm sorry, we're getting back the key on May… I should have changed the date here. I shouldn't have both June 10 and May 10
… We're getting back the version of the doc on May 10th, um, which has the compromised key
… But we are performing that action on June 10th, when the key's been rotated, and it should no longer be used
<swcurran> Pro Tip: Don't use the same key-id for different keys. :-)
Joe Andrieu: So that's that's the basic setup with did off. Um there are a couple of other scenarios that that might help um sort of clarify how this
… problem seeps out. Um for data authentication that's the one I just talked about
… Um, it's even more problematic with version ID. Because with version ID, you don't… uh, the caller… doesn't know how that version ID maps to time. That's sort of the whole point. So, um, if you… if you blindly follow the version ID, then you don't even know if
… You're incorrectly following the time. And if we have both a version ID and a version time, because you're trying to override, I think that gets very complicated with the current spec text
… Another one is if you're validating did authentication logs. So this is a record of authentication that maybe happened last month. And there's some anomaly or maybe it's just procedural audits. The version time there absolutely should never be what's in the DID URL. It should be at the time of the authentication
… Um, because what you want to ask is, at the time of authentication, uh, what should this be? Um
… And again, version ID should be ignored because you can't put that into temporality. And that creates its own problem. Because if version ID somehow did authentication, you're thinking, oh, we should let them if they're being specific about it
… Then you should allow that. But then when you go to the authentication log. then your version ID
… Which is, uh, sort of
… expect it to not be the same anymore, um, you would have a mismatch here. If version ID were to be allowed in one of those contexts, it would be broken in the other context. Um, another one is, uh
Stephen Curran: Hey, Joe. Hey, Joe...
Joe Andrieu: Yeah, go ahead...
Stephen Curran: You said task question. Saying you should always use version time now is...
… not appropriate for things like verifying a signature
… If you are verifying a signature, you should be using, you may want to use version time as the time of the signature
Joe Andrieu: So, I would argue that...
Stephen Curran: So just that blanket statement is incorrect...
Joe Andrieu: Um...
Stephen Curran: Oh, sir...
Joe Andrieu: I would argue that for DID authentication, you are authenticating a real-time system, and that signature...
Stephen Curran: Yes, sorry, did authentication, you've got that at the headline, yep, sorry, that's fine...
Joe Andrieu: Okay, well, I'm right with you, though, because we run into that problem with the VC. So this last one is getting to the point that you were trying to raise. We may still have a difference of opinion, but let me get the third one out. So we could have an issuance date of a VC that's a mismatch with a version time...
… Um, and the tricky part there is that all we have is a valid from. We don't have a timestamp on the proof itself
… Um, and, uh, Will has pointed out that valid from is equally, uh, if, if, if you have access to something that can make the signature, you can change the valid from to be whatever you want. Um, however, uh, if this version time is different than valid from
… then it could potentially be that the, the attacker is pointing you to a compromised key, but attempting to establish that this credential was issued after, the key has been rotated out, but the DID URL is pointing to before that
… Um, so it just creates this mismatch that becomes a problem. And this is sort of… the root challenge with the VC is that we don't have the actual time of the actual proof, and so we have to infer some things. But you still have the possibility that a DID URL with a version of time in it could be directing you
… to a version of the DID document that has nothing to do with the time at which the VC was created. So if the recipient of the VC, the verifier, has some confidence about time, then they could use that
… Um, and they should just ignore whatever the version time is in the URL, because they need to understand, using the best of their signals, when that VC was actually issued. And I think that's to your point, Steven
… Did that speak to your point, Steven?
Otto Mora: Uh, Damon?...
Stephen Curran: Yep...
Joe Andrieu: Okay...
Otto Mora: Okay, and I see, actually, Pierre's got his hand up as well, whenever you want...
Pierre-Antoine Champin: Yes, thank you. To react to this last issue...
… If I understand correctly, your premise is that the DID URL could be modified in a VC. I would expect that this premise doesn't hold the VC
… Okay, if it's part of the proof, it's not signed. So, ah, yeah, okay. I may be wrong. I take that back. Because
… No
Joe Andrieu: So it's it's it's more…it's a little bit more subtle. We're talking about like the key a key being compromised and so the compromised key is signing it So the proof is signed over by the attacker...
Pierre-Antoine Champin: My idea was that… Yeah, okay. Oh, yeah...
… Yeah, uh, got it. Okay, yep. Sorry
Joe Andrieu: Cool. Thanks, PA. No, it's all good. It's all part of trying to understand this confusing set of things...
… Um, so… My sense, as we've kicked this around, um, so far, and I'm gonna put the four options up soon. Is it really only the client of Resolve knows which version time would be appropriate? um
… And and so the bid URL author shouldn't be taken as authoritative for that at all in my opinion
… Because they're not in the context at which this is being presented. They are intentionally separated by space and time
… And so version time in particular, seeing these examples really my opinion should only be promoted explicitly when the client knows that it's the appropriate version time
… Um
… And so, we've…we've identified four different options. Um, let me just walk through them. Um, I gave them some names, so we can
… hopefully that's easier to talk about. So the first one is, um, the current spec, uh, with DIDs, not DID URLs, because we haven't pulled that PR in. So, uh, it's the second one that's the current resolution, which we had a resolution about switching to DID URL. Um, so those are the first two. So in this first one, all query parameters are
promoted in the same set
… Um, as client selected options, so that's what goes into that options value. With resolved DID URL, with options, then we pass a folded URL, and the options just have the override. So we have all the data in there
… Um, but we have separate buckets, um, with the options. Um
… In this context, we're not really addressing the confused deputy, by the way, because it's still potentially in the DID URL
… The third one, if we go to… Actually, the last two are also, let's go back to DIDS to help with this confused deputy problem
… Um, so the third one, there's no promotion. You pass a DID, and you pass options, and all of the options are client-selected. So the client should not promote any query parameters without making an explicit choice about it. Blind promotion
… Um, would not be conformant. Of course, some people might do it because they're sloppy, but, you know, we can, in the spec, say, hey, that's not what you'
… And then the fourth one here, um, that has been put out is that, um, we pass the DID, we pass, um, options that are from the resolving client
… Um, and we pass a parameters value. Um, and whether parameters is in options is kind of
… Not important, but the idea is that the parameters… Sorry, the options that are passed to resolve that come from did query parameters
… Um, are in their own bucket, so the resolver can at least understand, hey, these were things that the client provided, and these were things that were in the DID URL. Um, and I believe in this proposal, options would override the query parameter
… So this at least allows the resolving party to understand that there were two things here and would still allow the DID URL to pass in options when and where appropriate
… If… if it's appropriate. And so the question is, which of these has the least, um
… uh, security and or privacy harms. And the other thing I will mention, uh, although it doesn't have anything to do with Confused Deputy, um, but Marcus raised it in this conversation, and I think it's a good objection about Resolve
… Um, he expressed, um, uh, frustration that the DID URL there is also leaking path data to the resolver, and the resolver doesn't need to see that path data. Um, and I agree with that. Um, it's path data. I don't know any DID methods that use that
… To affect resolution so it's almost So I don't know of any examples where that would be confused, Deputy. But that is an additional negative on the passing the did URLs resolve
… Um, and so with that, I see someone's on the queue. How big is the queue? Is it just you, Steven?
Otto Mora: We got Steven and then Phil...
… And then Marcus. Go ahead, Steven
Stephen Curran: Um, Joe, you have Resolve… in all of these, there's options, um… But...
… There was a previous change, as I understand it, to the spec that removed options from
… Uh, did URL dereferencing?
… Um, which would mean that… someone passing in
… a DID URL for dereferencing would not have any… the ability to pass options in. Um, are you suggesting that the… Return to having options
… Um, since… It's quite possible that the
… Caller would want to pass in a DID URL with options
Joe Andrieu: Um, so, I… I think that's not… I think what you've presented is a misunderstanding of the… one of, uh, at least my proposals around...
… Uh dereferencing, which is that…the client who is generating the options is the one who owns that dereferencing algorithm. So
… When we don't have a function call for dereferencing, then we don't have to specify what parameters go into that function call
… What we're specifying in a dereferencing algorithm is here's what the dereferencing client does, and one of the things that they have to do is… is process those. The things that would have been options if they had to be formally passed in
… So we're not getting rid of the ability for the dereferencer to understand that in their situation, um, uh, they might be applying different rules. Um
… It's just we got rid of that function call. So we don't have to explicitly, uh, pass it as a value
Otto Mora: Okay...
Stephen Curran: Okay. Wow...
Otto Mora: Uh, Phil?...
Phillip Long (GU, T3, ASU): Yeah, I'm just curious. This whole thing started to try to address the original problem that you posed, and yet the first two don't address it...
… So it seems to me that the only discussion is about the remaining third and fourth one. Did I misunderstand that?
Joe Andrieu: Yeah, that's exactly right. So, uh...
… The first two here, um, were… uh
… catalyzed by a variety of different things. In the conversation debating these two options, we realized one of the deeper security problems is actually this confused deputy bit, and that
… That's what made us realize that, oh, hey, maybe neither of those options are right. So I think I'm following where you're going, and I think you're right
… The initial start of this was, um
… uh… hey, look, why are we processing the DID URL options? That's… that… that is a point of potential confusion. Um, but
… uh, the potential confusion is… is a different problem than we have where we're confusing the resolver, um, sort of intentionally as an attack. Like, the… the confusion of a client that maybe isn't processing the DID URL correctly, um
… That was what the DID URL proposal was about. And in the conversation, we realized there's a bigger confused deputy
Phillip Long (GU, T3, ASU): Right. So I would just suggest that we focus on the last two because I think that's exactly what we're trying to determine at this point. Thanks...
Otto Mora: Uh, Marcus?...
Markus Sabadello: Uh, yes...
… Joe, I think this is a really great and useful analysis. I think I… I agree with everything you said
… I like the… I obviously don't like the second option, I've made that clear. I like the third, and uh
… Fourth options, I think they're both interesting. At some point, I think, Joe, you said
Joe Andrieu: Okay...
Markus Sabadello: But your opinion was that the client should not have to do any parsing or any processing of the DTRL. My understanding is that with the...
… Options 3 and 4 here, the client would have to do some processing of the
… TTRL in a similar way as it does it. Today, I'm wondering if that is still… One of your concerns
Joe Andrieu: Yeah, it is. I just don't know how to resolve it. Like, my… my attempts to resolve it created this… or drew the highlight to this other problem, um, that I think is… is probably more important. Um...
… I think the… the context in which we… we need the client to know things
… Um, that's real. Like, there are just times when they have to know that the version time needs to map to the time the VC was issued. Like, if they don't understand that, we're in lots of trouble. So, there's gonna be some processing, absolutely, that has to happen. That's more than I would like
… But I don't I don't know that we can get around that without creating this blind promotion of potential attack vectors
Otto Mora: Mark, is it Ken? Yeah, go ahead...
Markus Sabadello: Yes. I think that makes sense. One more thought on the...
… Fourth option, if we do the fourth option, I would just
… prefer to somehow include this information as part of the options instead of introducing an actual third
… input, but I… I think you said that that would also be… be fine, that that feels like an
… implementation detail, but I think the
… Fourth option might… might not be a bad idea, right, to
<JoeAndrieu> +1 that parameters can just be a part of options
Markus Sabadello: To pass options and the original parameters in a way that the resolver would actually know. Where those are originally… come from, um
… I had… in one of the previous conversations, I had one
… one thought, I'm not sure if it's useful, but
… there are some characters that are legal for options, and that are not legal for parameters. So, theoretically, we could have something like a prefix character for options that can only be set by the client, and that could never come from an original. DDRL when they are promoted
… I'm not sure if that is… if that is useful, but that would be one way of
… Of making sure that, uh, some, some information
… Could only come from the client, and could not have come from
<JoeAndrieu> +1 in that "prefix" is a valid fifth option to consider
Markus Sabadello: an original DDRL, as I said, by introducing some special character as a prefix in the name of the option. I haven't fully thought it through, so I'm not sure if it's useful, but… Wanted to mention it
Joe Andrieu: Yeah, just… just plus one, that that could be a fifth one down here that I didn't list...
Otto Mora: Well...
Will Abramson: Yeah, I mean, I think this is great. Thanks, Joe, for sticking at it. I appreciate you, uh, doing this write-up for us all...
… Um, one of the use cases I wanted to just float out and think through is, like, when we create dig URLs with, like, a version, or maybe a version time, when we're trying to
… reference specific resources that were, sort of, bound to the DID document in the past. Like, I think maybe that's a valid use case, right? Like, I have a DID URL to, like
… uh, version 1 of my DID document that associated some resource that I wanna… I wanna surface. Um
… I mean, I think this still works, right? Like, if you're talking about option 3, no promotion
<JoeAndrieu> +1 for dereferencing "into the past"
Will Abramson: Uh, the client needs to, like, understand
… this ver… you know, what this version is for, and then also the URL, right? And then it would decide, yeah, I want to promote this version ID in this case, and it would intentionally parse the version ID from the URL, and put it in the options, and then call the resolve option
… In option 4, I think I'm kind of leaning towards option 3 over 4, because in option 4
… Like, there is no… the client doesn't need to be intentional, right? Like, it's just gonna take parameters, put them in this option, and then
… pass them through. So if it doesn't override, like if it doesn't have an option, if it doesn't intentionally override the parameters, then there is a case when version ID or version time could be passed through by a naive client. And get to the resolver. Is that true?
Joe Andrieu: Um… I think so...
… I was nodding along so vigorously that I lost your last sentence
Will Abramson: Yeah, I think it's just, like, you know, in the case where there is a DID URL with a version ID or a version type, in option 4, like, what I'm gonna do is I'm gonna pass all those parameters, stick them in the parameter option, and...
… option, unless I've been intentional about it, and realized that, you know, version ID is a problem, and I want to override that, or… Ah
… Okay
Joe Andrieu: Well, in option 4, the… so in option 3, I agree with you that it's going to be explicitly promoted, so that the client would have to say, hey, I am… I want the linked resource...
… From this particular point in time, from this DID document, right? Like, I'm not trying to get the current
… version of that linked resource, I want that linked resource from a year ago. Like, that's… that's a totally reasonable thing for the client to understand that they want to do. And the resolve query, if, um
… Uh, if… if there's a mismatch between valid ID and time, then, um, it's… it's not clear what happens. That's my concern with the fourth one. Um
… You may not be able to just promote it to get what you want
… Um… Does that make sense?
Will Abramson: Well, I think, I guess just to add, I think in version four, are you saying that all parameters in the URL get passed and stuck in that bucket? Right...
Joe Andrieu: Yes, that's my understanding of the proposal...
… Whereas the third one is to say, only things that the client knows should be promoted. are promoted
Otto Mora: Yes, yes...
Joe Andrieu: And I will acknowledge, like, I don't know, sorry. Piers on the queue...
Otto Mora: Go ahead, finish that because then Steven wants to go ahead. We got a few...
Joe Andrieu: Right. I see there a couple more. I just want to say this is unfortunate that the initial state and the BTCR2 sidecar data...
… Are some of those things that unfortunately now mean we don't have interoperability at the client side with regards to those parameters
… Um, because if the client wasn't written with BTCR2 in mind, they're not necessarily gonna know to attach the sidecar data. And, um, uh, so that may not get promoted. And so that is, that is a big negative of, of number. 3 here. Um, but I think
… it's… it's probably in the balance of the security trade-offs. Um, I think it's probably the right choice
Otto Mora: Uh, Steven?...
Joe Andrieu: Um, but it is a little frustrating for those of us who helped create BTs here, too. Back to the queue...
Stephen Curran: It seems to me that option one and three are the same, except you're saying, hey, be really careful before you pass anything in. Don't just pass things into options. And...
… 2 and 4 are the same thing, with that same caveat, because a really good way to pass parameters, instead of putting it into a separate
… uh… a separate argument is to pass it at the URL, so
… Well, we all agree that both for two and four, you can slip strip off path and fragment. And even if you don't strip those off. The resolver's immediately gonna trip off, so… I think what you're saying is
… We gotta pick either date or date URL, and
… We need to tell the… Implementers to be really careful about handling. The parameters that get passed in
… I… I… Don't think it's more than that. Is that
… I don't know. You probably don't agree that that looks like to me what you're saying
Joe Andrieu: Well, I think the distinctions matter, right? So, for the first one, everything is promoted. That is the rule. If you're not promoting, you're not conforming. And I think that's very different than, uh...
… you should only promote those things that you understand. Some clients will decide, I'm gonna ignore that rule. But the other one has the inverse effect, that you are not conformant unless you… Pass all query parameters and options today
… And similarly, between resolve between two and four, whether or not you're sending the path, that's the difference. So there's a whole parameter there that was a privacy point that Marcus raised. I'm like, oh, yeah, we're telling the resolver things that they don't need to know. Um, you know, it may be modest, but it is a real difference
between those two
Stephen Curran: But all of these things are suggestions...
… All of these are suggestions and guidelines to people that write code. They're not… You can't
… Like, just like I can't… not pass a… if I want to use an API call to an HTTP
… you know, a headless browser, I can pass in a fragment
… you can't… it can't be stopped, so all you're doing is giving guidance to how to… to do this. The spec can't… Can't force people
… what to put in a string. So you're… it's… it's about giving guidance. Um, I do
… say that it did URL if you want to, you know, a compliant resolver can simply reject it and that would be fine as well, or they can strip them off if they want
Otto Mora: Okay...
Stephen Curran: Okay, I'm yeah...
Otto Mora: I I wanna thank you. I wanna let Marcus and and Pierre intervene, and then I'll have Joe get the last word so that we we make we make it to the...
… A lot of time. Marcus
Markus Sabadello: Yeah, I wanted to say something similar as well. I think there are some legitimate use cases where even a version time or a version ID could be part of a DDRL. In the use case DDOF that Joe described, that's obviously not the case. You should always resolve the...
… the latest version of the DEET document, but if we think about some other use cases
… For example, digital product passports where the document points to service endpoints, which may have some information about products, then it might be useful to have the URLs that point to specific services at specific points
… In time, so it seems to me that it depends on the
<pchampin> +1 markus_sabadello when I sign a VC, I know which version/date of my DID document I am using
Markus Sabadello: On the use case, what parameters are… should be
… Actually used by the by the resolver and should be. Promoted
<pchampin> the problem is that the verifier can't be sure I'm not an attacker
Markus Sabadello: In some of the earlier conversations, when this change was first proposed, I heard an argument that supposedly the DDRL needs to be passed to the resolver, because only the resolver really knows what to do with the parameters and the options
… as I said, I think it also depends on the use cases and some things that the client needs to be
… aware of or to decide what what can be passed and what cannot be passed. Feels like maybe
… And maybe the third option is there for
… what we should do, but again, it's a great… it's a great summary, I think
Otto Mora: Okay. Uh, Pierre?...
Pierre-Antoine Champin: Yeah, maybe there's something I misunderstood about the fourth option...
… Actually, I see two sub-options. Parameters… the… might be
… by the… to be conformant, you must pass all the URL parameters there, or you might still elect to include or exclude some of the parameters there, and so basically, uh, that could be a… Yeah, 4 prime, uh, which… Keeps the the the
… explicit choice of option 3, while also letting the resolver know which parameters were… come from the URL, and which were
… directly provided by the client. I don't know if that's useful, but in that sense, option 4 seems more flexible
<Zakim> JoeAndrieu, you wanted to say the whole spec is guidance
Otto Mora: Okay...
… Okay, Joe, last word. Go ahead
Joe Andrieu: Cool. Yeah, I like that option, uh, PA. I think… I think you're right. The… the important thing to me about 3 was a no promotion, but we could do 4 with no promotion. Um, I… or no automated promotion, right? So that's smart. Um, but I also… I wanted to...
… uh, acknowledge your point, Steven, that we… we totally cannot make people, uh, implement this spec in a way that they don't want to implement it
… But that's true of everything in the spec, right? So the whole spec is guidance about how we get to interoperability. And if we were to tell people that interoperability is achieved by everyone
… Promoting all the options. That is one way that actually improves interoperability. But I think for security reasons, I think we should not suggest that that's how we get to interoperability. I think the guidance that we should be giving is that, hey, you should be thinking very carefully
… in the context of the use. Like, are you validating an authentication action that is happening now? Are you auditing an authentication action that's in the past? You know, are you… are you looking for a resource, you know, that's maybe in the past, and you don't care about what's happening today? Like, those are all good things that the
client can take into account. Um… I just… you know, we… we can't make any software implementer do anything. Like, that's… sort of just
… Not the nature of our superpowers
Otto Mora: I think Steven wants to react. We got 2 min to go ahead...
Stephen Curran: Just a quick reaction to that, which is, we can absolutely make a resolver do what it has to do, and we can tell people to do a compliant resolver. What we can't do is tell people...
… Oh, make sure before you call this resolver that you set up the bid and the auctions in an appropriate way
… We can't control how it gets invoked. What we can control is how it responds to being
… revoked, but invoked, and
… What we said is all of these parameters have to be able to be passed in some scenario, so we can't restrict the parameters that get passed in. We can give guidance to people calling these and say, hey, don't be stupid. And that's what we definitely should be doing. Um, but
… But we can't prevent them from doing legitimate things. Um
… because it could be bad in other circumstances
Otto Mora: Any last comment, Joe?...
Joe Andrieu: Um...
… Well, we can't prevent them at all, but we are and we can tell them things like, you don't send a fragment to the resolver. We are absolutely engaged with defining the dereferencing algorithm, which is how conformant clients should prepare
… Resolve and use the results of resolution
… So some of what you just said, I totally disagree. We are going to tell them what they do before and after a resolution. That's… That is part of the scope of what we're talking about
Stephen Curran: Absolutely...
Otto Mora: Okay...
Stephen Curran: No disagreement there...
Otto Mora: Alright, well, great. So, tomorrow, I guess we can have a conversation, maybe a little more on...
… It sounds like people are kind of rotating towards 4, but we can hopefully make a decision tomorrow, maybe make a proposal around it, and
… Yeah, maybe, Joe, if you can send me that, or you want to send that to the working group via email, this presentation, just so it's like background material for folks before
Joe Andrieu: Yeah, I can actually… let me, um...
… Let me just edit this. I put it up to Google Docs
Otto Mora: Oh, perfect...
Joe Andrieu: So, in theory...
<ottomorac> transcriber-bot, pause
Joe Andrieu: I can just drop this URL in. I'll get rid of this slide. Thank you
<JoeAndrieu> https://