Meeting minutes
<ottomorac> transcriber-bot, connect
Will Abramson: I don't know, I'm calling. Do you want to introduce yourself? Nope, I think...
… um… Yeah, feel welcome to introduce yourself. It would be great to know what company you represent as well
Aaron D Goldman: I'm Aaron Goldman...
… I'm not representing any particular company here, but more following on with DIDS because it's an interest of mine
Will Abramson: Okay, great. Welcome...
Aaron D Goldman: In this community, I am probably most famous for the work I did at Blue Sky creating DID PLC...
Will Abramson: Thanks...
… Um
… Cool, yeah, okay, so
… For today's call, we just had in mind to continue on through, Stephen, your presentation. Oh, I see Manu on the queue
Manu Sporny: Yeah, just so we don't get in any process trouble. Aaron, wonderful to see you. Thank you for joining. This is an official W3C working group...
… Uh, is your organization W3C member, or are you an invited expert? And if not, the chairs would have to extend a, uh, invitation to you to participate, and remind you not to, uh… Provide any kind of patented
… uh, or, uh, IP, uh, that could, uh, accidentally be put into the spec. Anyway, sorry, I feel compelled to say that so that we, you know
Aaron D Goldman: Yes, I'm aware of the invited expert rules...
Manu Sporny: Excellent...
Will Abramson: Great...
Aaron D Goldman: I will not bring any IP into the conversation...
Will Abramson: Yeah, thanks for that, Mario. Yeah, and thanks. You're welcome, Aaron. um...
… Yeah, so you kind of catch us in the middle of a conversation that we're trying to finish off around digital URL dereferencing. I think I'm just going to hand over to you, Stephen, to go over the last few slides in your presentation. Hopefully, we can work through this slide. And then aim to get PR344 today
Stephen Curran: Okay...
Will Abramson: Of the plan...
Stephen Curran: Assume you can see my slides...
Will Abramson: Yep...
Stephen Curran: Um, we'll jump down to the last couple that were on, um...
… Uh, so at this point, um, a reminder that, um, you know, we've talked about the slides as to what they represent. All these slides are… were things that I just pulled from comments and, um
… and suggestions in the PR. So none of this is original material. This is all just pulled out. Um
… On this slide, um
… general service handling, um… There is a… in PR344, there is a default
… Service handler where there is no, if there is no type associated with a service that is to be processed
… Um, there is a default handler. Um
… I believe. So Marcus has expressed some concerns over that, and notably the. Existing functionality around service and relative ref and path. Uh, the path handling
… Um, that is expected. Um, my understanding from Joe, and he's put this in the comments and agree with us, but, um, there is the expectation that after 344 is merged, there would be an additional path handler, PR
… And possibly combined a path handler PR that described what path handler is and provides the detail for it and likely a path service. Um, coverage in that, and so those would be, um
… on top of what the default service handler is and would provide more specific handling of paths in the spec. So 344 does not really have a whole lot about path handling itself
… And then the second comment to be clear is that relative ref is not being removed but being deprecated because of the risks it inherently builds in
… And so, it doesn't break existing uses, but directs, um… Uh, implementers to
<Zakim> JoeAndrieu, you wanted to ask about post 344 expectations
Stephen Curran: move away from the use of relative ref and move on to other approaches that would handle a similar functionality. So I think that with that introduction, I'll look for the queue and
Will Abramson: Yep. Joe is on the queue. Joe?...
Stephen Curran: Yeah. Mm-hmm...
Joe Andrieu: Yeah. I was trying to find the language in there. I'm I'm curious what your expectations are are around the path handler path service...
Stephen Curran: So...
Joe Andrieu: Because those are in this PR in a way that I thought would be enough, so...
Stephen Curran: Uh, I didn't...
Joe Andrieu: if there are missing elements, we might be able to get it in this PR. I'm just not sure what your delta is that you were hoping to...
Stephen Curran: Didn't… I thought you had specifically said you expected a follow-on PR?...
… Um, I… off the top of my head right now, I don't think it was… things were there. My… my sense is things are not fully there, but, um, I don't know specifically
Will Abramson: um...
Stephen Curran: Um, at this moment. Marcus?...
… Sure. Yep
Will Abramson: Yeah, so sorry, Stephen, can I just ask that you maybe take a test to have a little review around this and see if there are things that you think need to be added? That's great. Uh, Marcus?...
Markus Sabadello: Yeah, 22 comments on this about the relative ref. There's been a lot of discussion if the proposed path handler and path service are a complete replacement for relative ref. And so if we...
… deprecate relative ref if everything that we did before with the service and relative ref parameters can still be done. I think I've shared some experiments and some examples which demonstrate that
… that this is not a complete replacement and that we still need relative ref, but I'm curious what everybody else is thinking at the moment
Will Abramson: Thanks, Marcus. Maya?...
Manu Sporny: Uh, yeah, so, um, a plus one, uh, to...
<markus_sabadello> See w3c/
Manu Sporny: uh, defining a standard way that DID URL paths can be handled. I think Path Handler and Path Service is, um, a really good approach to that. Um, uh
… noting Marcus's concerns that, you know, maybe it isn't a full solution. Uh, in general, uh, I… we need to move away
… from effectively courting query parameters together
… to have different outcomes with did URLs. I'm saying that generally, I'm not saying like sometimes it's not helpful to do that, but I think it can lead to things that are very confusing to implementers who will probably get it right. But then developers that end up using did URLs will probably get it wrong or
… do things that, uh, lead to, um, attacks in, in, uh… just lead to attacks, right? So, so this whole concept of, like, courting a bunch of different query parameters together to get different outcomes
… uh, I think is challenging. I'm not saying we can get rid of it, but I'm concerned about it. And so, anything that moves us away from that for, uh
… common functionality, um, like path handler and path service, I think is a good move. Um, I… plus one to deprecating relative ref. I am very interested in hearing from Marcus about, uh, what use cases can't we accomplish if we do that?
… Um, meaning… and, uh, and that doesn't mean, like, preserve the way we did it in the past. It's quite literally, it is impossible to achieve
… Uh, this use case, and then it would be good to know how many implementations out there, or DID methods out there, uh, are very highly dependent, uh, on that, um, on that particular use case
… I feel like we did a pretty big exploration of the space when we worked on Path Handler and Path Service, um, and so, uh… I'd like to understand how many people have deployed this in this way
… to figure out how big of a break this is for the ecosystem. So, just because it existed before, doesn't mean that we need to continue to support it. Um, that's it
Will Abramson: Great. Thanks, Manu. Um, Joe?...
Joe Andrieu: Uh, yeah, I think actually some of us have a goal of not having a complete replacement because relative ref introduces security concerns that we are explicitly trying to avoid...
… So the the ability for relative ref as it was defined before to replace every single part of the service endpoint except for the authority part which is basically the host name and port. That is what we are trying to fix
… So allowing a parameter in the did URL to be able to rewrite the query part, the path part, the fragment part, all the parts, I don't think is something that we have a use case to support. And we do have security concerns to support
… This is actually an attempt to fix that problem. So, plus one to deprecating. We can keep it in an extension. We can say, hey, there are some concerns that have been raised. Please consider these concerns. And in some future version, we might go beyond deprecating it and deleting it. But the point now is to have a transition period
… where it is handled as a query term by those pieces of software that that want to handle it. And it is in the spec defining how you would do that along with some sort of warning, saying, Hey, this has security concerns. You can go look at the threat model and and see if you understand those or share those concerns
… But I wanted to push back Marcus against the notion that it should be a complete replacement because the the point here is to actually change the functionality
Will Abramson: Thanks. So, Marcus?...
Markus Sabadello: Okay, and a number of things. I mean, I've explained all of this in the GitHub issues and comments...
… I've heard several times that it is a complete replacement, right? Joe, you said it's a complete replacement, Dimitri said it's a complete replacement, Steven and Will, I think you thought that it was a complete replacement until you looked at my examples, and then I think in the comments you wrote that. we still need relative ref. I mean, I
don't want to put words in other people's mouths, correct me if I'm wrong, but that was my understanding that after looking at these use cases and the examples, those of you who looked at them all also concluded that
… But the path handling stuff is not a complete replacement for relative ref. To Manu's point, what exactly? That would not be possible anymore. This is basically the ability to pass. in the DTRL parameters to the resolver, and separately to the service endpoint. That's what becomes impossible. If you want a DTRL where, for example, you have a
version ID
… It affects the resolution process and you also need to pass query parameters to the service endpoint. This has always been supported by a combination of service and relative ref. And I think it's not anymore
… supported with this change, but there seems to be different opinions on that
… I wonder if we're clear that it's not a complete
… replacement, and uh… I think that's
… That's a problem. There are concrete use cases
… And concrete implementations that are using this, and I don't see
… Why, uh… why we should reduce the functionality that we… we support. Uh… Two more comments to Joe, um
… The security problems that you expressed with RelativeRef, I think, have not been sufficiently discussed
… disagree that there's really a big security problem with that. That doesn't also exist in the path handling approach. I think if it is a security problem
… then it exists in both approaches. I also disagree that this path handling
… proposal is the way to fix it if it is a security problem, right? We could also keep relative ref and change
… the construction algorithm to appending… appending strings, which is what… what you, you know, would like to do. So I… if there is a security problem, then I… I disagree that this proposal is a
… necessary fix. And finally, I also disagree that there is a transitional period, if 344 is merged, that would still
… make it work. If 344 is merged, then in the provisional algorithm, the previous DDRLs would immediately stop working. There's no transitional period
<Zakim> JoeAndrieu, you wanted to say that is not what people have said
Will Abramson: Um...
… Okay, thanks, Marcus. Uh, Joe?
Joe Andrieu: Yeah, so maybe I'm confused by what you mean by complete replacement, Marcus, but I literally just described how it's not a complete replacement. So we're clearly talking past each other on that point. This is not a complete replacement. There's a security problem, which you just spoke a little bit to, although you dismissed it. So it
is not. it is explicitly not intended to be a complete replacement, so I'm not sure why… what… what you… maybe there's something else you're trying to get at there, but I don't understand it. Um… the… the security problem is...
… that the context is misused for this algorithm. This algorithm is for the author of a web page to specify that another resource on the same server
… Should be linked to with this shorthand that they're going to use that uses a base URL to combine the relative ref within an HTML page that lives in the same domain
… Dids do not show up in the same domain that the did controller controls. So we no longer have that the party who is placing the did in context or the party that is perceiving the did in context has control over the did document. So. We're simply using what seemed convenient
… In a way that I believe is profoundly insecure precisely because you can rewrite every part of that service endpoint and I don't believe that's what people are going to expect
… Um, and that is a security problem, and I understand that you don't agree with it, and you don't think it's significant, but I think several of us have been convinced of that fact
Will Abramson: Thanks...
… Uh, Aaron, can you… Can you jump on the queue?
Aaron D Goldman: Did we specify anything about what protocol handlers you can use? If I set my base URI to be, say, JavaScript colon, I could do JavaScript in the page? Ah, sorry...
Will Abramson: Aaron, can you get on the queue? Do you have ISC? Thank you. Um, are you in ISA?...
Otto Mora: I think he's driving...
Will Abramson: Oh yeah, right. Okay, uh, sorry, that confused me, but I'm on the queue, and I did have something to say. Um, it was that… I think there's been confusion around this complete replacement thing, and I know where that confusion comes from, right? Like, there is...
… comment in 344, where Joe says, I remain convinced that this is a complete replacement, but after that, he also says, in a way that closes security holes, which I think is where the confusion is. Like, Joe's saying this is a replacement, but it doesn't obviously. Do all the features, because some of those features are
… uh, security concerns that he's trying to address, or that my deprecating relative graph we're trying to address
… The other thing I wanted to say is about my comments on 322, like, I do think there is something about relative rev that
… maybe we can pull across into the past service stuff in some way, and I think that, for me, is about
… query parameters, right? Not being able to rewrite the path, but being able to pass through query parameters that you want to be applied to the service endpoint, but not to
<markus_sabadello> JoeAndrieu How would I achieve this use case without relativeRef? did:ex:1234?service=dpp-1&relativeRef=%2Fproduct%2F9f7866e1-4bc5-4495-9f75-308350a37280%3Fversion%3Dlatest
Will Abramson: you know, at the moment, there is no way to do that, right? There is no way for you to say, I want to use this service endpoint, but I want to add a service parameter onto it
… That's my understanding, that's not supported. It's not supported in the current path handling approach, but relative rep does provide a way to… To do this. Just so you know
<Zakim> manu, you wanted to see if anyone thinks it's a complete replacement? and to ask if anyone believes there shouldn't be a transitional period.
Will Abramson: Okay, that's all I wanted to say. Uh, Manu
Manu Sporny: Yeah, going back to, uh, Marcus, I think your comment that we're claiming it's a complete replacement, I don't think anyone in the group...
… is claiming it's a complete replacement. So I think we can set that to the side, unless somebody wants to object to that statement. I don't think any of us are saying it's a complete replacement for relative rent, so
… Let's put that to the side. Plus one to, you know, Joe's concern around the security issue. We have discussed that before. Maybe you weren't on that call. I do think it warrants further discussion
<swcurran> Not a complete replacement and specific lost features -- query params on the resource URL
Manu Sporny: Um, but again, the proposal is to deprecate relative ref, it's not to remove it, and that to me means that we're not removing the functionality, uh, in this version. We're just signaling to the community that we are planning on deprecating it, and the reason we
… are signaling it to the community in that way, so that we can hear back from implementers, um, that would be greatly negatively impacted by that. So. Uh, you know
… I don't… so, so, one, I don't think anyone's saying that this, that path handling, uh, path service is a complete replacement. Um, we're not saying we're removing relative ref functionality. Uh, we're expecting there to be a future, you know, realignment of the spec that
… you know, keeps that in there, but with the notion of deprecating it. Um
… I don't know if that helps, Marcus, but, like, that, you know… meaning, like, there's further stuff to discuss, but I don't see this as disruptive as you are
… Asserting it is, um, that's it
Will Abramson: Yes, thanks for that. All right, Manu, I agree. Marcus?...
Markus Sabadello: I mean, I think… so first of all, there have definitely been claims that this is a complete replacement. You can find that in the logs or in some...
… GitHub comments, that's… that's why I tried to create examples, which… where I would not know how to accomplish the same thing
… with the path handle, I just put a DTRL also here in the chat, which is in one of my issues
… And I don't know how to do that, right, without using relative ref. And I think everybody should be aware of that, that there are
… Functionalities, there are requirements, there are use cases, which
… Unless somebody tells me how else to do it, or the group says we don't care about those use cases, they would not be possible anymore
… And in 344, if you actually read the pull request and if you actually go through the algorithm, it doesn't work anymore. It's not like there's a transitional period. It will continue to work. But if you follow that algorithm, if you actually read it
… you will see that these TTRLs immediately stop working. And finally
… Joe, I also made an argument that if there are security aspects with relative ref
… then, uh, that could also be fixed in relative ref. It's not a necessary argument for, uh, introducing the path handling stuff
Will Abramson: Okay. Thanks, Marcus. I mean, I take your point. Maybe people said there was a complete replacement in the past, but I think now everyone is aligned that this is not a complete replacement. So I think we need to drop that now. Uh, Aaron...
Aaron D Goldman: Yeah, my question was if there was any restrictions that we were specifying on which protocols you can jump to...
… So if I have a relative ref to a base URI that's a JavaScript
… or a data URI. Do we care? Do we allow that?
Will Abramson: Hmm. Okay...
Aaron D Goldman: Do we want to specify that, or specifically not specify that?...
<Zakim> JoeAndrieu, you wanted to say that's the problem
Will Abramson: Thanks...
… I think we don't say anything about it, but maybe others know. Joe?
Joe Andrieu: Um, yeah, I think, Aaron, the point is, in fact, to support all of that, which is part of the debate about the function signature that hopefully we're on the other side of. Um...
… But the previous requirement for the function signature would not have allowed you, for example, to pass a function into the dereferencing algorithm. So we do want the whole point of the handler strategy. is to not
… Um, prescribe how these things are handled. But to say, if you know of a handler, you can use it, and we do not have a registry of those kinds of handlers. Um
… But to to respond to, some other elements that one of the things you had said Will was that the
… The arbitrary passing of query parameters all the way through the stack is a good idea. That's what I'm challenging. That is the security goal. So the use case that we have identified as meritorious and worth trying to figure out how to support
… is to have a file service in the cloud, where I can have a DID that's basically pointing to that file service, and I can hang additional path information so that I could get to different files in that file service. And we can do that just with managing the path. But when we allow the arbitrary rewriting of query parameters that pass all the way
through
… to the endpoint, um, then we're… we're connecting domains that do not have a shared authority or a shared contents of security in the way that Relative Ref does on a web page, where the author of the web page is. understood to be authoritative for the site. Um
… So to answer your question about that particular URL, Marcus, simply define a type for that service DPP that handles relative ref and you're good
… What I've done here is… is to define a default service handler, because there were some concerns over what do we do with exit stuff, and I said, hey, alright, we'll come up with a default service handler, we'll figure out how it
… fits in the handler determination strategy. Um, and I am not going to enshrine a security hole of the kind that propagates, uh, uh, parameters all the way through the stack
… Um, I'm gonna pose that, because I think that's a bad security architecture. So that's why it's not in the default service handler, but you can have another service handler, you just need to define a type, and then define how that handler works for that type, um, and it can all work
<Zakim> swcurran, you wanted to say a question about whether we are ok to lose the feature that Markus is talking about
Will Abramson: Okay, sure. Steven?...
… Okay
Stephen Curran: So Manu outlined that it's not a complete replacement, and we're good with that. And what Marcus said, though, was, here's the specific thing that we lose, and I just wanted to point that out. And and...
<JoeAndrieu> +1 for the question
Stephen Curran: blatantly ask the group, are we okay to lose that feature? Which is, essentially, you can't pass query parameters onto the
… the URL of the resource you are referencing
<JoeAndrieu> (in that its a good question for the group to decide)
Stephen Curran: And, um, so I think there are valid use cases. I do agree that there's a pile of things that, um, have to be done, and those are in the… currently in the, um, normalization section
… um, the URL normalization, um, that needs to be addressed, and a lot of that is about relative ref and the risks it involves, and the things Joe was talking about, about dots and double dots, and
… Um, um, presented coded dots and things like that. Those
… Probably have to be a direct no matter what. Um, not sure if those
… or become a did problem, or become whoever handles the URL after it's produced, but either way, those have to be. Um
<Zakim> manu, you wanted to note we don't speak to which protocols you can jump to because we don't know how people might use this.
Stephen Curran: addressed. Those have to the normalization has to happen and have to be done in a secure way or as secure as possible. That's it
Will Abramson: Thanks, Stephen. Matt?...
Manu Sporny: Yeah, I do respond to that. I don't think we're gonna implement relative ref. So as an implementer of Digital Bazaar, we're probably gonna turn off relative ref in all of our implementations to start out with. We may implement it in the future if we hit a case where we need it...
Manu Sporny: Uh, we have never needed the feature...
… over the past 7 plus, 8 plus years. That doesn't mean that other people don't need it, um, right? But, uh… but just to… I think it's fine, get rid of it. We're not going to implement it. I want to make sure that the spec doesn't require, mandate the implementation of relative ref. Um, uh, and that's kind of where we are going as a… Uh, as
a company that's implementing, um
… But, you know, that conversation is, like, a little moot, right? Because we're just talking about deprecating it here, right? And if it is mandatory to implement, we don't want it mandatory to implement. That's the other thing that… Uh, we're concerned about, um
… And just a reminder to the group, just because we say it in the spec doesn't mean people are going to follow it, right? So if we deprecate it and say it's getting, you know, phased out, that doesn't stop anyone from implementing it anyway
… And if we put it in the spec and we say it's mandatory, well, that doesn't mean that people are going to implement it. I think that the concerns that
… Joe raised are real concerns. We should explore them, but at
… well, we have to explore them if we leave it in the spec, because the threat model has to reflect something, uh, you know, that, that, uh, that talks about, uh, the concerns that, uh, Joe's raising
… Anyway, hope that helps. You know, that's our kind of position as an implementer
Will Abramson: Thank you, Marcus...
<swcurran> +1 Manu
Markus Sabadello: Yeah, I think Stephen summarized it well that what we would lose is exactly the ability to pass query parameters to the service endpoint. Okay...
… This is the first time I hear concerns with that. Maybe I missed it earlier. I thought Joe's concerns with relative ref were mostly about the
… path processing and double dots and processing relative references according to the URI RFC and that Joe essentially preferred an append, a simple string append. Functionality, and instead of that, I
… Don't remember hearing about concerns with… passing query parameters to a service endpoint, I really fail to see how
… Passing and appending a path
… Would be less secure or would be less problematic than passing a query parameters. I I don't understand why
… We're okay with passing a path to a service endpoint, but we're not okay with passing query parameters to a
… service endpoint. As I said, there are existing use cases. We've always had this, nobody ever has ever
… I haven't had any problems with with this, but I'm
… Happy to hear that we're now on the same page, that we're losing functionality
… And I don't think we should because there's no reason for that
Will Abramson: Sure, thanks. Um...
… So, I think we're, yeah, we're all on the same page. We are going to be losing the ability to pass query parameters to service endpoints. We're not losing, right? Deprecating this ability. um… I guess I had a question, or to… Joe, around, like
… Currently, in the spec, the old algorithm did define how to handle relative ref. It said, this is what you do when you get a relative ref
… And I think it sounds like your algorithm today isn't going to talk about that at all. And then if somebody wants to support relative rep, then they define their own type in a different effect, right? And say, this is how you support relative rep
… Like, to me, that sounds a little bit more like we're getting rid of relative breadth from spec, apart from maybe as a query parameter in section three that is just in there but doesn't need to be implemented. Is that true? Um, and I see Marcus here on the queue. Marcus?
Markus Sabadello: Yeah, again, the functionality is really removed. There's no transitional period. The URLs that work today, again, I mean, I'm repeating myself, but in 3, 4, 40, it will stop working immediately...
… When when Joe says you, you have to define some kind of service handler
… then that's not realistic. It's very impractical. I mean, every time I introduce a new service type, I have to define a service handler, I have to write a separate specification for each service type, just to make. Relative ref work again
<Zakim> JoeAndrieu, you wanted to say the problem isn't that you can't have query parameters, it's overwriting query parameters
Markus Sabadello: That's not a transitional period, right? That's a breaking change
Will Abramson: Yep...
Joe Andrieu: Um...
… Yeah If you don't override with the service type then relative ref will be processed. So
… it is in the algorithm, and is in where I believe is the appropriate place, that if you make it all the way through
… the selection of a handler, and you don't have a specific handler that you've identified. Um
… And you get to a query part, and there is a relative ref, then software that wants to process relative ref has the opportunity to do that, and that is defined in the algorithm
… What I have done is create a default service handler
… That will, um, be, um, used for those, uh, path…those…did URLs that have a path
… Um, or that have a service that doesn't have a, um
… Uh, service handler defined. Um, and I think it is… it would be irresponsible of us to
… Um, enshrined this behavior relative ref that comes from an HTML page, I just think it's the wrong use case and it creates security problems. And so, um, you know, I, I think Marcus, if, if you really want a service handler type, that a service type that has relative refs and go ahead and create and we can
… potentially even get it into a registry such that this can be live as soon as you care about it. This specification doesn't change any software that's out there in the world
… It's just charting a path for interoperability that doesn't and and in this case, we're removing a security problem. That's it
Will Abramson: Okay, thanks, Joe. Marcus?...
Markus Sabadello: I don't think that's...
… true what you said, Jocio, about how it works in the current algorithm, because in the example I gave you, there's a service parameter and there's a relative ref parameter, and the way it works is that
… The service parameter, uh, selects a service from the, the document, and then the relative ref, uh, applies the relative reference to that service endpoint, uh, with
… Your algorithm
… it would not process that relative ref, because you have this default handler, which doesn't… which deletes that functionality, essentially, and I cannot… You cannot ask implementers to write separate specifications
… for each service type that they want to use. I may have a lot of different service types. I may have a service type for my website, for my GitHub repository, for my business card, for my photo gallery, so all kinds of
… types of services that I want in my DID document and I want to be able to apply relative references including a relative path and query parameters. I want to encode them in the DDRL and I want them to be added
<Zakim> manu, you wanted to ask if the functionality is removed if we're saying we're going to define it in the spec? -1 to not having a transitional period.
Will Abramson: Thanks. Manu?...
Markus Sabadello: to the service endpoints, and I cannot write new specifications for every single service type where I want to do that. This has always been a generic. functionality, and with your algorithm, uh, this immediately stops working, as I said before...
Manu Sporny: Um, yeah, I did a quick scan through the spec for mentions of relative ref, and there is a problematic statement in there...
Will Abramson: That's it...
Manu Sporny: Um… let me try and find it. The default handler does not process relative ref parameters. I think, Joe, you're saying, but you can fall through to another handler that does do that. I think that's what you're saying, Joe...
… Um, my concern is that, uh… Without it
… really being defined. I think technically you're right, Joe, like, anyone can implement it if they want to, but we're not giving clear guidance, uh, either way, and we don't speak to the security concern, uh, that you have, Joe, which then basically means, like, there's no justification. Uh, for, uh
… I get what Marcus is saying related to there is no transition period
… Um, we are just presuming people have implemented relative ref in, you know, some kind of way, and then we're gonna be silent on it in the spec. I think we should be more explicit about
… Deprecating it, uh, and or, if we all agree that the security issue is so grave
… uh, we should explicitly ban it, um, but I, I think we need to have that, that discussion. So the, the slide says we're gonna deprecate it. The spec
… deprecates it silently, uh, by effectively not saying much of anything. Uh, and I don't think we should… we should do that. I think we should explicitly talk about relative ref. Um… in the spec. That's it
Will Abramson: Uh, yeah, thanks, Manu. I think I do… agree with that. I mean, maybe we can have some more, like, sort of examples of all the security issues this will cause. I mean, the other thing I thought, Joe, you say in your, like, Q-plus comment was, you know, the issue is query parameters overriding...
… query parameters that have been defined. Like, I see that, right? Like, there's a service endpoint that has a query parameter, and then I do a didURL and change that query, you know, has the same query parameter, then what happens? But
… I mean, I'm wondering if there are ways we can write the spec so that we handle those issues, rather than just saying this is a security concern, so we're not going to allow that at all. Like, I do have… I think there are some interesting use cases where you do want to allow
… Security
<Zakim> JoeAndrieu, you wanted to say that's exactly what I said. If you don't have a service parameter, it works. Yes, your URL won't be handled, because it is a security problem
Will Abramson: query parameters to pass through to the thing. Like, for example, to a verification method, I've thought some ways that you'd have a query parameter that triggers on a verification method to reveal certain keys. As I think, anyway. Um… I don't know. Uh, but I do agree with Manu, what he was saying. Joe?
Joe Andrieu: Um...
… Yeah, so the deprecation language is not in there. I agree with Manu on the point that we should discuss that. This PR did not have that language
… Um in fact it it didn't handle relative ref in any way whatsoever Um and it did not have a default service handler in the first version of this
… Um, so that note is, in fact, to trigger this conversation, so that we can figure out what do we want to say about it. Um… uh
… And as as Will just mentioned you can have a query parameter in your service endpoint. The security problem is when the DID author, who could be anybody, um
… can override what's in the service endpoint in the DID document. They can override everything except for the host name and the port and the scheme. Um, so… And that's the essence of the security concern
Will Abramson: Uh… Marcus?...
Markus Sabadello: Okay, well, I'm happy that we're agreeing now that...
… The path handling proposal is not a complete replacement for what we had before. I'm also happy
… To hear that, maybe there's some
<smccown> Part of my concern is that relativeRef enables a caller to interact with a service endpoint based on their knowledge of the internal implementation / structure of the service endpoint's structure. This is generally considered a security problem (e.g., path traversal) in many system. Perhaps, it would be good to re-evaluate what is being intended
<smccown> to be accomplished and look for a safer way.
Markus Sabadello: some insight that what's in 344 right now does not have a transitional period that will make RelativeRef continue to work
… And regarding the security problems, I still don't get it. I mean
… even with the path handling stuff, there are certain elements that come from the TTRL, from the TT author, that could be anyone, as Joe says. There are some elements that come from the TTRL, and are then. uh, applied to the service endpoint from the D document, uh
… The difference is that with relative ref. There's a
… it's a bit more flexible and more powerful, and maybe, because of that, a bit more risky, because, as Joe says, it allows things like double dot, and it also allows adding query parameters to the. to the service endpoint, I
… I think there are a lot of use cases for that. I think it's unnecessarily restrictive to tell people that when you construct a DTRL, you can
… You can specify a path that will be added to the service endpoint, but you cannot specify query parameters that will be added to the service endpoint. I think that's restrictive, and I actually don't share the security concerns, to be honest
… If you say that anyone can construct a DTRL with
… dangerous parameters that will be applied to a service endpoint. I feel like
… it's… this argument applies to any kind of relative reference that you find… you can find anywhere on the web, right? If you have a link on an HTML page, anyone can put any link in there
… With relative paths and with query parameters, and if somebody operates a web server that returns 302s or 303s with a location header that can also contain relative references, people can also redirect you anywhere in a relative ref with a relative path, and any
… service parameters that will be applied to the base URI. I think they're… that's the architecture of the web, and just like you wouldn't click on an untrusted link, you shouldn't dereference an untrusted. I'm looking at the URL, so I think all of this
… So really needs more discussion before we just blindly make such a profound change
<Zakim> manu, you wanted to speak against features that have complex security characteristics. and to say we're not just talking about HTTPS URLs
Will Abramson: Thanks. Marcus Manner...
Manu Sporny: Um, yeah, uh… I guess the first point is to go back to something Aaron said earlier in the call, you know, how many different types of URL schemes are we supporting? And I think Joe's answer was, you know, all of them, we're not restricting anything, and we don't know if we really want to do that kind of restriction...
… Uh, this early, we just don't have enough implementer feedback on, you know, what schemes are dangerous, what ones are
… clearly good, you know, and we… I don't think we want to say that right now. So… so, it could be any, uh, protocol scheme, uh, that's… that's used, um, and because of that, it makes it really hard to… uh
… uh, reason through the security characteristics of, you know, supporting all the schemes. Um
… and so we're not just talking about HTTPS URLs here, we're using HTTPS URLs because it's easy to kind of talk about, uh, the… the concerns, which I think Joe's gonna do, uh, after me, but, um
… the world's bigger than just HTTPS URLs, um, and… and that means that, you know, pretty big minus one
… to any features that have complex security characteristics that, uh, developers have to reason through on a regular basis. I think it will lead to a more vulnerable system
… I'd much rather have something that is fairly locked down in what it can do, uh, and be limited, and not support all of the super fancy use cases, um, than have something that is effectively, uh, could be a foot gun
… to developers. So that's why this whole, like, being able to rewrite, having an attacker, giving an attacker the ability to rewrite a query parameter that's going into, you know, a dereferencer
… feels dangerous to me. Um… I think people have spoken to it, and given the choice of supporting something that
… you know, could be implemented in a safe way, and not supporting the thing that could be a foot gun. Like, much rather not support the foot gun just yet. We can always open it up in the future. Um
… But for now, you know, minus one to complex
… you know, uh, secure… complex features that have security implications, like the ones that we're talking about. Let's just get 1.0 shipped, and then we can, you know, talk about it in 1.1 or 2.0. Um
… to speak to, you know, the deprecation thing, in order to deprecate something, we have to define it. I think that's kind of where Marcus is coming from, I agree with that. Um, but when we define it, you know, we should
… Uh, be very clear about why we're deprecating it, and um
… Yep, that's it
Will Abramson: Thanks. Um, yeah, I guess I...
… I mean, I agree with a lot of what Manu said about, let's keep it simple, this is 1.0, you know, if people come back to us. The features are, like, you know, people can always extend this stuff in ways that they want, right? Like, this is just what we're putting in the spec the first time
… That being said, like, and maybe this is, again, what I just said, like, I
… and I don't… I'm not arguing strongly for this, but just personally, I think it is an interesting feature to be able to pass query parameters through, but maybe, again, it's complex, and we shouldn't be bothering to figure that out, because we don't have people asking for it, blah blah blah, all that stuff, but
<Zakim> JoeAndrieu, you wanted to point out that most web pages don't allow just anyone to edit them. that's the essence of CORS
Will Abramson: I guess my wondering was, are there things that we could do to make that, you know, to mitigate the security risks that come with that? Anything. Joe
Joe Andrieu: Um...
… Yeah, just to try and answer your last question, um, someone could come up with a
… Complicated way that, um
… Uh, for example, you could annotate your endpoint as to whether or not it allows this capability. Um, which actually is what the
… the… the service type does for us. So, I… I
… I think the right way to do it is to have a service handler that does it. The
… My problem is, if it's done by default, it will. So, if it just automatically happens, then I don't think you and I can square the differences between those two. But I wanted to engage with something Marcus said that I think on its surface was wrong
… And it may help Marcus, I'm hoping it actually might help you understand the security dynamic. A web page is not something that anyone can edit. I host lots of web pages for my company or my personal blog or whatever
… And for most of those, for most of my career online, I'm the only one who edits those. Uh, and in fact, that is the security
… Perspective that is behind cores. Cross-origin resource something security maybe Where the presumption is if it comes from the same domain, it's under the same authority. And so that allows certain types of behaviors and disallows other types of behaviors
… And so, the presumption is that the person who has written the webpage is the same authority that is running the server, and so when they put URLs in their content, it is from the same source
… There is a known problem in, say, blogs that allow open commenting
… Where people who are commenting put in URLs that are attacks
… And this is exactly the thing I'm talking about. This is now content that's a URL that is getting embedded in a web page in a manner that isn't created by the authority that owns the website and who controlled the web page, right? And every time I've had commenting turned on in any of my services
… It was just a matter of time until, um, it was attacked in this manner. Um, and so that's the disconnect that I'm seeing, which is that we are not in a web page
… We do not have a relative ref within a course context within an authority in a domain. The authority is in the controller
… And in the DID document. And that is not under the control of the party who has created the DID URL, it's under the control of the DID controller. So, I don't know if that helps, Marcus, but I'm trying
Will Abramson: Thanks, Joe. Marcus?...
Markus Sabadello: Um...
… I don't… I think it would be good to write this down and then consider it. I mean, I… I think there's a lot of… new information
… I don't really follow what this has to do with embedding in HTML pages. I mean, I agree that
… Not everybody can edit the HTML page, and I think I understand a bit the… Course. argument, but I… I still don't… I don't really understand why this would be a… a problem with
<JoeAndrieu> the 3986 algorithm was written for web pages not for DIDs in the wild
Markus Sabadello: with DT URLs or with with relative refs, since that is, since deeds are not, I mean, deeds are not
… dependent on, on the web, right? These are, are separate, it's a separate URI scheme, it's, it's not an HTTP
… URL, but maybe we can… we can write this down and then… and then analyze that
… I would also note that I, as I said earlier, I'm not
… Convinced that, uh, proposed other
… algorithm with string append functionality, if that really solves it, because it also allows double dot syntax that will be applied
… to a service endpoint URL. Um, and as Will said, uh, yeah, I also think there is, uh
… useful functionality by being able to apply query parameters
… So I think this needs to be written down and analyzed. And uh
… Yeah, I don't know, we have a few minutes left, I'm not sure if… what's the plan is for tomorrow, if the plan is to
<JoeAndrieu> the path part is driven by a particular use case
Markus Sabadello: have a vote to merge the pull request. I object to that. I think we should not do that unless we understand all the implications with regard to the path handler functionality
… I disagree that this is simpler than what we have now, right? There was a comment about what is simple and what is complex, and we should start with the simple thing. I think what we have right now is much simpler than
… what is being proposed. We've had more than a thousand GitHub comments, and the design of the path handle is still not finished. So I think if we cannot get to a conclusion on these open questions, then we should not
… Uh, merged the PR, and as I… as I pointed out in
… my last comment in the PR, there are also a lot of other changes that we haven't discussed at all, such as removing the accept, or the verification relationship, or the service type inputs
Will Abramson: Uh, thanks. Yeah, so we are running out of time. Um, I just wanted to speak to what you just said then, Marcus. We will not be voting on the PR tomorrow. What we are going to do is get this PR up to date with the latest...
… you know, consensus, I want to say, maybe not quite, but from the group, from this spreadsheet, like, at the moment, the PR does not reflect what we've been discussing for the past month or two. We're trying to get through this discussion, we can do that update, uh, and then we will decide whether we're going to adopt that. Yeah. Into the group
… But we can't do that until the PR is up today. Uh, we're gonna go through the queue, and then we'll finish up today. Steve. Thank you
… Yeah, you're on mute, Sue
Steve McCown: Yeah, sorry, my Zoom was halfway off the screen. I couldn't see the mute button...
… So I just wanted, I just wanted to comment. I'm, I'm squarely on the side of keeping things secure and I'm
Will Abramson: Yes...
Steve McCown: It seems like our intention for relative ref is to be able to invoke particular functionality in the service endpoint...
… And that's good, that's fine. But the problem with that is it opens the door in a number of ways for attackers to misuse that feature. And. And I'm just observing the conversation that we we
… whenever we discuss this, we tend to talk about there are good uses for relative ref
… and we seem to want to kind of ignore the potential misuses of that feature. The problem with doing that is, even though we can build useful things using the feature
… Is that we put a lot of, um, pressure on the service endpoint implementers to make sure that they're security conscious and aware of all these things, and they, um
… they take lots of mitigations to block these misuses of of something like relative ref versus just keeping the spec safer for them to implement more easily. And I and I think. Come
… that's just a different take on the on the discussion. But I think we need to work on keeping things safer rather than leaving the door open for potential misuses, simply because it's a it's a convenient and
… Convenient way to do that. But I just think that
… letting callers manipulate the service endpoint because they're aware of the underlying platform or architecture that it's riding on
… And that's not always such a good idea. So I just wanted to comment to that. Thanks
Will Abramson: Thanks, Steve. Um...
… Yeah, thanks, everyone. We'll meet again tomorrow. And I just want to quickly say, Marcus, we are going to respond to all of your comments on that issue. We're just not going to discuss them in this call until we've responded to them in writing
<ottomorac> transcriber-bot, stop
Otto Mora: Hey, Aaron, are you still there?...
… Can you hear me?
… You're on mute
… Can you hear me now?
Otto Mora: Yeah, yeah, no worries. Um...
… I'll, um… I sent you a request on LinkedIn, if you want to message me through there. I can send you the link for the invited expert application
Aaron D Goldman: By the next one, yeah...
Otto Mora: No worries, sir. Take care...
Aaron D Goldman: See you around. Bye...
<ottomorac> transcriber-bot, help