14:58:38 <RRSAgent> RRSAgent has joined #did
14:58:42 <RRSAgent> logging to https://www.w3.org/2025/09/25-did-irc
14:58:53 <ottomorac> rrsagent, make logs public
14:58:57 <ottomorac> Meeting: Decentralized Identifier Working Group
14:59:05 <ottomorac> Chair: ottomorac
14:59:14 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Sep/0012.html
15:00:45 <JoeAndrieu> JoeAndrieu has joined #did
15:01:20 <swcurran> swcurran has joined #did
15:01:31 <swcurran> present+
15:01:33 <Wip> Wip has joined #did
15:01:39 <ottomorac> present+
15:01:39 <Wip> present+
15:01:43 <markus_sabadello> markus_sabadello has joined #did
15:02:51 <pchampin> present+
15:04:26 <JoeAndrieu> present+
15:04:27 <dmitriz> dmitriz has joined #did
15:04:37 <dmitriz> scribe+
15:04:50 <Wip> Wip has joined #did
15:05:03 <markus_sabadello> present+
15:05:30 <manu> present+
15:05:37 <pchampin> q+
15:05:46 <ottomorac> ack pchampin
15:05:54 <dmitriz> pchampin: I was contacted by some people that have a pending PR on DID Extensions
15:06:01 <Wip> q+
15:06:24 <dmitriz> ... and I realize that there's a few pending PRs there; I completely appreciate that this is an additional burden and that this group has been concentrating on specs etc
15:06:37 <manu> q+
15:06:42 <ottomorac> ack Wip
15:06:43 <dmitriz> ... I just told them I'd bring it up on a call, just so it's on the radar
15:06:59 <dmitriz> Wip: same (also had it brought to attention). It raises the challenge that this group does not have enough resources to manage that list / registry
15:07:15 <dmitriz> ... I replied that we had volunteers (who have gone quiet). I can't even do it, since I'm not on the list
15:07:31 <dmitriz> ... so the question is - what happens when the working group does not have the resources. and what happens when the WG is disbanded / expires
15:07:47 <ottomorac> ack manu
15:07:52 <dmitriz> ... also has to do with the perception that people have that being on that registry makes it a 'valid did method'
15:08:00 <pchampin> q+
15:08:03 <dmitriz> manu: yeah, it's always been a problem. it's usually me processing it, and I just dont' have time
15:08:13 <dmitriz> ... we have like 12 volunteers theoretically
15:08:21 <dmitriz> ... I mean, Will, if you want to be added to the list, we can certainly do that
15:08:22 <swcurran> q+
15:08:29 <dmitriz> ... the only way we can make this work is if we have volunteers
15:08:51 <dmitriz> ... because it's a constant drumbeat of new did methods. and the challenge is the folks that don't do it right, so there's a lot of education and back-and-forth
15:09:12 <dmitriz> ... what we can do is -- whoever complains, we can focus on their one, etc
15:09:12 <dmitriz> ... that's usually how it works
15:09:29 <dmitriz> ... the other option is, maybe, something that an AI bot can help process? (judge on whether a PR meets the rules criteria)
15:09:48 <dmitriz> ... and another option is -- we just merge everything. which we did not like as a concept, before
15:09:58 <dmitriz> ... soo, I think we're just stuck with the registry. we don't want to drop it on the floor
15:10:05 <dmitriz> ... so this dragging out / slow processing is better than nothing
15:10:07 <JoeAndrieu> q+
15:10:18 <ottomorac> ack pchampin
15:10:23 <dmitriz> ottomorac: I'd also like to be added
15:10:29 <JennieM> JennieM has joined #did
15:10:34 <JennieM> present+
15:10:37 <dmitriz> pchampin: will's question about the registry after the WG lifetime -- this is a Notes document
15:10:49 <dmitriz> ... if it was an official W3C Registry, that'd be a different process
15:10:59 <dmitriz> ... so Notes wise, the W3C Team maintains it (which doesn't help)
15:11:02 <manu> q+
15:11:12 <dmitriz> ... we have a precedent of a CG volunteering to maintain WG Notes after the WG expires
15:11:20 <dmitriz> ... so if we think that it might help, maybe we can have something similar here
15:11:32 <dmitriz> ... find a CG to volunteer to curate the DID Extensions / DID Registry
15:11:38 <ottomorac> ack swcurran
15:12:02 <dmitriz> swcurran: just as a matter of interest -- is there a definition of the minimum amount of info necessary for a PR?
15:12:09 <dmitriz> ... I assume the main problem is that one PR that has like 20 methods
15:12:12 <dmitriz> ... has that one been dealt with?
15:12:43 <ottomorac> ack JoeAndrieu
15:12:49 <dmitriz> ... the others look like single DID methods that follow the intent / spirit of the registry
15:12:53 <dmitriz> JoeAndrieu: I want to be a voice for getting rid of the registry entirely
15:13:00 <dmitriz> ... we had this problem from the beginning, and will continue to.
15:13:14 <dmitriz> ... we have consensus as a group that we should enforce conformance. but it's a pretty major burden
15:13:25 <dmitriz> ... identical DID methods (in a single PR) is within the rules
15:13:37 <dmitriz> ... we also agreed, and had some consensus, that we should make it an official W3C Registry
15:13:43 <dmitriz> ... so that's another option. (though we've failed at that)
15:13:54 <dmitriz> ... I want to put forward the question -- what do we think the registry is doing?
15:14:09 <dmitriz> ... the registry is not going to resolve security & privacy concerns. so then, what's it for
15:14:14 <ottomorac> ack manu
15:14:19 <dmitriz> ottomorac: yeah, and maybe something self-service?
15:14:36 <dmitriz> manu: for pchampin's comment -- who maintains the registry is just shuffling around the chairs on the deck of a sinking ship
15:14:54 <dmitriz> ... doesn't matter if it's CCG or W3C staff, still the same core issue of - work is not being done, reviewers are not reviewing
15:15:17 <dmitriz> ... and the issue is not necessarily with someone jamming 20 DID Methods in a single PR. the issue is more -- people are not reading/listening / doing the basic thing in PRs
15:15:29 <dmitriz> ... basically, people not paying attention. and having to review and re-review is really burdensome
15:15:54 <ottomorac> q?
15:16:01 <dmitriz> ... I don't want to get rid of the registry yet, but I'm open to what Joe is suggesting
15:16:12 <dmitriz> ... if there was some way to just list the methods without having a bad actor come in and DDOS the registry
15:16:14 <JoeAndrieu> q+ we don't know the number of DID methods
15:16:18 <dmitriz> ... if we can figure that out, we could get to self-service
15:16:20 <JoeAndrieu> q+ to say we don't know the number of DID methods
15:16:29 <dmitriz> ... I also don't want to spend time on this in the WG, we have way more important stuff to work on
15:16:48 <ottomorac> ack JoeAndrieu
15:16:48 <Zakim> JoeAndrieu, you wanted to say we don't know the number of DID methods
15:16:49 <dmitriz> ... also, I don't want to just come up with another plan that falls on the same people's lap
15:17:14 <dmitriz> JoeAndrieu: manu, we will never know how many DID methods are there
15:17:23 <dmitriz> manu: it's not a count, just that some people want there to be a list
15:17:35 <dmitriz> JoeAndrieu: that's centralization though; why do _we_ want there to be a list?
15:17:40 <dmitriz> ... sometimes it's a monetization thing
15:17:44 <dmitriz> ... what's the value prop for us?
15:17:52 <bigbluehat> present+
15:17:54 <dmitriz> manu: I have lots of thoughts on this. but I don't this is a good use of WG time
15:18:26 <Wip> q+
15:18:40 <ottomorac> ack Wip
15:18:49 <dmitriz> JoeAndrieu: hey, if we get rid of the registry, then people won't have to send Pierre emails. it's like fly-paper ...
15:18:56 <dmitriz> Wip: yeah, we could debate this, but probably not a good use of our time today
15:19:01 <dmitriz> ... maybe after horizontal review
15:19:18 <dmitriz> ottomorac: I'll open an issue about this to keep it on our radar
15:19:30 <ottomorac> Topic: Horizontal Review
15:19:45 <Wip> q+
15:19:56 <ottomorac> https://github.com/w3c/did-resolution/issues/177
15:19:56 <smccown> smccown has joined #did
15:20:01 <dmitriz> Wip: I just want to have this on the calendar as a touchpoint - where are we with the review
15:20:04 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3ATAG
15:20:07 <dmitriz> ... I think we're in a good state, if you have a look at the PRs
15:20:14 <smccown> present+
15:20:49 <dmitriz> ... lets spend some time on that, and also talk about the SING (?) review
15:20:49 <dmitriz> ottomorac: let's start with Manu's PR?
15:20:53 <ottomorac> https://github.com/w3c/did-resolution/pull/199
15:21:09 <dmitriz> Wip: we just need some more reviews on these PRs
15:21:22 <dmitriz> manu: yeah, not much to say about #199
15:21:37 <dmitriz> ... if TAG needs us to say more than that, they can tell us
15:21:46 <ottomorac> https://github.com/w3c/did-resolution/issues/187
15:21:50 <dmitriz> ... the PR would close 3 of our horiz rev issues
15:22:03 <dmitriz> ottomorac: the other one is #187
15:22:13 <dmitriz> ... I used some AI summary to help answer that question
15:22:19 <dmitriz> ... mentioned the testing suite
15:22:23 <dmitriz> ... do people have any comments on this?
15:22:24 <Wip> q+
15:22:32 <ottomorac> ack Wip
15:22:49 <dmitriz> Wip: why don't we open this is a PR?
15:22:52 <dmitriz> ottomorac: that section, the Relationship to Other Specs -- hasn't been merged into the main branch
15:23:03 <dmitriz> ... so I wasn't sure if I should branch off of Manu's PR
15:23:20 <dmitriz> Wip: ah, so you think this is going to be a subsection to the Relationship to Other Specs section?
15:23:28 <dmitriz> ottomorac: I was confused about Manu's PR
15:23:36 <ottomorac> - Add a "Design Goals and Rationale" 1.1 section before Conformance (this section will incorporate the changes required for issues 185, 187-189)- Add a "Relationship to Other Specifications" (New Appendix "C") (this section will incorporate changes required for issue 186)
15:23:42 <dmitriz> ... I asked about doing these 2 sections. which was, Design Goals and Rationale
15:24:04 <dmitriz> ... and the Relationship one which would be an appendix under pr 186?
15:24:18 <dmitriz> Wip: my recommendation is -- just put it in a PR wherever you think it goes. and we can reconcile it later
15:24:46 <ottomorac> q?
15:24:54 <dmitriz> ottomorac: I'll open an PR, no prob
15:24:57 <dmitriz> ... anything else?
15:24:58 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/191
15:25:10 <dmitriz> Wip: 191 - maybe I can ask Markus or Steve
15:25:19 <dmitriz> ... it's about filling out & addressing the Security & Privacy self-review
15:25:29 <dmitriz> ... this is the last review that we need to get in, then we can request horizontal reviews
15:25:35 <dmitriz> ... so, either Steve or Markus --
15:25:46 <dmitriz> smccown: when is it due by?
15:25:48 <dmitriz> WIp: soon as possible
15:26:18 <dmitriz> smccown: ok, I'll work on it this afternoon
15:26:23 <dmitriz> Wip: thanks
15:27:04 <ottomorac> Topic: DID Resolution Test Suite
15:27:08 <ottomorac> https://github.com/w3c-ccg/did-resolution-mocha-test-suite
15:27:09 <Wip> q+
15:27:15 <ottomorac> ack Wip
15:27:27 <dmitriz> Wip: I am making some progress. is there anyone willing to volunteer to help?
15:27:42 <dmitriz> ... I don't think we need a full on special topic call. I just need someone to sit with me, look at the code, talk through it
15:27:59 <dmitriz> ... one of the issues I have at the moment is - in the Resolution spec -- a lot of the properties are optional
15:28:15 <dmitriz> ... and "If it is defined, it MUST be like this...". I don't know the best way to test that
15:28:22 <dmitriz> ... so, would be great to have another pair of eyes on this
15:28:54 <Wip> https://w3c.github.io/did-resolution/#resolving-algorithm
15:29:00 <dmitriz> ... also the DID Resolution Algorithm. a lot of it is -- you need visibility inside the resolver
15:29:17 <dmitriz> ... there's a lot of statements that are hard/impossible to test
15:29:26 <dmitriz> ... so, we don't need to discuss it on the call right now, but I need help
15:29:37 <ottomorac> q?
15:29:39 <markus_sabadello> q+
15:29:45 <dmitriz> ottomorac: anyone have thoughts / volunteers?
15:29:48 <ottomorac> ack markus_sabadello
15:30:04 <dmitriz> markus_sabadello: wrt optional features -- isn't that something we also had to solve in other suites? VC-API etc?
15:30:18 <dmitriz> ... maybe put it into the config of the implementation, etc?
15:30:32 <dmitriz> ... the test suite should be able to test those things, conditionally, if supported in the impl config
15:30:38 <ottomorac> q?
15:30:49 <dmitriz> WIp: maybe yeah
15:31:07 <dmitriz> ottomorac: ok, let's just keep in mind, that we need somebody to help out here
15:31:21 <ottomorac> Topic: DID Resolution Internationalization Issues
15:31:27 <ottomorac> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3Ai18n-needs-resolution
15:31:46 <ottomorac> Subtopic: Define timestamp format carefully #203
15:31:52 <ottomorac> https://github.com/w3c/did-resolution/issues/203
15:32:18 <dmitriz> ottomorac: this is about the timestamp format, etc...
15:32:24 <dmitriz> ... something about normalizing to UTC
15:32:38 <ottomorac> q?
15:32:48 <Wip> q+
15:32:52 <ottomorac> ack Wip
15:32:58 <manu> q+
15:33:07 <dmitriz> WIp: I don't have many opinions on many of these i18n issues
15:33:16 <dmitriz> ... but we just need to address them for horiz review
15:33:28 <dmitriz> ... like, how do we even define the operation of normalizing to UTC?
15:33:32 <ottomorac> ack manu
15:33:43 <manu> https://w3c.github.io/vc-data-model/#representing-time
15:34:10 <Wip> q+
15:34:12 <dmitriz> manu:  we do have responses, like the one from VC DM, we should just point to that
15:34:21 <dmitriz> ... definitely not copy paste (it's too much text), but rerference
15:34:23 <ottomorac> ack Wip
15:34:49 <dmitriz> Wip: so we can just say 'as defined by VC DM'?
15:34:50 <dmitriz> manu: danger here is pulling in a normative dependency on VC DM, which we don't want to do
15:35:04 <dmitriz> ... but there aren't normative statements in that section. so it wouldn't be a straight up dependency
15:35:24 <dmitriz> ... yeah, we should just point to this section
15:36:33 <ottomorac> q?
15:36:35 <dmitriz> ottomorac: any volunteers?
15:36:44 <Wip> q+
15:36:48 <ottomorac> ack Wip
15:37:12 <dmitriz> WIp: I don't know if I want to do a PR, but I could write a comment -- do we have a section that you can reference, see what they say
15:37:23 <dmitriz> ... this seems like it has been solved by other specs
15:37:32 <ottomorac> Subtopic: Use character reference notation and Unicode names for references to specific characters #202
15:37:37 <ottomorac> https://github.com/w3c/did-resolution/issues/202
15:38:05 <dmitriz> ottomorac: seems a bit more editorial?
15:38:26 <pchampin> looks editorial to me
15:38:39 <manu> yep, editorial
15:39:14 <dmitriz> ... if it's ok with you, I'll just assign it
15:39:27 <dmitriz> ... to Markus
15:40:02 <ottomorac> Subtopic: relativeRef should prefer UTF-8 for percent encoding #201
15:40:08 <dmitriz> ottomorac: next one is our dear friend Relative Ref
15:40:14 <ottomorac> https://github.com/w3c/did-resolution/issues/201
15:40:29 <dmitriz> ... I don't know whether this is a discussion for next week (Weds)
15:40:44 <manu> q+
15:40:49 <dmitriz> ... what do you think Will?
15:40:50 <ottomorac> ack manu
15:40:51 <dmitriz> Wip: reading...
15:41:21 <dmitriz> manu: Addison us usually right about this stuff. I think it's separate, unless we get rid of relativeRef, which I don't think we're likely to
15:41:29 <dmitriz> ... so, he's right that we should prefer UTF8 for percent encoding
15:41:39 <Wip> q+
15:41:44 <ottomorac> ack Wip
15:42:02 <dmitriz> Wip: the change we need to make is - somebody needs to make a PR stating that we prefer UTF8, yeah?
15:42:07 <manu> q+
15:42:09 <dmitriz> ottomorac: I can take that on, if it's just the clarification
15:42:13 <ottomorac> ack manu
15:42:15 <JoeAndrieu> q+
15:42:25 <dmitriz> manu: just to be clear, this is a MUST. if we want to help interop
15:42:46 <ottomorac> ack JoeAndrieu
15:42:49 <dmitriz> ... you MUST encode disallowed URL chars using UTF8
15:42:49 <dmitriz> ottomorac: ok, so just make it a must statement
15:43:00 <dmitriz> JoeAndrieu: we should make it clear that this is for ALL URL params, not just relativeRef
15:43:04 <dmitriz> ottomorac: ok
15:43:07 <manu> +1 to what Joe said
15:43:08 <pchampin> s|encoding #201|encoding [#201](https://github.com/w3c/did-resolution/issues/201)
15:43:17 <ottomorac> Subtopic: DID parameters require ASCII-only #200
15:43:26 <ottomorac> https://github.com/w3c/did-resolution/issues/200
15:43:37 <dmitriz> ottomorac: so, this is another one, discussing various parameters here
15:43:45 <dmitriz> ... requirement that the value be an ASCII string...
15:43:54 <JoeAndrieu> q+
15:43:54 <dmitriz> ... some other references to an RFC
15:44:04 <ottomorac> ack JoeAndrieu
15:44:12 <dmitriz> JoeAndrieu: this seems directly entangled in the other one. shouldn't it be UTF8 and not ASCII?
15:44:14 <manu> q+
15:44:15 <dmitriz> ottomorac: yeah...
15:44:30 <Wip> q+
15:44:41 <ottomorac> ack manu
15:45:01 <dmitriz> manu: yeah, I agree with Joe -- the nuance here is -- we DID say ASCII on purpose originally
15:45:19 <dmitriz> ... but Addison is right unfortunately, we can't ignore that part of the world, non-US/Latin characters that billions people use, etc
15:45:33 <dmitriz> ... so yeah, it's entangled w UTF8, so we'll just have to clarify
15:46:03 <dmitriz> ... like, IF you have non-ASCII character, you MUST use UTF8 encoding. and percent-encode it to ASCII
15:46:20 <ottomorac> ack Wip
15:46:58 <dmitriz> Wip: (confirming he heard Manu correctly)
15:47:06 <ottomorac> q?
15:47:07 <dmitriz> Wip: ok, so, somebody just needs to define that process somewhere
15:47:18 <manu> q+
15:47:22 <ottomorac> ack manu
15:47:42 <dmitriz> manu: yeah, we should just say - this is a statement around encoding/decoding parameters. All parameters need to go through this process
15:47:57 <dmitriz> ... you start w an input string, ensure it's encoded as UTF8, then you percent-encode THAT value to get to an encoded param
15:48:17 <dmitriz> ... to decode a parameter, you percent-decode it and arrive at a UTF8 string.
15:48:17 <bigbluehat> q+
15:48:35 <ottomorac> ack bigbluehat
15:48:37 <dmitriz> bigbluehat: yeah, there's a couple of RFCs related to this
15:48:49 <dmitriz> ... that have a fallback to ASCII / related functions
15:48:51 <ottomorac> a couple RFC's have some stuff about this https://datatracker.ietf.org/doc/html/rfc3454 "stringprep"
15:48:55 <dmitriz> ... and discussion of footguns
15:49:14 <dmitriz> ... encoding UTF8 URLs has been around for decades etc
15:49:24 <dmitriz> ottomorac: ok, yeah, so that's connected to that other issue
15:49:29 <dmitriz> ... I'll try my hand at it
15:49:44 <manu> q+
15:49:50 <ottomorac> ack manu
15:50:23 <dmitriz> manu: I agree w bigbluehat that we need to reference an existing RFC, but specifically, we don't want to use Punycoding (that's for domain names only, not URL fragments)
15:50:44 <ottomorac> Ask Addison what should we ref for this
15:50:56 <ottomorac> Topic: DID Resolution PR Processing
15:51:06 <ottomorac> https://github.com/w3c/did-resolution/pulls
15:51:23 <ottomorac> Subtopic: Security Consideration -- DID Resolver Clients should detect resolution cycles #204
15:51:31 <ottomorac> https://github.com/w3c/did-resolution/pull/204
15:51:38 <ottomorac> PR from Stephen Curran regarding the issue with the infinite loop DID resolution cycles.
15:52:22 <dmitriz> swcurran: this isn't an issue for a DID Resolver, because it doesn't expand references, it just returns the DID Doc
15:52:27 <dmitriz> ... so this is for CLIENTS of a DID Resolver
15:52:32 <dmitriz> ... _that's_ where cycles can occur
15:52:47 <ottomorac> q?
15:52:49 <dmitriz> ... I did decide to put it in security consideration sections
15:53:08 <dmitriz> ... so, it's a short one - if you're a client of a resolver, and if you do repeated resolutions
15:53:12 <dmitriz> ... you may wind up in a cycle
15:53:19 <dmitriz> ... and should take steps to mitigate
15:53:32 <manu> I have no objections for it going into a security considerations section -- doesn't a DID Resolver do this, though?
15:53:33 <manu> q+
15:53:37 <ottomorac> ack manu
15:54:02 <dmitriz> manu: I thought we had some algorithm in the spec where the DID Resolver does it too?
15:54:07 <dmitriz> swcurran: I didn't see one
15:54:10 <dmitriz> manu: ok that's fine then
15:54:27 <JoeAndrieu> q+
15:54:44 <ottomorac> ack JoeAndrieu
15:55:07 <dmitriz> JoeAndrieu: I think there may be.. didn't we parametrize in the resolution request to de-reference it on the resolver level? that might run into this problem
15:55:09 <manu> My recollection is the same as Joe's
15:55:30 <dmitriz> ... otherwise, I agree with your analysis
15:55:38 <dmitriz> ... unless resolver has to do it, it's the client's problem
15:55:44 <dmitriz> swcurran: I'll take another look
15:55:50 <ottomorac> Subtopic: Define HTTP POST binding #196
15:55:57 <ottomorac> https://github.com/w3c/did-resolution/pull/196
15:56:26 <dmitriz> ottomorac: Will has provided approval, but it would be great if other folks also reviewed
15:56:28 <Wip> q+
15:56:36 <ottomorac> ack Wip
15:56:40 <Wip> https://github.com/w3c/did-resolution/pull/183
15:56:49 <dmitriz> Wip: this isn't about this PR, but just briefly -
15:57:13 <dmitriz> ... maybe this 'no cache allowed' is a 'feature not supported'?
15:57:51 <dmitriz> manu: wait, I'm confused
15:57:56 <Wip> https://github.com/w3c/did-resolution/pull/183
15:58:05 <dmitriz> Wip: sorry, this is about PR 183
15:58:40 <manu> q+
15:58:45 <ottomorac> ack manu
15:58:49 <dmitriz> ottomorac: I think Will was saying that instead of having a 'No-cache disallowed' error, we make it more generic, use the 'feature not supported' error instead
15:58:51 <dmitriz> manu: yeah, I think that would be fine
15:59:04 <dmitriz> ... as long as we have a description of what the missing feature is
16:01:54 <ottomorac> ottomorac has joined #did
16:02:24 <ottomorac> ottomorac has left #did
16:16:12 <TallTed> TallTed has joined #did
18:02:05 <Zakim> Zakim has left #did
19:04:46 <ottomorac1> ottomorac1 has joined #did
19:05:18 <ottomorac1> rrsagent, make minutes
19:05:19 <RRSAgent> I have made the request to generate https://www.w3.org/2025/09/25-did-minutes.html ottomorac1
19:06:03 <ottomorac1> m2gbot, link issues with transcript
19:06:04 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/177#issuecomment-3335573415
19:06:05 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/191#issuecomment-3335573461
19:06:06 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/203#issuecomment-3335573509
19:06:07 <m2gbot> comment already there: https://github.com/w3c/did-resolution/issues/203#issuecomment-3335573509
19:06:08 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/202#issuecomment-3335573603
19:06:09 <m2gbot> comment already there: https://github.com/w3c/did-resolution/issues/202#issuecomment-3335573603
19:06:10 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/201#issuecomment-3335573689
19:06:11 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/200#issuecomment-3335573737
19:06:12 <m2gbot> comment already there: https://github.com/w3c/did-resolution/issues/200#issuecomment-3335573737
19:06:13 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/204#issuecomment-3335573816
19:06:14 <m2gbot> comment already there: https://github.com/w3c/did-resolution/pull/204#issuecomment-3335573816
19:06:15 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/196#issuecomment-3335573893
19:06:16 <m2gbot> comment already there: https://github.com/w3c/did-resolution/pull/196#issuecomment-3335573893
19:06:31 <ottomorac1> zakim, end the meeting
19:06:59 <ottomorac1> RRSAgent, please excuse us
19:06:59 <RRSAgent> I see no action items