15:53:26 <RRSAgent> RRSAgent has joined #did
15:53:30 <RRSAgent> logging to https://www.w3.org/2026/01/22-did-irc
15:53:43 <ottomorac> rrsagent, make logs public
15:53:47 <ottomorac> Meeting: Decentralized Identifier Working Group
15:53:51 <ottomorac> Chair: ottomorac
15:53:55 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jan/0007.html
15:53:55 <agendabot> clear agenda
15:53:55 <agendabot> agenda+ Agenda Review, Introductions (5 min)
15:53:55 <agendabot> agenda+ Process Update (5 min)
15:53:55 <agendabot> agenda+ Use unicode names for special characters (7 min)
15:53:55 <agendabot> agenda+ Make https binding mandatory for network-based did resolvers #272 (7 min)
15:53:58 <agendabot> agenda+ Reminder about Ready for PR issues (10 min)
15:54:01 <agendabot> agenda+ DID Path Discussion (15 min)
15:54:06 <ottomorac> previous meeting: https://www.w3.org/2026/01/15-did-minutes.html
15:54:09 <ottomorac> next meeting: https://www.w3.org/2026/01/29-did-minutes.html
15:59:20 <TallTed> TallTed has joined #did
16:00:59 <Wip> Wip has joined #did
16:01:01 <Wip> present+
16:02:27 <pchampin> present+
16:02:28 <dmitriz> dmitriz has joined #did
16:02:57 <dmitriz> present+
16:03:18 <TallTed> present+
16:03:18 <KevinDean> KevinDean has joined #did
16:03:23 <KevinDean> present+
16:03:37 <ottomorac> present+
16:04:30 <dmitriz> scribe+
16:05:03 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/22-did-minutes.html TallTed
16:06:33 <markus_sabadello> markus_sabadello has joined #did
16:07:21 <JennieM> JennieM has joined #did
16:07:36 <ottomorac> zakim, next item
16:07:36 <Zakim> agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot]
16:07:55 <JennieM> present+
16:08:45 <dmitriz> ottomorac: <we'll do some issue review, PR review>
16:08:55 <dmitriz> ... anything else to add?
16:08:58 <ottomorac> q?
16:09:12 <dmitriz> ottomorac: before we do that, our charter ends in April
16:09:19 <dmitriz> ... and we can try to ask for an extension
16:09:28 <dmitriz> ... we can try to finish as much as we can before we do, for best effect
16:09:44 <dmitriz> ... I know that we also wanted to remind folks that we have a Security Interest Group call on the 3rd
16:10:04 <dmitriz> wip: yeah, it'll be great if people show up
16:10:19 <dmitriz> ... we can get a sense of where the security review is at
16:10:31 <Wip> https://github.com/w3c/securityig/issues/40#issuecomment-3779623532
16:11:10 <ottomorac> q?
16:11:32 <dmitriz> ottomorac: yeah, we can liaise with them, see about the threat modeling, etc
16:11:38 <ottomorac> zakim, next item
16:11:38 <Zakim> agendum 2 -- Process Update (5 min) -- taken up [from agendabot]
16:12:11 <dmitriz> Wip: previously, we've been marking issues as Pending Close, and then sending Pending Close reminders in email
16:12:26 <dmitriz> ... then Manu pointed out that we're in a bit of a rush, and don't have time for this extended timeline
16:12:46 <dmitriz> ... so we'll switch to -- once a PR is merged for an issue, we'll just close the issue addressed
16:12:52 <dmitriz> ... if you have any concerns, please voice them
16:12:59 <dmitriz> ... otherwise that'll be the policy going forward
16:13:09 <ottomorac> q?
16:13:31 <dmitriz> 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)
16:13:45 <ottomorac> q?
16:13:49 <ottomorac> zakim, next item
16:13:49 <Zakim> agendum 3 -- Use unicode names for special characters (7 min) -- taken up [from agendabot]
16:14:01 <ottomorac> https://github.com/w3c/did/pull/918
16:14:03 <JoeAndrieu> JoeAndrieu has joined #did
16:14:05 <dmitriz> ottomorac: this issue, using Unicode names for special characters, pr 918
16:14:11 <ottomorac> This change replicates unicode changesfrom this PR https://github.com/w3c/did-resolution/pull/269 into DID Core. After the changes are merged, I will raise another PR in the DID Resolution side to delete the duplicated terms that overlap with DID Core https://github.com/w3c/did-resolution/issues/232
16:14:11 <swcurran> swcurran has joined #did
16:14:17 <swcurran> present+
16:15:08 <ottomorac> q?
16:15:27 <Wip> q+
16:15:32 <dmitriz> ottomorac: reviews appreciated
16:15:41 <dmitriz> wip: this is exactly the same change we already made in Did Resolution, right
16:15:47 <dmitriz> ottomorac: right
16:16:02 <ottomorac> q?
16:16:06 <ottomorac> ack Wip
16:16:18 <ottomorac> zakim, next item
16:16:18 <Zakim> agendum 4 -- Make https binding mandatory for network-based did resolvers #272 (7 min) -- taken up [from agendabot]
16:16:34 <ottomorac> https://github.com/w3c/did-resolution/pull/272
16:16:55 <dmitriz> ottomorac: now that we have conformance classes defined, we can establish two things
16:17:06 <denkeni> present+
16:17:20 <dmitriz> ... one is - conforming resolvers must implement GET, and may implement post, and two, must use TLS
16:17:33 <Wip> q+
16:17:42 <ottomorac> ack Wip
16:17:43 <JoeAndrieu> q+ to ask about QUIC and TLS
16:17:45 <dmitriz> wip: this is great, yeah
16:18:02 <ottomorac> ack JoeAndrieu
16:18:02 <Zakim> JoeAndrieu, you wanted to ask about QUIC and TLS
16:18:03 <TallTed> q+
16:18:46 <dmitriz> 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?
16:18:53 <ottomorac> ack TallTed
16:19:38 <dmitriz> TallTed: I think there's a similar issue somewhere.. <something about recursive complex datatypes>
16:20:23 <dmitriz> manu: the language pointed to 'all conforming network-based did resolvers', but the text just said 'conforming did resolvers'
16:21:01 <dmitriz> ... I took out the mention of TLS -- it's presumed by using 'https'
16:21:14 <dmitriz> ... and that'll future-proof it. (the HTTPS spec has a bunch of text to that effect)
16:21:31 <dmitriz> ... in the final statement, you mention use of DNS is not required, etc -- that is the same statement, restated
16:21:48 <dmitriz> ... we can just say 'Resolvers may use TLS certs issued for IP addresses'
16:22:07 <JoeAndrieu> q+ to be said about the implication for DNS
16:22:27 <ottomorac> ack JoeAndrieu
16:22:27 <Zakim> JoeAndrieu, you wanted to be said about the implication for DNS
16:22:56 <dmitriz> 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
16:23:01 <ottomorac> All conforming network-based DID resolvers  MUST implement the GET version of the  and MAY implement the POST version.
16:23:03 <dmitriz> ... so maybe we don't want to imply the inverse
16:24:19 <dmitriz> ottomorac: ok, I'll accept manu's change suggestion, minus the IP TLS cert part
16:24:46 <Wip> q+
16:24:52 <ottomorac> ack Wip
16:25:02 <dmitriz> Wip: I see what you're saying, Ted.
16:25:13 <dmitriz> ... I'm not sure what the best way to handle is, maybe as a separate PR?
16:26:00 <dmitriz> TallTed: I think the cleanest way to do that is just to re-enumerate that list
16:27:24 <ottomorac> q?
16:27:43 <ottomorac> zakim, next item
16:27:43 <Zakim> agendum 5 -- Reminder about Ready for PR issues (10 min) -- taken up [from agendabot]
16:27:52 <ottomorac> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22ready%20for%20pr%22
16:28:24 <Wip> q+
16:29:18 <ottomorac> ack Wip
16:29:34 <dmitriz> Wip: this is just a reminder that some of these issues have been assigned to folks for some time
16:29:39 <dmitriz> ... we need to resolve em as soon as we can
16:29:55 <pdl-asu> pdl-asu has joined #did
16:30:12 <pdl-asu> present+
16:31:02 <dmitriz> Wip: the critical path is the tag 'needs resolution'
16:31:09 <dmitriz> ... we've got about 27 issues left?
16:31:16 <ottomorac> q?
16:31:37 <ottomorac> zakim, next item
16:31:37 <Zakim> agendum 6 -- DID Path Discussion (15 min) -- taken up [from agendabot]
16:32:10 <smccown> smccown has joined #did
16:32:17 <smccown> present+
16:32:28 <ottomorac> https://github.com/w3c/did-resolution/pull/260
16:32:20 <dmitriz> swcurran: I tried to align it to the rest of the spec's construction
16:32:52 <dmitriz> ... 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
16:33:07 <dmitriz> ... I also added returns for error conditions, including defining an error condition and including it in section 10
16:33:11 <dmitriz> ... so, looking for feedback
16:33:38 <dmitriz> ... the way we structured it now -- all of the query parameters are DID URL Dereferencing query params that are defined
16:33:47 <ottomorac> q?
16:34:01 <dmitriz> ... there's a line in there that I put about 'ignore params that are not recognized', and that raised a question in general
16:34:16 <dmitriz> ... looking at HTTP, it says, re query params, you COULD throw an error if you want, but most just ignore them
16:34:20 <TallTed> q+
16:34:23 <dmitriz> ... so that's thing one I'd like feedback on
16:34:28 <ottomorac> ack TallTed
16:34:28 <JoeAndrieu> q+
16:35:00 <dmitriz> TallTed: it feels like a potential security issue, to silently ignore things. maybe we can return an advisory, if not an error?
16:35:06 <dmitriz> ... just to say 'we ignored this'
16:35:26 <dmitriz> swcurran: what would be the form of that?
16:35:45 <dmitriz> TallTed: instead of 'error', we can say 'advisory' or 'warning', and say 'Ignored parameter XYZ'
16:36:24 <dmitriz> manu: in the VCALM spec, we have the ability to return warnings and errors as problem detail objectrs
16:36:46 <dmitriz> ... I'm not sure we want to add this concept to DID Resolution at this late stage,
16:37:03 <dmitriz> ... 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
16:37:14 <ottomorac> q?
16:37:56 <swcurran> q+
16:38:17 <dmitriz> ... so one thing we can do here is just not say anything about it (re dropping the error silently), and tighten it up later
16:38:23 <ottomorac> ack JoeAndrieu
16:38:46 <dmitriz> JoeAndrieu: I don't think this is that big of a security problem, otherwise the POST spec would be phrased differently
16:38:46 <dmitriz> ... I think the general HTTP approach is -- if you don't recognize something, ignore it
16:39:00 <dmitriz> ... In our case -- so, first of all, the resolver may not know about the query param. It might just be a pass-through proxy
16:39:18 <dmitriz> ... so it would be odd for a resolver to error on an unrecognized param, since it's just supposed to pass it through
16:39:32 <ottomorac> q?
16:39:34 <dmitriz> ... on the other side for the client -- are they supposed to know which properties are allowed for which did method?
16:39:34 <pchampin> q+ to comment on the opacity of URLs
16:39:51 <ottomorac> ack swcurran
16:39:51 <dmitriz> ... 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
16:40:10 <dmitriz> swcurran: two things -- I'd like to remove whatever wording related to unrecognized params, we can handle that separately
16:40:50 <JoeAndrieu> q?
16:40:54 <dmitriz> ... 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
16:41:07 <dmitriz> JoeAndrieu: I think we still have proxied resolution as an entire section in the did resolution step
16:41:48 <dmitriz> ... we should raise an issue in general, about proxies being appropriate or not
16:41:55 <dmitriz> ... I'll just raise that issue for future discussion
16:41:59 <dmitriz> swcurran: sounds good
16:42:42 <ottomorac> q?
16:42:46 <markus_sabadello> q+
16:43:00 <dmitriz> 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
16:43:14 <dmitriz> ... if relativeRef is passed, it is decoded and then appended to the end of the serviceEndpoint, combined with the path
16:43:25 <dmitriz> ... and that COULD produce an invalid url. do we care about that, or just do it?
16:43:48 <dmitriz> ... 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?
16:44:18 <ottomorac> ack pchampin
16:44:18 <Zakim> pchampin, you wanted to comment on the opacity of URLs
16:45:00 <dmitriz> pchampin: URLs are not always intrinsically opaque. take HTML forms
16:45:23 <dmitriz> ... I see that that the DID Resolution has section 11.4 specifying specific did params. that's not opaque
16:45:36 <dmitriz> ... I remember Manu expressing concern about those params specifically (like the specific version param)
16:45:49 <dmitriz> ... I think I share his concern, with the disclaimer that my understanding is limited here
16:46:00 <dmitriz> ... so let's not over-rely on the url opacity argument
16:46:08 <ottomorac> ack markus_sabadello
16:46:46 <dmitriz> 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
16:46:54 <dmitriz> ... we even have a section in DID Core about relative uri refs
16:47:04 <dmitriz> ... the current DID Resolution spec also describes the relativeRef param in that way
16:47:37 <dmitriz> ... to apply the Relative Reference to a base URI you have. that should address your questions
16:48:02 <ottomorac> q?
16:48:31 <dmitriz> swcurran: what should the wording be?
16:48:38 <JoeAndrieu> compose?
16:48:51 <dmitriz> markus_sabadello: we should phrase is as 'execute the logic in DID Core related to relative reference'
16:49:01 <dmitriz> ... basically, look at that section and use similar lang
16:50:46 <dmitriz> 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
16:50:50 <dmitriz> ... so I'm not sure what should happen when there's both a 'service' and a 'serviceType' param.
16:50:52 <ottomorac> q?
16:51:22 <ottomorac> q?
16:51:29 <markus_sabadello> q+
16:51:37 <ottomorac> ack markus_sabadello
16:51:57 <dmitriz> 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
16:52:18 <swcurran> q+
16:52:18 <dmitriz> ... my understanding was, if it doesn't have those service entries, it cascades to the DID Method
16:52:29 <ottomorac> ack swcurran
16:53:16 <dmitriz> 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
16:53:24 <ottomorac> q?
16:53:28 <dmitriz> ... and if DID method does not have contingency for it, it should return an error
16:53:34 <dmitriz> markus_sabadello: ok sounds good
16:53:40 <ottomorac> q?
16:54:03 <dmitriz> ottomorac: thanks Markus and Stephen and everyone else who contributed to this
17:02:51 <markus_sabadello> markus_sabadello has joined #did
17:34:36 <markus_sabadello> markus_sabadello has joined #did
17:47:04 <markus_sabadello> markus_sabadello has joined #did
17:52:42 <markus_sabadello> markus_sabadello has joined #did
18:34:06 <ottomorac> ottomorac has left #did