Meeting minutes
<ottomorac> transcriber-bot, status
Agenda Review
<ottomorac> transcriber-bot, resume
Will Abramson: Um, yeah, so we'll just briefly touch on the working group charter extension. I'll hand over to PA for that...
… And then, uh, debrief on the special topic call yesterday. Um
… Then we're going to touch on some open PRs that I'm hoping are going to be less controversial, and we can just get them through, and then
… Um, if that's successful, we'll go on to some of the more controversial ones. And finally, I want to have a bit of time at the end just to discuss next steps. Like, initially, I was thinking
… Um, you know, we can have… we will have a special topic called next week, but let's figure out what… what is most valuable for us to discuss in that call. Okay
… So
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): sorry, just before we keep going here, um, I noticed that there are two agendas in the calendar item...
Will Abramson: Oh, okay...
TallTed // Ted (he/him) Thibodeau Jr (OpenLinkSw.com): It'll be helpful if that can be trimmed down going forward...
Will Abramson: Yeah, thanks for watching tonight...
… Yeah, actually, on that note, does anyone else have any other agenda items to add for today?
… Uh, ma'am?
Manu Sporny: I guess, um… where do we know where we are on charter extension?...
DIDWG Charter Extension
Will Abramson: Yeah, that is on the agenda, that is the next item...
Manu Sporny: Okay. Okay, sorry, apologies, I was late...
Will Abramson: Um, great, yeah, so that is the first thing I want to discuss, and I'm just going to hand over to you, Pia, and maybe you can give an update on...
… The process, and uh… what we expect from that
Pierre-Antoine Champin: Uh, yes, so, uh, it's on me, and I haven't, uh, progressed on that yet, I'm sorry, uh, but, uh, basically, to get an extension...
… All, all I need to do is make a request to the team
… This is a team decision and motivating that, so, uh, it's on my list for my… it should be done by the end of the week
… Um, and then, uh, the decision should come in the coming days
… well, count a little more, maybe, because of the A/C meeting next week, but, uh
… Uh, we should, uh, we should have an answer pretty quickly. Uh, the goal after discussing with the chairs is to request, uh
… A 6 month extension, which is usually considered the maximum we can ask for and
… Not consider a re-chartering for the moment
… Hopefully we can we can
… get the deed resolution, uh, through, well, both through, but deed resolution is more at risk. Uh, we can get all our right track through, uh, in those 6 months
Will Abramson: Great. Okay...
… Yes, I mean, if people think that there's a better route, and that we should be focusing on re-chartering, then do jump on the queue and say so, but… My sense is
… We just want to finish the work, and 6 months should give us enough time to do so
Debrief from the Special Topic call for 14th Apr
Will Abramson: Okay, I'm on the queue
… So, let's move on. Uh, yeah, I just want to spend a little bit of time to debrief from
… yesterday's call, I think most of us were there
Will Abramson: Um, but we can just touch on it quickly. So it was a productive call in that we reviewed this, uh
… document of the sort of itemized changes that Joe created, and we kind of, uh, traffic light coded them, like green being. You know, this has broad consensus, orange means
… There's some discussion that needs to happen here, but we think we can move forward. There are some folks objecting, and. We need to figure out how we're gonna
… either move through those objections, or have some hard conversations there. And then we
… Ended the call just talking on one of the issues, which is really, like, 4A, and it was all focused on
… Will we support HTTPS binding for digurl dereferencing?
… Didn't come to a conclusion of that discussion
… Um… and we need more time to talk on it. I don't think I'm gonna… we're gonna have time on the agenda today
… But at the end of the call, we can discuss whether it's worth putting that on the topics that. Special topic call next week to continue, like
… Momentum on that, or if there are other topics we'd prefer to
… So, if I missed anything… Do you jump on the queue?
… Okay, give me one moment
… So, yeah, with that, I'm going to continue on
Clarify that "DID resolution" is consistent with "URI resolution"
Will Abramson: So, the first topic, and this did come up briefly yesterday, but this is about a PR that Marcus raised
<Wip> w3c/
Will Abramson: specifically to respond to Jeffrey's
… concern… let me just drop the link in… 318. Uh, this is to address 226, which is about inconsistent use of resolution, which Jeffrey reads as part of his tag review
… and Jeffrey has reviewed this and approved this PR. I think there's some concern from. Some people that, you know, this is
… Uh, while Jeffrey is approving this PR, it maybe isn't completely resolving his concern
… But, you know, this PR has broad acceptance of mind, too
… suggested it's merged from Dimitri. I think Dimitri is also
… in that mind, but I just wanted to open up a little conversation about this PR, and… If anyone has any concerns with this
… Excuse me
… And one thing I will say is, yeah, I think one of the concerns is Jeffrey has not
… yet review did URL dereferencing as a section
… Um, this issue that he raised in 226
… Um, but specifically about text in the introduction. Um, so maybe… The confusion that he has is
… is going to rearrise as we go into… when we ask them to review did URLD referencing
… But, um
… I'm not seeing anyone on the queue, so maybe we're all like, okay, this is fine, let's merge this text. I mean, it has lots of approvals, so… That's great, and always then… you know, I think we can mark his
<Zakim> JoeAndrieu, you wanted to merge, but also comment
Will Abramson: Tag review. Pending close. Um
… Joe
Joe Andrieu: Um, yeah, I think this is an easy cleanup, but I think we should merge it. Um, looking at Jeffrey's comments, I am one of the people who think he...
… he does not… I think his confusion is not cleared up. He suggests things like, hey, maybe that reference to 3986 is just incorrect, and maybe what you should do is lean into that and say
… We are a willful violation of 3986, um, but we're not, so
Will Abramson: Great, that was… Excuse me. Uh...
DID Resolution PR Processing
Will Abramson: Okay, thanks. I'm gonna move on
… So next, uh, we're just going to do some general PR processing, and I'm going to start with some of the. One's really raised from… by Marcus
w3c/did-resolution#301
Will Abramson: better off more. Actually, no, I'm not going to start with 301
… So, this has been, uh, about for a while. It was raised by Steven, who actually is not on the call
… But it is talking about the URL query normalization, specifically to address the security
… issue that was raised. I think it was initially raised in didcore, but moved across to here
… Uh, it seems to have approvals. I guess I just wanted to flag this. Because, you know, this has been open for
… Months now, maybe? At least a month. Um, and it'd be good to get it in, just
… clear out some of these older issue PRs that can pose issues
… Um
… Sure
Joe Andrieu: Um, yeah, I have not looked at this in detail, so, you know, I don't have an opinion against it. Um, my question is, there was...
… an issue that I raised and didcore that I think we as a group do need to address
… Which is, until this discussion, we have not formally defined what a query parameter is
Will Abramson: Hmm...
Joe Andrieu: Um, the definition in Didcore points to 3986, and 3986 says it's the thing between the question mark. And either the end of the URL or a hashtag...
<Wip> This is the issue JoeAndrieu is referring to - w3c/
Joe Andrieu: Um, so it's literally not possible to have duplicate, uh, query terms, and it's one of the things we comment in a note in Didcore. So, I think there's some cleaning up to do. I don't know if it will apply to here
… This actually looked pretty good by my scan, um, but I do want to see if the group feels we also need to update Didcore to clear up that confusion
Will Abramson: Great. Thanks, Joe...
… Um… anyone else have thoughts on this? Uh… Madame?
Manu Sporny: Um, yeah, I think plus one to merge this with a couple of caveats. Um, I did review it in depth when it first came up. There is an enormous amount of text here...
… a lot of it's just kind of, you know, explaining, I wish we could use maybe 25% of the amount of text that we have in here, but I don't see anything super dangerous. It just goes through and, like, tells people about, like, hey
… You know, query string normalization, you know, is a kind of complex thing, and these are a number of things that you need to pay attention to, and it provides some examples of, like, where things go awry
… Um, I wish we were not the ones that had to talk about this, I wish it existed in another spec, plus one to what Joe's saying, we should probably say something in Didcore. But even then, it's not Didcore's job to talk about this stuff, it's really a
… you know, 3986 thing, uh, which does not talk a tremendous amount about, you know, uh, normalization and that sort of thing. So
… Um, I'm fine with adding it, because it does address a comment that we got, um, very thoroughly, uh, but I would like to see us see if we can say less. In the future. That's it
Will Abramson: Hmm...
… Thanks. I mean, I'm wondering, you know, Steven does also mention the length in his initial. phasing of this PR
… Um, maybe we could try and ask for a pass to make it shorter, or, like, someone could take on a task to review it and try and make it shorter. I agree, there is a lot in here
… The other thing I'm interested to hear from the group is, like, Steven mentioned in this PR around
… like, issues that this raises with relative RAS
… And… perhaps it would be better to drop relative ref. I mean, that's not related to this text here, but
… Is that something that we should have a conversation about at a separate time, or
… We just wait and see if it comes up as an issue later on. Uh, man
… Hmm
Manu Sporny: Um, I think… so, let's merge this. I don't think we should… we need to get things merged and get into CR. I don't… an editorial change, I don't think is necessary here, right? Like, we're addressing the issue, we're over-addressing the issue, like, let's just merge it...
… and move on, uh, and keep it focused on just that, that, you know, um, merging the PR or not
Will Abramson: Okay...
Manu Sporny: I think we should. Um, for your relative ref question, that is another issue that we can discuss...
… Um, just to be clear, I'd be a pretty strong minus one for getting rid of relative ref entirely. I… I
… don't like it as a feature. I remember we put it in there for a reason, but, like, if we get this path service or any variation of that done, that is the thing we should be telling people to do. I think the most we could do is put out a deprecation warning for relative ref
… To say that a future version of the spec might remove the feature entirely. Um, uh
… or just deprecate it forever and tell people, like, please don't use relative breath. It creates
… concerns and issues and that sort of thing. So, um, but that is a conversation we should have in the future
… as a separate, you know, issue, if we have the time. That's it
Will Abramson: Great, thanks, I appreciate that. Okay, I'm hearing… let's merge this, and I will let Dimitri know...
w3c/did-resolution#321
Will Abramson: What's that? Uh, so… Moving on
… This next one should also be relatively straightforward. It's 321. It's just a fix, really, to a bug that was in the spec around misnaming of the… Resolution, when it meant. dereferencing. Um
… I think it has strong approvals
… maybe we don't need to talk about it at all, I just wanted to make sure everyone had a chance. Yes. Marcus
… Hmm
Markus Sabadello: I think it's more than maybe just a bug. I think it has to do a little bit with the other discussions about what means resolution, what means dereferencing, what do you do with the DID and with the URL. And so on, so if… if everybody...
… actually agrees with this PR, it could also be helpful to get some alignment on the other. topic, so I would
… I would maybe ask if Joe and Steven could also review this, um
… And if they agree, then maybe some of the other discussions would be easier
Will Abramson: Okay, great, yeah, Stephen has approved it, so, uh… That's good. Manny?...
Manu Sporny: Uh, yeah, I've reviewed this PR, I think it's a good change. I think it does clarify...
… Uh… what, you know, a dereferencing cycle is, and why we care about those, and um
… Anyway, it feels like a good, a good change, um, that… that adds clarity. That's it
Will Abramson: Uh, 2?...
Joe Andrieu: Um, yeah, I think this is a good change in general. Um, there's some languaging I'd like to shift, so I'll take a look at that and give feedback. In particular, just the first line caught me...
… And that we don't dereference a DID service endpoint, we dereference a DID URL that has a service property, or that
… like, we need to figure out how to talk about that better, because if you give me a DID service endpoint, I don't need to
… they reference it. Um, I think the challenge is when you're going from the did URL, and then you trigger that loop
Will Abramson: Okay, great...
Joe Andrieu: But I will… I'll… I'll engage on that...
Will Abramson: Perfect. Thank you. Um...
w3c/did-resolution#327
Will Abramson: Okay, I think there's just one more that's maybe, like, an easy win, uh
… Uh, 327, there's another one from Marcus, and I think this is just a bug, right? It's the fix, like, we have old language
… In the spec that talks about input metadata, and
… these are no longer… this is no longer metadata, right? It should be options
… Uh, I guess, like, I know there are some other outstanding things that maybe change, whether there is the URL dereferencing options, but I still feel like it's. Valuable for us to just fix the… Back text, as is today. But
… Open to comments, questions
… That was
<JoeAndrieu> +1 for options instead of metadata
<manu> +1
Will Abramson: Okay, I see postpone from Joe. I'm not hearing anyone on the queue, so
… I don't mind just to move on, uh, and maybe we can… tackle a more
… challenging conversation now. Uh… If we have time
… Yeah, so, I mean, we've got half an hour. So, question to the group, we could
… continue the discussion on whether we want… what we're going to do about HTTPS binding
… Uh, for did your LD referencing from yesterday, or we could discuss, um
… this shift from resolving DIDs to DID URL
… I think both of these are, uh, you know, topics with strong opinions
… it'd be good to see which one. I mean, my, sort of
… Instinct is maybe to talk about the bid versus did URLs
… And then we can circle back to the HTTPS finding next week, but
… if people want to dive into HPS mining, also happy to do that
… Okay, I see Manny suggesting we close that HTTPS planning to do that
… So, okay, let me just
… Okay, great, yeah, so, um, let's talk about HTTPS binding, put that as a topic
HTTPS Binding for DID URL Dereferencing
<Wip> w3c/
Will Abramson: Uh, and
… really is captured in this issue that Joe raised. The change also has been made in a PR that Joe has raised, but I think this issue probably captures. The best place for the discussion
… Um, we discussed yesterday, and maybe, Marcus, it would be good for you to start this discussion
… sort of talking about, uh, why you're opposed to your LD referencing. I think you came with some good examples
… Yesterday, also some good points yesterday that we didn't get a chance to fully unpack, so
… Better place to start
Markus Sabadello: Um, but I...
… Oh, I, I
<markus_sabadello> w3c/
Markus Sabadello: Wrote one comment in one of the issues, uh, with… that I'll put in the chat now
… Which shows two… two real life, uh, examples of
… what the HTTPS binding for TDRLD referencing?
… is used for… one of them has to do with linked resources, and the other one has to do with
… redirecting to a service endpoint, I think
… So those are definitely things that have been implemented, that have been deployed, that are used in real-life use cases. And I think
… If we remove that binding, then those would become unspecified, and therefore not interoperable
… Between implementations. So these are two real examples that maybe some people were not aware of
… Right, so I think in the discussion about the dereferencing and the binding. Maybe we don't all have a
… Full picture of what that even means, right?
… It has nothing to do with the fragment, and nobody's questioning that the fragment should be dereferenced on the client side. Everybody agrees to that, but
… There are just some aspects, or
… that maybe not everybody is aware of, so I try to
… To share information about two concrete examples of. What this is used for
Will Abramson: Thanks...
<Zakim> manu, you wanted to note that just because something is deployed, doesn't mean we need to support it (especially if we think it's a bad idea)
Will Abramson: Yeah, thanks for that, Marcus. I see anyone on the queue?
Manu Sporny: Yeah, just a quick summary for, I guess, those that weren't there yesterday. I push back really hard on this feature. I think it is an anti-pattern. I think it can lead to security vulnerabilities and denial-of-service attack vectors...
… Um, I do not think we should support it. Um, that doesn't mean that implementers can't implement it, um, that's fine
… Um, but, uh, you know, just because people have implemented a feature and deployed it
… Uh, does not mean that we should… we need to endorse it in a specification
… For example, um, MDLs have been deployed in ways that are really bad for privacy
… Um, that does not mean that W3C specifications need to say that
… you know, those mechanisms are valid, or us defining it so that pattern becomes more entrenched, right? Certainly, this is not the same as the phone home issues that MTLs have had in production
… Um, but I'm trying to draw a parallel to, you know, if you implement this feature on your GID resolver
… Um, you have a lot more, uh, that you need to be aware of and guard against when it comes to exposing your APIs
… to any external system, meaning that there are all kinds of attacks that could be, you know, taken on your system if you have such an endpoint
… So, adding this would mean that, you know, at a minimum, we would have to go very detailed in the security consideration section about everything that you need to do around resource consumption and usage and redirection loops and. All that kind of stuff, versus not defining it
… Because one, I don't think it's a good feature, and two, um, you know, we avoid, you know, suggesting that it's a good feature
… Um, it feels like that is a better path, uh, to go, so
… Uh, again, very strong minus 1 on this feature. It is
… there are multiple security things that you need to be concerned about. I certainly don't want our company exposed to anyone claiming that it's in the spec, and therefore it's okay
… Because we strongly feel that it's not. Um, and so, you know, yes, other people have implemented it
… that's fine. Doesn't mean that we need to suggest that everybody, you know, should be implementing it, or that we need to do it for interoperability purposes. You don't want interoperability on bad features. Right? Um… That's it
Will Abramson: Great, thanks, Manu. And I think towards the end of last call, Manu, you mentioned, like, maybe there's a way to achieve some of the same...
… functionality or use cases that Marcus is mentioning without exposing this feature, and we should. We should explore that, and
… Make that possible. Yes, I'll see you on the queue, go for one
Manu Sporny: I think that's a different issue, right? So I think, you know, Marcus, from what you said yesterday, I got the impression that you thought some of us were making an argument against the dereferencing algorithm, or taking out completely, or something of that nature...
… I don't… I don't think anyone in the group has that position. I think the general position is we do think the dereferencing algorithm is
… a worthwhile thing to keep in the specification. Um, I think there's a question around the API definition of it
… Uh, and there's certainly questions around whether or not we believe the algorithm is, you know, the details of it, but I don't think anyone's saying we should take dereferencing out… the dereferencing out
… Uh, sorry, the dereferencing algorithm out completely. Um
… So, I would expect that if we remove the HTTPS binding, we would still keep
… The dereferencing algorithm, uh, detailed enough so that it could be implemented. Certainly on the client side
… Potentially on the server side, but we would not, you know, provide an interface. For the server side
… Um, which is the HTTPS binding for that. Hopefully that made sense
Will Abramson: Great, thanks. I'm Marcus?...
Markus Sabadello: Just to respond to that, I don't think I misunderstood that, so I understand nobody wants to remove the dereferencing algorithm, or at least I...
… I hope so, so that's, uh, that's clear to me. I understand this is about
… About the binding and not about the algorithm itself
Will Abramson: Yeah, looking for anybody else who has opinions about moving the, uh, fine, Jean? show...
Joe Andrieu: Um, yeah, I think… so I agree with Manu about all the security, uh, aspects...
… But I also wanted to add that if we have an HTTP binding for dereferencers, then now we're gonna have URLs
… that need to be dereferenced to talk to the dereferencer. And I think that's the heart of the confusion with Jeffrey. Like, there's
… like, how do we dereference a dereferencer becomes a more complicated pattern when we explicitly have an HTTP endpoint, which is going to be representable by a URL
… And so, I think that just gets really confusing
Will Abramson: Thanks, Joe...
… Anybody else in the group want to share their opinion about
… whether or not they support, or they support removing dereferencing, or HPS binding for dereferencing, or
… They want to keep it. They feel strongly that we should keep it
… Yeah, Apple, it's not a bad idea. I mean, I feel like
… kind of in the document, but I'm happy to take one. Marcus?
Markus Sabadello: I mean, I would like, you know, before we have a vote or a poll request or any of that, I would really like people to...
… consider the… the examples that I… that I gave
… And maybe also getting input from Checked or others who are
… Who have implemented the linked resources. I think there's
… One misunderstanding in the group may be that
… all of the dereferencing can always be done on the client side, and that it is all just about the document, right? So when we
… When we talk about things like the service parameter, when we talk about the path service proposal
… When we talk about the fragment, then all of those things are
… did method independence, they can be done after you have the DID document, they can be done in a method-independent way, they can all be done on the client side, you don't need an
… HTTP binding for dereferencing for these things, but there are
… did URLs, like the ones with linked resources, um
… Where you're basically doing something similar to
… to, uh… when you… when you obtain the deed document during resolution, right? You do it in a method
… specific way. The way how you resolve the DID document for a DID
… depends always on the… on the method, and sometimes the way how you dereference a DID URL also depends on… on the method. You cannot. Do that in a
… Client that doesn't understand the method itself, um
… And this would become unspecified or impossible if we remove the binding, so
… I would like this to be considered. I understand some people don't want to use these features, or. Don't want to… want to implement them, then
… This is also an optional feature, right? Nobody has to implement it
… But if we remove it, it would break things that are working today
<Zakim> manu, you wanted to speak to "all dereferencing can be done on client side, all about DID Document"
Will Abramson: Thanks, Marcus. Manu?...
Manu Sporny: Yeah, I wanted to kind of speak to, Marcus, what you said, that, you know, um… that we might be misunderstanding, um, that, you know, certain things need did method-specific features in order to dereference them. I'm pretty...
… I mean, please put yourself on the queue if you don't understand that, but I think all of us understand that. The idea that, you know, there are some ways of dereferencing that are did method agnostic
… And there are some ways of dereferencing that very much depend on the did method, meaning, like, there's data stored on a blockchain somewhere, and that is tied, you know, very closely to the DID method, spec, and
… you need to keep that in mind when you do the dereferencing, and it would be convenient to have something on a server that does all of that for you, right? Um, I think that is… Understood. Um, however
… one of… there… there… I think we… we have been saying there are
… ways to store these things in blockchains, and what we have seen is the did methods choose multiple different ways to do this, which has led to less interoperability, not more interoperability
… Now, there are good reasons to do it sometimes. I'm not saying you shouldn't have a blockchain-based storage mechanism and
… or a decentralized network-based storage mechanism. Um, uh, however
… you know, to say, Marcus, you said it's going to be impossible, you know, to do it. It's not going to be impossible. It is going to be unspecified, uh, right, uh, to do it, or underspecified. That is very different from impossible. You can still write a dereferencing client
… that understands, you know, special things about the AD method, and does the appropriate dereferencing algorithm that's did method specific to get the data. You could also have a dereferencing client
… that knows how to dereference something in a did-agnostic way, um, that is generalized among multiple did methods. Um, all of those things are possible
… Uh, we're not saying people can't do any of those things, we're just taking the HPS binding away, which you don't need for those other things. There's a separable
… Those are separable concerns, right? Um
… So, so, you know, again, I don't think anyone is confused about
… You know, those examples you showed show us
… you know, things that need special did method-specific logic to dereference the thing, like it exists in the blockchain or in, you know, some kind of verifiable data registry
… Uh, yes. However, you don't need
… an HPS binding to do those things, right? You can do them all client-side. That's it
<Zakim> JoeAndrieu, you wanted to ask about did linked resources being method-specific
Will Abramson: Great, thank you, man. Um, Joe?...
Joe Andrieu: Yeah, um, two things. One, the meta-comment is, I think...
… Um, it is often said in this community that something is did method specific about things that are not did method specific
… Um, and I think did linked resources isn't did method specific, so I'd love to be corrected, Marcus. I have not been driving or deeply involved in that work, but I have been tracking it from the beginning, because
… I wanted to understand how it interacted with the linked resources spec, um, because those properties are all in the metadata document that comes back from resolution
… So, um, I could put a deadlinked resource property. In any, um
… System that could respawn and put it into the resolution properties
… Um, so I'm not… I'm not following where we're losing functionality by. getting rid of the HTTPS here
Will Abramson: Great, thanks, Joe. Um, Marcus, if you want to respond to that first, good...
Markus Sabadello: Yeah, it is that method-specific, because, um, yes, it does use some metadata. properties that are...
… common and standardized across different deed methods
… But the way how you… how you obtain the content, how you actually dereference the thing, and the way how you get the representation of the
<ottomorac> This was the comments from Alext Tweeddale las time: w3c/
Markus Sabadello: resource that is referenced by the DTRL that is method-specific in the same way as obtaining the DID document for the DID. Is… is method specific, and
… And I would also
… I suggest to avoid maybe the concept of on-chain and off-chain
… Um… because there could be a
… a wide variety of approaches, how DTRLs can be dereferenced in a method-specific way, just like we've seen a lot of variety when it comes to
… how the document is… is a pain for the
… for the deed, right? We've been trying to avoid
… Categories like web-based and blockchain-based, because people keep coming up with new ways how
… how you can resolve a D28 document, and in the same way, I've been viewing URLs and
… Dereferencing also in the… in a similar
… Way, insofar as the methods can… Specify all kinds of ways how
… how you could get from a DDRL to
… Uh, to a representation of a resource that the URL dereferences, and did linked resources is, like, the first
… implementation, or the first design, which makes, uh, which makes use of DPRLs, and… Dereferencing, um
… and to implement that is… is method specific, right? So if you have a
… client, and you want to do all of that on the client side, then… then the client would have to know
… for every single method, how to do that, um
… And that's exactly why an HTTP binding is useful
Will Abramson: Thanks, Marcus...
… I put myself on the queue to suggest something that was maybe stupid, but I don't know. I wondered if these things are did method specific, like, couldn't
… that'd be, like, a HTTPS binding that's kind of
… wrapped in, or, like, part of the did method specific definition for how you get to that
… resource, like, maybe it's an optional thing. So, like, the DID resolution spec isn't going to define HTTPS binding generally for DID URLs
… But as you're dereferencing that div URL, you come to a did method-specific thing, like
… Then, if you understand that, like, they might tell you where to go and query to get the results
… I mean, it kind of feels like, I agree, did check, there's some interesting things, but if we… the only way that we're, like
… referencing those things is through HTTPS URLs, and not actual DID URLs
… it feels like we're defeating the point, right? People are just going to use these HTTPS URLs
<manu> Strong agree with what Will said.
<Zakim> JoeAndrieu, you wanted to say the resolver addresses that. not the dereferncer
Will Abramson: uh, like, what I would like to see is, like, a web page that can, you know, dereference a resource, like an image, that is linked to by a URL
… Uh, that's all good. Joe
… You're muted, Joe
Joe Andrieu: Yeah, thanks, Will. Um...
… Uh, with apologies, Marcus, I have to disagree pretty strongly that, um, did link resources is method-specific
… Um, any resolver for any method
… could support that property. The whole point of defining the property did link resources
… Is so that we can standardize this interface, that really any
… did method, any resolver could use, even for any did method. A resolver for did BTCR could choose to use did linked resources, it would be weird, but
… Someone could come up with that approach. It is the resolver who necessarily does whatever did method specific stuff it is
… So, to the extent that did linked resources was created by check, so that their DID method had a way to return a resource
… Doesn't mean that the property they created can only be used in checked
… bid methods. It could be used in any system that… any resolver that is capable of manipulating the metadata. can use Deadlink resources
… That's it
Will Abramson: Okay, thank you. Yeah, I see we're getting close to last 15 minutes, so, uh...
… Let's have a bit more chat on this, but I would like to get to a resolution at some point. Marcus?
Markus Sabadello: Maybe we're not on the same page on what method specific. means I...
… The properties are not method-specific, they can work with any method, but
… the dereferencing, how that works, that is method-specific for deed-linked resources, right? Just like it is for deeds and deed resolution, we standardize, uh
… the syntax of a date. We standardized the date document data model that's
… not method-specific, but the actual resolution process for get to the DID document that is method-specific, and it's the same for
<JoeAndrieu> We should move on. But I don't agree. Resolution is method specific. But dereferencing isn't. The property tells you everything you need. Nothing method-specific.
Markus Sabadello: the linked resources, and therefore, for the URLs, in a general sense, that some of the syntax and the data model and the properties are not method-specific, but the actual dereferencing process. Uh, is method, uh, is method specific. Um
… That's it. I also have a… I also wanted to reply to Will, but I don't know if there's time left
Will Abramson: No, no, you can reply to me, that's alright. I meant, like, I would like to have some time at the end to discuss next steps in terms of, like, next week's agendas, like, what do we want to focus on?...
… Uh, but yeah, for 3 months
Markus Sabadello: I mean, regarding your argument. will, um...
Will Abramson: Yep...
Markus Sabadello: So, binding is not a reference, right? You said something like you're worried that people would use, um, HTTP...
… URLs, then, as references for a resource, um
… That's not what anybody is saying, I think, right? The identifier, the reference, that is the TTRL, and
… A binding would not create a new reference or a new identifier, it would just be a
… a binding, and it's the same for resolution, right? We also have a HTTP binding for
<manu> It might be more fair to say that the interfaces are method agnostic, and some of the algorithms are method agnostic, and that's what we're trying to specify in DID Resolution (but that argument doesn't really get us anywhere on this issue, because that's not the point of contention).
Markus Sabadello: Did resolution, that doesn't mean that we're creating a new… that doesn't mean that we're creating HTTP URLs that become identifiers or references for the
… document. Um, so I feel like some… if you… some of the arguments that you made
… Uh, who are questioning the binding for the referencing would also
… could also apply to the binding for resolution, right? Why do we have an HTTP binding for resolution? Do we want to. Uh, drop that as well
Will Abramson: Bye. Thank you, Max. Manu?...
Manu Sporny: Um, I'd like us to run a poll. I want to see where everyone is, because, you know, it's kind of the same people talking over and over again. Um, one of my concerns here is that, um, this is, this is, you know, Marcus did very clearly ask the group for...
… uh, input on the HTTPS binding a very long time ago. Um, I'm asserting that people did not really pay attention and look, and because of that
… you know, uh, text got into the specification that, you know, I don't think has consensus. Um, I would like to at least poll the group
… Uh, on whether or not we have consensus for this feature, because again, it would be good to understand, like
… is it just, you know, Joe and me, and possibly Will disagreeing on this, or, you know, the rest of the group is very supportive of it, but they're just letting Marcus kind of
… carried the water on the counter argument. So, um, can we run a poll? We really need to… I mean, things in the specification need to have consensus
… do we even have that for this feature? I just want to get a temperature check from the group. That's it
Will Abramson: Yeah, I'm happy to run a poll, let's see how the queue, so we'll do auto, Marcus, and maybe you can prepare the poll text for us, Manny?...
… Uh
Manu Sporny: Um, well, let me… let me make sure. Marcus, if I… I want to make sure the poll's fair. Um...
… uh, if the text was what we would normally do in adding a feature, you know, that has some contention, um, to the specification, I think the poll would be something like
… Uh, poll, uh, add an HTTPS binding for
… uh, did, uh, what is it? Did, uh, resource
… Dereferencing? Is that
<ottomorac> transcriper-bot, pause
Manu Sporny: Uh, or did URL dereferencing, did URL dereferencing, would that be… An accurate summary of the… the spec
Will Abramson: Yeah, Marcus, which you're fine...
Markus Sabadello: Well, it would be… it would be accurate if we were now...
… discussing to add that, right? It's, as you said, it's been there for a really long time
… I did ask the group for feedback on that about more than almost 2 years ago
… I understand just because there's no feedback doesn't mean that there is consensus. I agree with you that. Probably nobody read it, but
… I… we should also consider not that this is something that's new now, that we're discussing whether we want to add it or not, but it
… It has been there for a long time. There have been multiple pull requests in the specification that we've discussed that have been approved
… Um, that kind of implied this feature, and uh… as a final comment, the
… Group now is not the same as the
… group back then. We… I think we need at least also some input from other people who have expressed support for this
… like the Cheqd people, um, like, maybe Phil Archer, I remember he was very involved
… Uh, back then, when it came to… to the HTTP binding
… So I… I don't know the W3C rules as well as you do, but I find it a bit
… Problematic now, too, so late in the process to
… To just remove something that has been there and has been supported, and
Will Abramson: Hmm. Thanks, Marcus...
… Yes, uh, I mean, it's not ideal. I think it's not ideal that we don't have people who were involved who have not been involved, but this group has, in general, suffered from lack of
… Engagement across the board, and that is the situation that we face ourselves in
… Uh, so I'm… I'm still happy to run this poll, Manu, I guess the text. I mean, let's hear from Otto
… to go on queue for a while, and moved Manu again. Noting the times, 10 to Auto
Otto Mora: Yeah, I would say, uh, plus one is run the poll. I mean, it makes sense. A point of just some research that I was doing here in the background, like...
… Did Cosmos does use the link resources back? I guess, not surprising, they are a Cosmos-based, uh
… Uh, did method, and then did Cosmos, and did check their twins, so not surprising there. But another point of interest is that
… Uh, the DitWebh apparently does use, uh
… the resource specification, uh, to provide some kind of cryptographic binding as well. Uh, so I… I am curious about that. I don't know
… I'm not that deep into it with, uh, did WebPH, but I don't know, Juan, if you are, but
… That did seem like an interesting tidbit there to just try to add here for, like, some context
… Because, yeah, it says that it provides cryptographically verifiable trust registries and status lists
… using the link resources, so that is an interesting bit, but, um, yeah, I see that one went on the queue, so I'll stop there
Will Abramson: Uh, okay, thanks, Otto. Yeah, I think also, just to note, I think the Cosmos uses the linked resources that Joe talks about, and the...
… Uh, check stuff using data linked resources, so it's obviously naming confusion going on there, I think
… Um, Marcus, I think you're not on the queue anymore, but if you are, do let us know
<Zakim> manu, you wanted to note silence is not consensus
Will Abramson: Take that, as I know, I think you spoke great. So, Manu, uh, and then one more question, then let's run the ball
Manu Sporny: Yeah, just to speak to what you said, Marcus, that, you know, you did ask, you know, you asked, um, uh, people did not come back and say no...
… Um, but, uh, silence is not consensus, right? Like, you cannot… you cannot base consensus based on silence, which is why W3C has the polling and proposal resolution mechanisms, because sometimes
… There are a lot of people that just don't say anything that do have a feeling one way or the other, and you need to get active engagement from them. Um, uh
… The other, you know, point about, like, yes, it's not good when you have the group shift, uh, and there were some people there in the beginning that are not here anymore
… And, you know, you have a different group, and they're making different decisions, and they're doing it, you know, towards the end of the group
… that happens, that is the way it works, right? I mean, if those people, you know, still wanted to be involved and cared about the work enough to, you know, show up on the calls and participate
… it would be a different, you know, thing, but that's not what we have, right? The reality of the situation is
… We have 14 people on the call today. That is way more than Quorum. Like, we have a good chunk of people
… Um, uh, uh, we are hearing people say, like, silence is not consensus
… Um, which it isn't, right? Like, hopefully everyone agrees to that… agrees on that. Um, uh, the… and so, like, let's just get a… I feel from the group, like
… Usually, you know, in contentious situations for a feature, you know, before it goes into a spec, we're like, is everyone okay with this feature going into the spec? Like, let's take that measurement now. And see where we are
Will Abramson: Great, thanks. Now, uh, Juan, you want to go, and then we'll run this port...
Bumblefudge: I was… I was just gonna say, in terms of the WebVH stuff...
… Um, I think it's a little new and a little experimental, the
… Adding a service to the… Um
… a VDR host, uh, that you run at the URL that hosts the web VHs for translating, and… and I wish Steven were here today, uh, because I know… I know he has been
… Uh, really interested in the pathing service as one way to do this. I don't think… Um
… I don't think it is a stable feature in the sense that I think it is still optional in WebH
… I think different implementations are doing it different ways, and it's mostly relevant to an optional layer above WebVH
… Because some of the deployments have, like, a… you know, like, a witnessing layer that runs separately
… Um, but just… just trying to answer to the fact that at none of the WebVH meetings I've been to, or the discussions I've been to
… Um… was this specific functionality
Otto Mora: thanks
Will Abramson: Okay, uh, so, apologies to Mark, because I am going to run this poll, I'm going to run it as...
… man who suggested, add an… add a HTTPS binding for… Good URL. Do you referencing?
<Wip> POLL: Add a HTTPS binding for DID URL dereferencing.
Will Abramson: Uh, so please share your opinions, and we'll take them into account and decide the next steps
<manu> -0.95
<JoeAndrieu> -1
<PDL-ASU> -1
<smccown> +1
<Wip> -1
<pchampin> +0
<markus_sabadello> +1
<ottomorac> +0
<TallTed> ±0 I don't grok the tradeoffs well enough
<KevinDean> +/-0
<ottomorac> transcriber-bot, pause
<bumblefudge> +/-0 tallted speaks my mind
<ottomorac> transcriber-bot, resume
Will Abramson: Okay, let's resume, and...
Otto Mora: Yep...
Will Abramson: So, pretty evenly split here. I… I would like to hear from you, Steve. If you don't mind sharing why you respond?...
… Because… I guess I'm trying to figure out how we move forward as a group at the moment. It feels like there is not consensus on this feature, so maybe it shouldn't be in, but… Um… anyway. Manning. Oh
Steve McCown: Yes, so, um… oh, sorry, I thought you were asking me...
Manu Sporny: Yeah, go ahead, Steve...
Will Abramson: Yeah, you guys do. No, no. Yeah, yeah, I was asking that, I went...
Steve McCown: Um, so generally, I think HTTPS should be used for everything...
… there's… there's been a big push for years to use it on the web. I think it has a lot of benefits. I think we should use it
… I'm a little hesitant, so I guess I'm not entirely a fold plus one. Um, I was… I was
… There's… there's other… there's other protocols, um, that can be
… that can be added for, you know, IoT and things like that, that
… may end up… MQTT, for example, that may end up getting considered at some point, depending on implementations
… Um, my personal home router starts with HTTP
… insecure to talk to it locally, but then allows me to turn on HTTPS, um, for very good reasons
… The alternative is a cloud-based resolver to access my local
… router, which I've gone to great lengths to keep turned off
… So, the way the question was written for the poll was simply
… should we… should we have an HTTPS binding? So I think the answer to that is yes. If there's
… Other collateral issues that result from that, I think we should talk about
… those individually, but just on principle, I think HTTPS. Should be there
Will Abramson: Okay, thank you. I'm noting we're basically at time. Manu, do you want to have a quick chat?...
Manu Sporny: Yeah, Steve, unfortunately, that was not what we were polling. We are going to have an HTTPS binding, but one for resolution and not dereferencing. We're trying to make a decision between two endpoints or one...
… the poll was about having… we will have an HTTPS binding for resolution, certainly. That, I think, has consensus. It's the dereferencing question that we were… we were asking. So I don't know if your plus one is
… Answering the actual thing we were polling for. I will note that this is not… the poll results. are very clear, um
… there is no… there's no support for it. It's not… it's not… it's not… it's split one way or the other. You have a lot of people that… or you have a number of people that didn't have an opinion. You have multiple people that are minus one or close to minus one
<TallTed> I will note that, quorum or nut, decisions (weightier than polls) made here are provisional, pending a (typical) week allowance for absent people to object
<TallTed> I will also notes that HTTPS only encrypts data in transit between end points, thwarting eavesdroppers. It's a lot less security than most people think.
Manu Sporny: And you've got, you know, 2 plus ones where one of them, Steve, I'm asserting yours is not… I don't think you were answering the poll that we were polling, and then Marcus, of course, right?
… if we got this, when we were considering merging a PR or not, we would not merge that PR
… So I, you know, Will, with all due respect, the chair call on this
Will Abramson: Mm-hmm...
Manu Sporny: has to be… we do not have consensus. I mean, we can keep talking about it until we have consensus, but that is a very clear, we do not have consensus on this. It should not be in the spec. I don't think it's appropriate to say, well, we could go either way. No, absolutely not. There's no consensus on this. That's what we just saw in
the poll...
Will Abramson: Yep. Okay, thanks. I see we're at time, past time, uh...
<smccown> Since it sounds like I was answering a different question, I'm happy moving to a +0
<ottomorac> transcriber-bot, pause
Will Abramson: I appreciate this discussion. I'll talk with Otto next week, but I think I agree it's very clear, not consensus on this feature, so