Meeting minutes
Agenda Review, Introductions (5 min)
ottomorac: <we'll do some issue review, PR review>
… anything else to add?
ottomorac: before we do that, our charter ends in April
… and we can try to ask for an extension
… we can try to finish as much as we can before we do, for best effect
… I know that we also wanted to remind folks that we have a Security Interest Group call on the 3rd
wip: yeah, it'll be great if people show up
… we can get a sense of where the security review is at
<Wip> w3c/
ottomorac: yeah, we can liaise with them, see about the threat modeling, etc
Process Update (5 min)
Wip: previously, we've been marking issues as Pending Close, and then sending Pending Close reminders in email
… then Manu pointed out that we're in a bit of a rush, and don't have time for this extended timeline
… so we'll switch to -- once a PR is merged for an issue, we'll just close the issue addressed
… if you have any concerns, please voice them
… otherwise that'll be the policy going forward
manu: +1 to that, I would certainly prefer that process. remember also that if somebody disagrees with the way an issue was addressed, they can reopen it (or ask it reopened)
Use unicode names for special characters (7 min)
<ottomorac> w3c/
ottomorac: this issue, using Unicode names for special characters, pr 918
<ottomorac> This change replicates unicode changesfrom this PR w3c/
ottomorac: reviews appreciated
wip: this is exactly the same change we already made in Did Resolution, right
ottomorac: right
Make https binding mandatory for network-based did resolvers #272 (7 min)
<ottomorac> w3c/
ottomorac: now that we have conformance classes defined, we can establish two things
… one is - conforming resolvers must implement GET, and may implement post, and two, must use TLS
wip: this is great, yeah
<Zakim> JoeAndrieu, you wanted to ask about QUIC and TLS
JoeAndrieu: I like the intention. question about TLS -- maybe that's not specific enough. should we specify a specific version? what about the evolution of HTTP, how can we forward-proof the statement?
TallTed: I think there's a similar issue somewhere.. <something about recursive complex datatypes>
manu: the language pointed to 'all conforming network-based did resolvers', but the text just said 'conforming did resolvers'
… I took out the mention of TLS -- it's presumed by using 'https'
… and that'll future-proof it. (the HTTPS spec has a bunch of text to that effect)
… in the final statement, you mention use of DNS is not required, etc -- that is the same statement, restated
… we can just say 'Resolvers may use TLS certs issued for IP addresses'
<Zakim> JoeAndrieu, you wanted to be said about the implication for DNS
JoeAndrieu: small nuance -- the statement that they MAY use TLS certs for IP address, might be read by some that they're not supposed to use TLS certs for DNS addresses
<ottomorac> All conforming network-based DID resolvers MUST implement the GET version of the and MAY implement the POST version.
JoeAndrieu: so maybe we don't want to imply the inverse
ottomorac: ok, I'll accept manu's change suggestion, minus the IP TLS cert part
Wip: I see what you're saying, Ted.
… I'm not sure what the best way to handle is, maybe as a separate PR?
TallTed: I think the cleanest way to do that is just to re-enumerate that list
Reminder about Ready for PR issues (10 min)
<ottomorac> https://
Wip: this is just a reminder that some of these issues have been assigned to folks for some time
… we need to resolve em as soon as we can
Wip: the critical path is the tag 'needs resolution'
… we've got about 27 issues left?
DID Path Discussion (15 min)
<ottomorac> w3c/
swcurran: I tried to align it to the rest of the spec's construction
… I've updated the PR to match the format of what is returned; now returns a list of URLs which matches what happens when service or serviceType query params are used
… I also added returns for error conditions, including defining an error condition and including it in section 10
… so, looking for feedback
… the way we structured it now -- all of the query parameters are DID URL Dereferencing query params that are defined
… there's a line in there that I put about 'ignore params that are not recognized', and that raised a question in general
… looking at HTTP, it says, re query params, you COULD throw an error if you want, but most just ignore them
… so that's thing one I'd like feedback on
TallTed: it feels like a potential security issue, to silently ignore things. maybe we can return an advisory, if not an error?
… just to say 'we ignored this'
swcurran: what would be the form of that?
TallTed: instead of 'error', we can say 'advisory' or 'warning', and say 'Ignored parameter XYZ'
manu: in the VCALM spec, we have the ability to return warnings and errors as problem detail objectrs
… I'm not sure we want to add this concept to DID Resolution at this late stage,
… I also have the same gut reaction as Ted is having, about silently ignoring query params. What if it's a really important extension, etc
… so one thing we can do here is just not say anything about it (re dropping the error silently), and tighten it up later
JoeAndrieu: I don't think this is that big of a security problem, otherwise the POST spec would be phrased differently
… I think the general HTTP approach is -- if you don't recognize something, ignore it
… In our case -- so, first of all, the resolver may not know about the query param. It might just be a pass-through proxy
… so it would be odd for a resolver to error on an unrecognized param, since it's just supposed to pass it through
… on the other side for the client -- are they supposed to know which properties are allowed for which did method?
… I think they can just pick a resolver that they trust. but I'm not sure there should be a separate workflow that goes differently based on result
swcurran: two things -- I'd like to remove whatever wording related to unrecognized params, we can handle that separately
… second, you said - DID Resolver might be a proxy -- I think the PR I added removes any concept of the resolver being a proxy. it just returns the resolved URL
JoeAndrieu: I think we still have proxied resolution as an entire section in the did resolution step
… we should raise an issue in general, about proxies being appropriate or not
… I'll just raise that issue for future discussion
swcurran: sounds good
swcurran: based on my PR now, when you add a path to a DID URL, the result you get back is an array of URLs (with just one url) that is a URL to a resource of interest
… if relativeRef is passed, it is decoded and then appended to the end of the serviceEndpoint, combined with the path
… and that COULD produce an invalid url. do we care about that, or just do it?
… other question is -- when we append a relativeRef, are we doing it just by simply concatenating a string at the end, or are we doing a proper merge of URL components?
<Zakim> pchampin, you wanted to comment on the opacity of URLs
pchampin: URLs are not always intrinsically opaque. take HTML forms
… I see that that the DID Resolution has section 11.4 specifying specific did params. that's not opaque
… I remember Manu expressing concern about those params specifically (like the specific version param)
… I think I share his concern, with the disclaimer that my understanding is limited here
… so let's not over-rely on the url opacity argument
markus_sabadello: regarding Stephen's question about relativeRef. I would recommend we don't invent any new rules for URL appending strings etc. A Relative URI reference is a well-known concept, with established algs and libraries
… we even have a section in DID Core about relative uri refs
… the current DID Resolution spec also describes the relativeRef param in that way
… to apply the Relative Reference to a base URI you have. that should address your questions
swcurran: what should the wording be?
<JoeAndrieu> compose?
markus_sabadello: we should phrase is as 'execute the logic in DID Core related to relative reference'
… basically, look at that section and use similar lang
swcurran: there's a section on how to handle a path. and a different section of how to handle service and serviceType. And in my reading, they're mutually exclusive
… so I'm not sure what should happen when there's both a 'service' and a 'serviceType' param.
markus_sabadello: I'm curious if it matches people's understanding, that the path functionality is only triggered that if the DID Doc has the corresponding service endpoints
… my understanding was, if it doesn't have those service entries, it cascades to the DID Method
swcurran: the PR mentions -- the resolver may know other service types for path handling. the DID spec reserves one type, but did methods can override. if no service entry is found, it falls back to the DID Method
… and if DID method does not have contingency for it, it should return an error
markus_sabadello: ok sounds good
ottomorac: thanks Markus and Stephen and everyone else who contributed to this