Meeting minutes
Agenda Review, Introductions (5 min)
<ivan> present
Otto Mora: Yes, so today we… we're just, um… we have a few updates, uh...
Otto Mora: mainly, uh, regarding some issues that we reclassified, uh, b/Aecause we're running out of time, so we want to make sure that we get, um, those issues, uh, either labeled as during CR or future...
Otto Mora: And then we also have an update on the DID URL dereferencing. There's a PR that Joe created on this, so we're trying to get to the bottom of that as well...
Otto Mora: And then, uh, we have a, um...
<TallTed> just gotta get that updated zoom link into the calendar!
Otto Mora: an update on the DID resolution threat modeling, and then just a continuation of the discussion on the DID...
Otto Mora: Path PR, so that's essentially what we have. Did I miss anybody? Any other points that people want to raise, or any other issues?...
<pchampin> s/DIT resolution/DID resolution
Otto Mora: Okay, not hearing any, so… let's move to the next one...
Otto Mora: Uh, okay, so on this first, uh, issue, I think, um...
Otto Mora: Sorry, before we get into that, I think, Pierre, we wanted to mention that we really want to get into CR, so...
Otto Mora: Uh, we want to make some difficult decisions, I guess, at this point. Um...
Otto Mora: So that we can try to meet the deadline, uh, before the...
Otto Mora: the need for an extension is there, right, Pierre? Maybe you want to talk about that?...
Pierre-Antoine Champin: Yeah, we… we… so, we do have one month left, I think, on the… on the charter, so I will start, uh… Very soon, to request for an extension...
Pierre-Antoine Champin: Uh, and yeah, I guess the, the, the, the, the question will be, uh, how far we think we are, uh, how, how… How long do we need the extension?...
Pierre-Antoine Champin: And so, yeah, at some point, we will need to show progress, so we have did core in candidate recommendation...
Pierre-Antoine Champin: Uh, but did resolution still need to get there? So, yes, now is the time to...
Pierre-Antoine Champin: As Otto put it, make tough decisions, because that's what… that's also what standardization is about. Uh, so that we...
Pierre-Antoine Champin: So that we can be credible when we are requesting the extension, that we can actually get this through...
Otto Mora: Okay, perfect...
Otto Mora: Uh, yes, go ahead, Ivan...
<pchampin> agreed, depending on how long we think we need, we will have to work on a new charter in parallel
Ivan Herman: So, my… as far as I know, these days...
Ivan Herman: More than 6 months extension just like that, is pretty much difficult to get...
Ivan Herman: After that, they would ask us to...
Ivan Herman: on re-chartering, even if it is the same charter, but to have an AC approval for continuing, even with the same charter, so...
Ivan Herman: 6 months is probably the maximum that we can count on...
Otto Mora: Mm-hmm...
Otto Mora: Okay, well… yeah, okay, well, that's a… that's a fair point. So you think it, like, it would have to be, like, a shorter extension, Ivan, if any at all, like, it would have to be, like, 3 or 4 months at most?...
Ivan Herman: You can try with 6, though you might get 4...
Ivan Herman: But you might get...
Ivan Herman: The 6 months...
Otto Mora: And, alright, so let's move to the next topic...
Otto Mora: Oh, yeah. Go ahead...
Will Abramson: I just had a minor thing, um… thanks...
<JoeAndrieu> +1 to continue the experiment
swcurran: if Joe's PR is merged, all the other PRs will be broken, that is going to take time
DIDWG Status Update \[1\] (5 min)
Otto Mora: Okay, uh, alright, so next item...
<ottomorac> https://
Otto Mora: Um, we have, uh, labeled a bunch of them as either, uh, during CR or future. And, uh, that's just in the spirit of making some progress...
Otto Mora: I don't know, Will, is there anything we want to mention here about this?...
Will Abramson: I think the only thing I would say… sorry, I thought we'd already discussed this, but I guess you're right, we hadn't. The only thing I would say is, like...
Will Abramson: we might advise us to do this, and I think it is a good approach. Basically, anything that isn't adding normative changes to the text can be labeled during CR...
Will Abramson: So if there are issues that we have labeled during CR that you strongly disagree with...
Will Abramson: then do comment on those issues, but bear in mind that we need time to get those issues in. So, one of the things is, if it's not during CR and you think it's normative. Maybe it has to be future?...
Will Abramson: Um, so that's the only flag, you know, there are some new labels on the issue. If you strongly disagree, do voice your disagreement. Okay...
Otto Mora: Mm-hmm. Okay...
Otto Mora: One is raising any issues with that one, so maybe let's move on to...
Otto Mora: the DID URL dereferencing, which is the next one...
DID URL Dereferencing \[2\] (10 min)
<ottomorac> w3c/
<ottomorac> w3c/
Otto Mora: is this particular one, and then I saw that… yeah, Joe, yeah, thank you, you opened a PR for this, which the link is here...
Otto Mora: And I guess maybe I'll let Joe just present it, and then I think we can go into some detailed discussion around it. Uh, perhaps...
Otto Mora: I do see responding. Go ahead, yeah...
Joe Andrieu: Thanks, Otto. Um, so, uh, as I actually say in the PR, I apologize for the size...
Joe Andrieu: Um, this is a little bit like pulling on a thread on a sweater, uh, that included, you know, Jeffrey's request to clarify resolution versus dereferencing. Um, the path work, which included how do we handle properties that conflict...
Joe Andrieu: Um, and in that work, it became clear it was really hard, even for both Steven and I, to figure out how do we adjust just the dereferencing part...
Joe Andrieu: But not the resolution part, because of how the algorithm was described. And as I started working on that, I failed to give Stephen a good revision. I could only get halfway through it...
Joe Andrieu: And so then, when I turned back to Jeffrey's question and looked at the document as a whole...
Joe Andrieu: I think the thing that most clearly came into, um, high contrast for me was that I think I've always thought about resolution and the dereferencer as a client-server relationship...
Joe Andrieu: And, um, in our process, we ended up treating the dereferencer as if it were a server. So we added HTTP endpoints to it, for example, where...
Joe Andrieu: there really… that isn't a standard thing for most URL dereferencers. Like, a dereferencer generally is a browser of some kind...
Joe Andrieu: Um, and browsers don't generally have an HTTP endpoint, they are HTTP consumers...
Joe Andrieu: Um, so, as I wrote up an algorithm that, uh...
Joe Andrieu: made sense to me, which I had gotten some confirmation on, echoing sort of what I had written up for the did resolution threat model...
Joe Andrieu: And that seemed to be right, like, at least the feedback I got was like, yeah, Joe, that you're describing the right process, and so. I rewrote that...
Joe Andrieu: Um, in a way that hopefully is clearer. Um, that was my primary goal, was to just deal with, you know, inconsistencies or clarity issues...
Joe Andrieu: Um, and one of the things I discovered in there is, um, we don't currently have a normative requirement...
Joe Andrieu: that a dereferencer must allow a user to configure the resolvers. I think we should have that, as a matter of fact. Um, it was just something that was left out. I think that's a fairly minor point. The bigger issue is...
Joe Andrieu: I think, do we treat the dereferencer as a server?...
Joe Andrieu: Um, or is this insight about dereferencing is basically done by clients? You know, how does the rest of the group feel about that? And we can talk about the consequences. It is a huge. change. I don't… I didn't… I couldn't find a...
Joe Andrieu: short way to deal with it. Um, like, I think Steven and I, as we try to work on his PR, you know, we're looking for simpler options, but...
Joe Andrieu: Um, I think this was the most coherent way I could respond, and if we want to cherry-pick aspects of this, we could. We could keep the description of the algorithm. Um, in my PR, but also keep the, um, idea of an HTTP dereferencer...
Joe Andrieu: you know, with endpoints. So there are options here. I just wanted to get my, uh, thinking and ideas in a proposal and spec text. So that we could consider it as a group...
Otto Mora: Okay. So, first up is Marcus...
Markus Sabadello: Hey, Joe, thanks for the PR. I haven't had a… I haven't had the time to really look at it yet, but I'm curious why you think that in the...
Markus Sabadello: current specification, there's an assumption that the reference is a server. I'm very surprised to...
Markus Sabadello: to hear that, I think we've always had two functions resolve and dereference, and we've always said that those are...
Markus Sabadello: Abstract functions and the algorithm sections in the current specifications, I think, don't imply any kind of...
Markus Sabadello: client-server relationship. It's true that then there is a separate section with an HTTPS...
Markus Sabadello: binding for Resolve and for dereference, but that's completely...
Markus Sabadello: separate from the… from the definition of the resolve function and… and from… from the algorithm, so I don't think...
Markus Sabadello: Does anything in the current specification that implies or requires a dereferencing...
Markus Sabadello: server, and I think there are also some diagrams which, uh, which make that clear that...
Markus Sabadello: Uh, that the referencing after the resolution step can… can and should happen on the client side...
<Zakim> Wip, you wanted to ask about formatting
Otto Mora: Okay. Uh, Will...
Will Abramson: Yeah, thanks. I just wanted to bring up a...
Will Abramson: of that thing, an issue, which is very hard to review this PR because of the formatting issues. Like, I don't know. If you know...
Will Abramson: I don't know what the best solution is here, but, um, I think Steven mentioned it, and then I was having a look too, and it...
Will Abramson: you know, there's just a lot of green, and I think it's not clear which bits of that are, because you've changed things versus just line formatting. Issues and edits...
Will Abramson: I did suggest maybe we do a separate PR that just does a formatting pass...
Will Abramson: I don't know… I don't know how easy it would be for you to, like, revert the formatting on here, for example, all those...
<Zakim> JoeAndrieu, you wanted to say that if you expose an endpoint, you're acting as a server.
Otto Mora: Mm-hmm. Yep, go ahead, John...
Joe Andrieu: Um, I'm not sure what formatting you're referring to, Will. Do you mean in GitHub, how it presents the diffs?...
Will Abramson: Yep...
Joe Andrieu: Like, I think the way to read this is to clone it and read it. Like, I think that the diffs is going to be a very difficult way to get through it...
Joe Andrieu: Um, it's pretty much a rewrite of the whole thing...
Joe Andrieu: I mean, there are sections that are untouched, but...
Will Abramson: Okay...
Joe Andrieu: Um, I wouldn't expect the GitHub UI to be particularly helpful...
Joe Andrieu: Although, I do see you made a bunch of suggestions that should help our terminology links. So...
Will Abramson: Yeah, well, I think that's amazing, you know, like, when I'm making suggest… yeah, I see what you mean. Most of this are just changes, but for example, like, at the top of the index.HTML file...
Will Abramson: There's a bunch of green on the, like, config, and that's definitely just some formatting changes that have been applied...
Will Abramson: that make it kind of confusing, like, I don't think I need to review the, like...
Will Abramson: Script tag contents of the index.HTML...
Will Abramson: But, like, GitHub is indicating that there are changes, so maybe I should be reviewing. for example...
Joe Andrieu: Okay...
Otto Mora: It's it. This stuff here, right? Like, the...
Will Abramson: Yeah, I can't see your screen...
Will Abramson: I take your point, it's a big major rewrite, and maybe you should just be reading it top to bottom...
Will Abramson: Uh...
Will Abramson: I guess I could keep going. I do have, like, a more substantial comment about the content. Um...
Will Abramson: Okay. Yeah, go ahead...
Joe Andrieu: I had a quick comment, just to respond to Marcus's question, if you don't mind. Uh, I was waiting to get on the queue to see where new voices might show up...
Joe Andrieu: Uh, the reason, uh, it feels like a server is because there are endpoints...
Joe Andrieu: Like, for the browser, browsers don't expose endpoints for dereferencing, they just do dereferencing...
Joe Andrieu: Um, so… that's… that's what felt like, why… why do we have this separate piece of software?...
Joe Andrieu: Um, and what we… we do have in the spec, something that's underspecified, something called a client...
I think of the resolvers as a kind of "proxy" or "bridge" in terms of standard Web architecture
swcurran: the diff is unusable, this is goint to take a long time to review
… the server language is correct; browsers only do the fragment thing, the rest is done on the server side
<markus_sabadello> https://
<Zakim> JoeAndrieu, you wanted to say browsers fundamental exercise is to dereference URLs
swcurran: it is a logical requirement, not an impl requirement
JoeAndrieu: you took my comment to be about that particular dereferencer
… I discovered that Chrome can be used on the command line, like curl
… but it does not offer an API that any other app can use
… Jeffrey Yaskin's confusion comes from us defining a new pattern
swcurran: are you considering that the processing and display of the content as part of the dereferncing?
… that's not how I see it
markus_sabadello: repeating myself: nothing in the spec constrains the resolver to be a server
… it is a component used by other components, possibly via an HTTP binding
… I posted examples in the github issue
TallTed: I'm surprised to hear programmers talking about "dereferencing" in a way that is different from its meaning in programming
… values are stored in memory, and referenced by their address in memory; dereferencing is getting the value from the address
… that's how I see dereferencing on the web
… sometimes to dereference a URL, you need to resolve it (e.g. make it absolute)
… hopefully, that's helpful to think about DID dereferencing and DID resolution
dmitriz: +1 to swcurran and TallTed, processing and displaying is not dereferencing
<Zakim> JoeAndrieu, you wanted to say the spec specifically says it MUST implement a particular interface
JoeAndrieu: I'm not sure what dmitriz says. dereferencing happens between a client and a server
… in this interaction, the fragment *has* to be handled by the client
… when I write a dereferencer, I don't want to expose an API
… what we are proposing here is not the way the web works
… we are defining classes of conformant software
swcurran: I agree that fragments are handled by the client
… I believe that a client passes a URL to a component, whether that component is local or remore, we don't say
… that component responds to the client with something, and the client goes from there
… a piece of software could call a local component, that's a library, not a server
markus_sabadello: Joe, maybe you can point to the place in the spec that states that you must expose an endpoint
<ottomorac> pchampin
<JoeAndrieu> https://
<JoeAndrieu> All conforming DID URL dereferencers implement the function below, which has the following abstract form:
<JoeAndrieu> dereference(didUrl, dereferenceOptions) →
<JoeAndrieu> « dereferencingMetadata, contentStream, contentMetadata »
pchampin: yes plus one to what Stephen said...
Wip: we spent a large part of this meeting discussing this
… maybe we need a special topic call on this
<bumblefudge> +1
Wip: regarding the timeline, I agree with swcurran that this PR will cause a lot of delay on other PRs
swcurran: we need to think about the concepts that Joe's PR introduces, then try to make it fit more into the existing spec
… the current PR mixes formatting and content change
… I'm not agreeing with some thing that Joe said, but I tend to agree that we may need to change the language,
… from describing as an HTTP interface, to describing as a message exchange interface
<JoeAndrieu> I don't agree there are five things that come back. ANY resource could come back.
<Wip> w3c/
Wip: this PR stems from the issue raised by Jeffrey, who's confuse with what's currently in the spec
… we need some changes to address Jeffrey's point
<Zakim> JoeAndrieu, you wanted to say give this a week.
JoeAndrieu: I think we should give this a week, let people comment on the PR and see where they are
… while the rest of the WG looks at this, I'll focus on the threat modeling, which is the other bottleneck
Wip: we should put a special topic call in the calendar
… on the 8?
<JoeAndrieu> +1 to saving that time slot
<bumblefudge> waait there's 7 other PRs and you have 4 meetings left?
<bumblefudge> i'd rather get through the other 7 in next two meetings and topic calls for jeffrey's Issue
DID Resolution Threat Modelling Update
JoeAndrieu: quick update: we were hosted by the TM CG this week
… sorry for the short notice
… this is the first time we did that in the CG, learning as we go, but I think it went very well
<Wip> Jeffreys issue is the only blocker for moving into CR bumblefudge. 6 of those 7 PRs are ready to merge I believe
JoeAndrieu: it was a joint combination of teaching what TM is, and showing how DID resolution works
… we started a threat ellicitation process
… some that came up were more VC threats or DID-core threats, but that's part of the process
… I'm going to add some of these threats in our repo and get a first draft
Wip: what changes do we expect in the spec text when the Threat Model is out?
JoeAndrieu: we are probably going to publish the Threat Model as a standalone note,
… then update the security consideration section to highlight the key threats, and point to that note
<Zakim> swcurran, you wanted to talk about the DID URL Path Handling PR after this topic
<JoeAndrieu> +1 to non-blocking!
pchampin: +1 to what JoeAndrieu described; note that the Security Consideration sections are non-normative, so this can happen during CR
w3c/did-resolution#260
swcurran: I made updates to the algorithm, which I think address the concerns that were expressed
… manu wanted to raise that there is only one implementation, so that should be at risk
… there has long been a use-case where a resource is available at multiple places, and you want to leave a client to decide what they want to do with that resource
… controversial point: resolver returning a modified document; that may be removed during CR, I added an issue note
… I need to address conflicts in the PR
<TallTed> "What are all the filepaths (hardlinks) that reach the same inode (physical bits on the disk)?"
swcurran: I really think this PR is ready