Meeting minutes
ottomorac: Next week is TPAC, there will be no meeting. Some sessions taking place. Two following meetings after that there will be no meeting. First is post TPAC, second is US Thanksgiving.
Review PR for #213: Make conformance statements concretely testable
<ottomorac> w3c/
<ottomorac> Will has proposed some wording around the conformance classes and there is initially some feedback from Markus.
wip: We have talked about this a number of times. I want to know what people think but I want to get this in as it's blocking a number of open PRs that depend on its language.
… You can be a conforming resolver just by being a library, don't need HTTP.
… There are conformance classes that we need to reference in the document that other PRs depend on.
JoeAndrieu: I think Markus is wrong on this. We don't have confirming DIDCOMM-based resolvers that don't have HTTPS binding. My understanding of the distinction is "Are we crossing a device boundary?"
… I thought that's what we're trying to highlight in the security of the two systems.
wip: I think that's what we're trying to highlight. Right now, only HTTPS crosses the device boundary. Do we want to limit it to that?
JoeAndrieu: I think we are not specifying that future thing. If a future working group with a different charter wants to add different features, that's up to them. If we want the network architecture to be interoperable, then we need extensions, and we lose interoperability.
ottomarc: A DIDCOMM resolver may do Bluetooth, HTTPS, etc.
JoeAndrieu: If it does HTTPS, then it's conformant, and that's the minimum.
wip: I don't care what we call it, I want to get that in. I'll change it back to "network" and ask that JoeAndrieu add a comment.
DID Resolution PR Processing
Clean up old issue flags #242
<ottomorac> w3c/
<ottomorac> The PR addresses part of the issues on #220, but Will also wanted to know about 3 other issues in red in the Authentication / Authorization section, and wheter we should track them in a separate issue.
<Wip> https://
wip: Yes, we talked about this extensively last week. I don't know that it needs more discussion, unless people have something to say about the three issue flags in Authentication.
… One is still open and needs action, the other two don't have an issue marked against them and I would like to remove them.
w3c/did-resolution#201
<ottomorac> This PR addresses #200, and #201 raised by Addison Phillips, regarding UTF8. It has some relationship to the DID path URL dereferencing, but wondering if we can have it merged before then?
<Wip> w3c/
wip: I don't have anything about this, but I thought it was issue 217.
ottomorac: I referenced the PRs, not the issue.
<ottomorac> w3c/
<ottomorac> w3c/
w3c/did-resolution#206
wip: Obviously, Markus isn't here, and he's technically the editor, but we've stagnated a little bit in the last month or so. It would be nice to have others get involved in the PRs and get them merged.
… PR 206 hasn't had any review, and it has just sat there, so if people could take a look at it we could get it in.
DID URL Dereferencing PR
<ottomorac> w3c/
ottomorac: There has been a lot of back and forth on this one, and we had to cancel a special topic call on it because of conflicts.
… Markus has expressed some feedback there.
wip: The only thing I want to flag is to JoeAndrieu, we might discuss this informally at TPAC, but Markus and Stephen won't be there, though they may be remote. When we get back we'll schedule a dedicated time to deal with it.
… I know, Joe, you have opinions, and it would be create to get them out there. Manu doesn't think we should close this and move on. He thinks we should work as a group to come together and move this forward.
JoeAndrieu: I'm not up to speed, and it looks like there has been a lot of activity in the last couple of weeks. My understanding is that Stephen was going to take things forward, but I haven't had time to see how people have responded. We should take some time at TPAC.
wip: At TPAC, I want to spend time on the more general issues. The agenda is pretty flexible at the moment, so we can make time for it.
… I expect it to be a dedicated session in November.
ottomorac: It would be evening time in America if we overlap with TPAC for part of the discussion to happen virtually.
wip: I don't think we'll have formal session for this. There are other things we need to make time for.
JoeAndrieu: If we as a working group want to take some of that meeting in Kobe at a time that's most convenient for virtual attendance, first thing Tuesday morning would be Monday 5pm Pacific.
DID Resolution Issue Processing
ottomorac: Quite a few issues out there.
w3c/did-resolution#227
ottomorac: I believe you opened this one, Will.
<Wip> https://
wip: The note is in this introduction section, and Geoffrey is saying that it is confusing.
<Wip> The note references this issue - w3c/
wip: My sense is that we should just remove it. It's old and stale and I don't know that it's adding anything.
ottomorac: Anybody have any strong opinions on removing it?
JoeAndrieu: I support removing it. It has been thoroughly discussed, and I don't think it's relevant anymore.
wip: These issues are all tagged "feedback". At the moment I'm trying to go through all tagged issues, label them "ready for PR", and find people to address them.
w3c/did-resolution#228
<Wip> https://
wip: Our example says resolve, but the thing we're resolving is a DID URL, so either it should be "dereferencing" or we should change the example. Do people agree? As soon as you add a query parameter it becomes a URL, so the correct term should be "dereferencing".
JoeAndrieu: Where is the URL?
wip: In section 1.1, second paragraph down, ignoring "This section is non-normative".
JoeAndrieu: I think it's more nuanced that we've discussed so far. The DID URL is modifying your resolution because it has a query parameter "versionTime". It would be incorrect to resolve this without using the version time.
… This section is non-normative, so that helps with our options. Resolving the DID may require understanding if there is a DID parameter.
… I think this paragraph is not about resolution. The "For example" is about dereferencing.
Ivan: I'm also pretty much mixed up. We had two normative sections on DID resolution and DID URL dereferencing. We use different terms if we do something with a DID vs. a DID URL. This example here is a DID URL, not a DID.
JoeAndrieu: The challenge is that the version time as a query parameter is going to change how you resolve that DID, so you can't fully separate it.
Ivan: We need to understand this is a URL, but it modifies the resolution, so it's part of the resolution.
… We shouldn't have this example in this section. If we are going to talk about URLs, we should put it in a paragraph at the end of the section.
<Wip> Obtain the DID document for the input DID by executing the DID resolution algorithm as defined in 4. DID Resolution. All dereferencing options and all DID parameters of the input DID URL MUST be passed as resolution options to the DID Resolution algorithm.
<Wip> https://
wip: I think, Joe, this is a section in the DID URL dereferencing algorithm, which takes the parameter and passes it to the resolve operation.
… You're going to parse the URL and pass them into the resolution algorithm.
… I agree with Ivan. We change the example to use something simpler.
<Zakim> JoeAndrieu, you wanted to say I think we need to redefine resolution to take a DID URL
JoeAndrieu: Simple, but I'm not sure it's right. I think the mistake is that we say that DID resolution starts with a DID, rather than a DID URL, which may affect which document is returned.
<KevinDean> +1 to JoeAndrieu
JoeAndrieu: We may need to pass query parameters through to the resolution process. We have a handful of parameters. Some may affect resolution, some may affect dereferencing.
Ivan: Is this defined somewhere? This is not defined in the DID resolution document.
… I understand the intention, but I'm wondering if the specifications are clear in this respect.
JoeAndrieu: They're not clear, because we say that DID resolution starts with a DID, not a DID URL. Anyone at any time can add another parameter that changes resolution even more.
wip: I always thought we resolve DIDs and dereference DID URLs.
… I thought we handled that by stating that we pass the parameters through to the resolution as resolution options along with the DID.
JoeAndrieu: The problem is that the language is what we've been using, but we cannot resolve the DID without the full DID URL. The DID resolution process can't happen without the parameters in the DID URL.
… I agree in some moment before we do resolution that we have to parse the DID URL.
… I don't think we've properly discussed this preprocessing step that has to take place before resolution.
Ivan: What bothers me is that this is so different from the way that HTTP URLs are handled that we're bound to create confusion for the community.
… I see this as, "If I take an HTTP URL, whatever is in a query parameter, will influence how I handle the host name."
JoeAndrieu: I think you're right, but I don't know how we get out of it.
… We wanted parameters that affect resolution and parameters that affect dereferencing.
wip: I think this is great, but I suggest we move on, and discuss at TPAC.
<ivan> for the record, from the did spec: "Identifies a certain version timestamp of a DID document to be resolved. That is, the DID document that was valid for a DID at a certain time."
w3c/did-resolution#229
ottomorac: This is related to hash link.
<Wip> https://
wip: We reference hash link for the hl query parameter, but it's not part of the spec, so I don't think we can reference it.
Ivan: In 3.2.1 of DID Core, it explicitly says that DID parameter is non-normative. I think that it refers to the fact that hash link is a moving target.
wip: I think maybe that didn't get copied across.
<ivan> see https://
wip: We moved it to DID Resolution, it shouldn't exist in DID Core.
JoeAndrieu: One of the problems of this section is that one part says it's non-normative, but include normative language.
… I think the response to Jeffrey is that it's a non-normative section and should be rewritten.
wip: I'll do that.
w3c/did-resolution#230
<ottomorac> https://
<Wip> https://
wip: I think this is a good point. I don't know what we can do about it. In the 4.4 DID resolution algorithm step 3, we execute the read operation, and it's not clear what it means; it's under-defined.
JoeAndrieu: I agree, it shouldn't be "read".
… The "read" language is in quotes because we previously used the CRUD style. The advantage of that reference doesn't help anymore, and I think it's just a resolve operation.
<Wip> https://
wip: It points to the DID Core specification. I wonder if we should make it more concrete by passing in the DID, the method, and the resolution options.
JoeAndrieu: I think we need to define a resolver that's going to resolve. We tried to separate this out because we had concerns about the protocol boundary in our charter.
… We're standardizing the front end, not the back end. That's the point.
wip: I think I agree the "read" operation should be "resolve". We should respond to Jeffrey to say that we'
… we're not trying to standardize this.