15:57:53 RRSAgent has joined #did 15:57:57 logging to https://www.w3.org/2026/03/05-did-irc 15:57:58 rrsagent, make logs public 15:58:04 Meeting: Decentralized Identifier Working Group 15:58:08 Chair: Wip 15:58:13 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Mar/0001.html 15:58:13 clear agenda 15:58:13 agenda+ Agenda Review, Introductions (5 min) 15:58:13 agenda+ DID Path PR \[1\] (15 min) 15:58:13 agenda+ Add rules for DID URL query normalization \[2\] (10 min) 15:58:13 agenda+ Tracking of resolutions and dereferences by downstream entities from the resolver \[3\] (10 min) 15:58:16 agenda+ Inconsistent use of resolution \[4\] (15 min) 15:58:19 previous meeting: https://www.w3.org/2026/02/26-did-minutes.html 15:58:26 next meeting: https://www.w3.org/2026/03/12-did-minutes.html 16:00:30 present+ 16:00:44 swcurran has joined #did 16:00:58 present+ 16:01:11 I have made the request to generate https://www.w3.org/2026/03/05-did-minutes.html TallTed 16:01:27 present+ 16:02:45 KevinDean has joined #did 16:02:45 present+ 16:03:27 scribe+ 16:03:55 present+ Om_Goeckermann 16:04:04 present+ 16:04:12 We have a visitor joining the call today: Om Goeckermann 16:04:27 zakim, next agendum 16:04:27 agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot] 16:05:39 Wip: We'll talk about DID Path PR, we have some issues that need a bit of discussion (DID URL query normalization), inconsistent use of resolution, any other suggestions/changes. 16:06:11 manu: We should also talk about DID v1.1 CR 16:06:21 scribe+ 16:07:22 manu: The publication has happened. Thanks to PA for pushing it through the process. Our strategy for the test suite is to take all the DID Docs run them through the test suite 16:07:53 JennieM has joined #did 16:08:01 present+ 16:08:03 ... upgrade them to the 1.1 context and rerun the tests. We have not done full JSON-LD processing on them -- still need to do that and then done. 16:08:07 I have made the request to generate https://www.w3.org/2026/03/05-did-minutes.html TallTed 16:08:43 ... We still need to integrate in the CID spec in the context. Since the context is non-normative, OK to change, but need to make the changes and need to run the test after the changes. 16:09:14 q+ 16:09:14 ... Don't want to get implementors to test until then, but they can do that after -- a few weeks. But we're in good shape. 16:09:57 ack pchampin 16:10:07 ... need to have DID Resolution ready to move to the next stage. Update the context for the DID Resolution context and rerun the tests. That will get past some of the exit criteria. 16:10:09 https://www.w3.org/news/2026/w3c-invites-implementations-of-decentralized-identifiers-dids-v1-1/ 16:10:19 q+ 16:10:35 pchampin: W3C has already published and requested implementor feedback now. 16:10:38 ack manu 16:10:47 wip: Manu are you doing the context/testing work? 16:11:33 manu: Yes, though I might need some help from PA. Need to get DID Resolution context stabilized. Need to do all of this as soon as possible since we are in CR. 16:11:38 zakim, next agendum 16:11:38 agendum 2 -- DID Path PR \[1\] (15 min) -- taken up [from agendabot] 16:11:42 scribe+ 16:11:42 https://github.com/w3c/did-resolution/pull/260 16:12:02 Wip: There are two things identified in the group. 16:12:08 JoeAndrieu has joined #did 16:12:12 swcurran: I went through all comments, I have a presentation to go through all changes. 16:12:41 https://pr-preview.s3.amazonaws.com/swcurran/did-resolution/pull/260.html 16:12:42 swcurran: Looking at PR 260 16:14:06 swcurran: Should there be a MUST on handling of query parameters, service types, what does a DID URL Dereferencer have to handle those things? 16:14:30 q+ 16:14:33 ack JoeAndrieu 16:14:48 smcown has joined #did 16:14:52 present+ 16:15:22 +1 for Joe's comments ... handling of "things" should be a "should" 16:15:22 q? 16:15:28 JoeAndrieu: I do think this should not be a MUST -- but if it is present, it must be defined in this way -- we have DID Methods out there that don't use PathService and if we make this a MUST, we'll just have non-conforming methods. 16:15:33 manu: +1 on what Joe said. 16:15:56 swcurran: Ok, will do that... change it to a SHOULD. 16:16:15 q+ to say it's more than just SHOULD 16:16:33 swcurran: Next item -- unknown parameters, not mentioned in the defined algorithm. Other parameters that come up -- what do we do about it? 16:16:33 q+ 16:16:47 swcurran: I do think it's something for the group, but not for this PR. 16:16:47 ack JoeAndrieu 16:16:47 JoeAndrieu, you wanted to say it's more than just SHOULD 16:17:01 JoeAndrieu: Agree that we shouldn't deal w/ this in the PR. 16:17:27 JoeAndrieu: on previous item -- SHOULD process PathService, but if implemented, MUST follow rules in this spec... something to that effect. 16:17:45 ack manu 16:17:59 Wip: Yes, you SHOULD support PathService, but if you do support it, you MUST implement it in the way that it's in the spec. 16:18:00 scribe+ 16:18:10 manu: +1 on the previous item 16:18:32 ... On this item. I agree its not in scope. We can raise an issue. However, one option is not to say anything about unkown parameters 16:18:43 ... Lets raise an issue and have a more detailed conversation 16:18:49 scribe- 16:19:03 swcurran: I think there might be an issue already for this. 16:19:46 q+ 16:19:49 swcurran: This is about ReSpec, use bullet list -- I get numbers... instead of bullets. 16:19:50 q+ 16:20:09 ack TallTed 16:20:13 swcurran: I added a style, stuck it into styles where other styles are defined, is that ok? 16:20:32 TallTed: If we can write up that bug in ReSpec, I have no problem writing a style like this. 16:20:48 TallTed: Is there a bug in the markup? 16:20:58 swcurran: All things I tried, always incremented the numbers. 16:21:40 swcurran: There are other places where we're using algorithm, where it would make more sense to not have numbers... apply the relative ref with these inputs, we try to use bullets but end up with numbers. I'd do this in a few more places, happy to have others figure it out. What do we do with this PR? 16:21:42 q? 16:21:44 q+ 16:21:51 ack manu 16:22:02 TallTed: I'd do that for now, turn it into a fresh issue. 16:22:13 bigbluehat has joined #did 16:22:33 present+ 16:22:37 q- 16:22:50 +1 to finding the bug 16:23:20 manu: It's not a ReSpec bug, it's just a CSS bug, we should fix it. We can fix it later, we can raise an issue to remember to fix it -- it'll be editorial. 16:23:22 +1 to manu 16:23:48 q+ to volunteer to investigate the CSS 16:24:21 swcurran: I'm going to revert 16:24:23 ack pchampin 16:24:23 pchampin, you wanted to volunteer to investigate the CSS 16:24:29 manu: Nah, let's keep the right markup and fix CSS later. 16:24:41 pchampin: Leave it and I can look into it to see what's wrong with the CSS. 16:25:02 swcurran: I'll remove the styles that I put in and will remove the class on the unordered list that I have. 16:25:30 +1 if we remove, we lose backwards compat 16:25:38 swcurran: Finalize fallback to DID Method for path handling if there's no PathService -- in text right now, Markus seems to be good with it.... 16:25:39 q? 16:25:40 +1 to keep (not +1 to remove) 16:26:17 q+ this section is did-resolution specific, not PathService 16:26:18 swcurran: Joe had a comment about basePath attribute -- how do we figure out how path is handled -- I don't think it works with out that and I don't think it needs to. we already have fallback mechanisms on how paths can be handled. 16:26:22 ack JoeAndrieu 16:26:23 q+ to this section is did-resolution specific, not PathService 16:26:26 ack JoeAndrieu 16:26:26 JoeAndrieu, you wanted to this section is did-resolution specific, not PathService 16:26:54 JoeAndrieu: This section isn't in the PathService algorithm description, other algorithms shouldn't be required to do this, just PathService. 16:26:57 swcurran: How can I do that? 16:27:29 JoeAndrieu: Part of this document talks about resolution, we shouldn't put it there... we should put it in path handling. 16:27:50 swcurran: I don't agree with that characterization, but perhaps you can help 16:27:51 q+ 16:28:00 q+ to raise tracking issue? 16:28:08 ack manu 16:28:08 manu, you wanted to raise tracking issue? 16:28:12 scribe+ 16:28:22 manu: Was this language there already? 16:28:28 swcurran: no it wasnt 16:28:50 manu: Can we put in an issue marker saying we need to figure out where to put this language and raise an issue against it 16:28:57 ... Then we can deal with it in a future issue 16:29:03 JoeAndrieu: I would rather we didnt 16:29:14 ... Rushing it into review right now is not helped 16:29:29 manu: Can we just raise an issue and deal w/ it in another PR. 16:29:32 ... This is structural to the whole PR. Where we have things that are path service specific, we need to fix that 16:29:42 JoeAndrieu: We need to fix this in one fell swoop. 16:30:22 Wip: Joe, I think what you're suggesting, a refactoring so this functionality happens in PathService. 16:30:27 JoeAndrieu: Yes, I'll commit to that. 16:30:35 swcurran: I'll make the other changes. 16:30:47 zakim, next agendum 16:30:47 agendum 3 -- Add rules for DID URL query normalization \[2\] (10 min) -- taken up [from agendabot] 16:30:48 swcurran: That's everything. 16:30:54 https://github.com/w3c/did-resolution/issues/218 16:31:41 Wip: Can anyone take this issue on? 16:33:25 manu: They just want us to talk about the things you should pay attention to if you are doing DID URL query normalization 16:33:37 ... e.g. pecent encoding, duplicate params, relative paths, canonicalization rules 16:33:54 q+ 16:34:00 ack swcurran 16:34:24 swcurran: I can give it a shot, what does c14n by DID Method mean? 16:34:34 q+ 16:34:34 ack manu 16:35:00 I have made the request to generate https://www.w3.org/2026/03/05-did-minutes.html TallTed 16:35:06 manu: On canonicalization by DID method, I think what they are presuming is the the DID method itself can have its own query normalization and canonicalization rules 16:35:15 ... e.g. if you see foo:bar, delete it from the URL 16:35:27 ... This is possible, even if its not recommended 16:35:39 ... We could also say as a WG that you should not have special canonicalization rules 16:35:47 ... in your DID method. But people will probably ignore us 16:35:56 ... We should tell implementers to look out for that stuff 16:36:05 swcurran: Ok, I'll give it a shot. 16:36:35 zakim, next agendum 16:36:35 agendum 4 -- Tracking of resolutions and dereferences by downstream entities from the resolver \[3\] (10 min) -- taken up [from agendabot] 16:36:42 https://github.com/w3c/did-resolution/issues/293 16:36:55 Wip: This is the last privacy issue we need to resolve. 16:37:04 Wip: We didn't come to a concrete decision last week. 16:37:54 q+ to say maybe we recommend methods have a threat model 16:37:57 Wip: If you resolve a did:web locally, you have to call out to another system, there are concerns around that -- maybe we just add some privacy considerations? Clients can take steps to obfuscate... wondering if it should be a SHOULD. 16:38:01 ack JoeAndrieu 16:38:01 JoeAndrieu, you wanted to say maybe we recommend methods have a threat model 16:38:43 JoeAndrieu: Maybe we recommend for DID Methods to have threat models -- each DID Method should be evaluated for threats unique to it -- DID Methods SHOULD provide a threat model, but good idea to explain architectures. 16:38:56 JoeAndrieu: I think he's trying to get to what would be exposed in that threat model, that might be one way to respond. 16:38:57 q+ 16:39:00 q- 16:39:05 manu: Yes, I like that suggestion 16:39:11 Wip: I like the suggestion 16:39:38 Wip: Do we talk about these items in DID Core? or CID? 16:39:52 Wip: He doesn't want implementers to not notice sharp parts -- use of DIDs vs Resolution 16:39:53 q+ 16:39:57 ack manu 16:41:09 manu: Do we point to the DID spec for privacy considerations 16:41:14 Wip: yep 16:41:41 manu: I think we should just cross reference with the privacy considerations in DID and CID spec that speak to the concerns raised 16:41:51 ... It may be that we dont have this written anywhere 16:42:07 ... We have the chaining working. Resolution to DID to CID 16:42:17 ... Lets map his concerns to these sections 16:42:52 Wip: Ok, I can take this on, then. I also like Joe's suggestion of pointing to a threat model. 16:42:53 q+ 16:43:10 ack manu 16:43:14 q+ to reference section error 16:43:19 Wip: Can we add privacy considerations to DID Core? 16:43:23 manu: Yes 16:43:59 ... Question to JoeAndrieu about threat model. All specs are required to have security and privacy considerations. When security and privacy do reviews they refer to both 16:44:51 Wip: In our approach, we do like the threat model to include any kind of threat -- we didn't want to restrict it to a particular category -- like human rights violations are a particular type of threat. We have no really resolved through PING if that's how they want privacy included -- don't know if it would meet their needs, where we may shift expectations for privacy considerations section. 16:44:52 q+ 16:44:57 ack JoeAndrieu 16:44:58 JoeAndrieu, you wanted to reference section error 16:45:07 s/Wip: In our approach/JoeAndrieu: In our approach/ 16:45:26 ack manu 16:46:02 q+ to mention multiplicity of threat models. 16:46:12 manu: +1 to that Joe, thats fine. The idea that you have all your threats in one section, security and privacy. I hope SING is moving in that direction. Otherwise it will be awkward to follow 16:46:48 ... This is a privacy review, so pointing them to the threat model might confuse the reviewer. It would be good to get his feedback on using the threat model for privacy analysis 16:47:09 ... When we say all threats, security and privacy is in scope. HUman rights violations, What about market competition 16:47:16 ... Trying to figure out the boundary 16:48:04 JoeAndrieu: There is a necessary decision made by threat modeller that is in the mode of a story teller that has particular locus of attention. When we're modelling threats of CSS, most people are not going to entangle semiconductor considerations into that model (legit threat, hardware focused threat model, but probably not in scope for the way CSS speaks to it). 16:48:58 JoeAndrieu: Two things are a result of that -- each threat model has a locus of attention, and they can put component in to talk about it -- TPM module not in diagram, don't need to talk about it. I think it's appropriate to have a multiplicity of threat models, same diagram, privacy threats from security threats -- so maybe that's how we can address complexity. 16:49:20 Wip: Maybe we raise this with Ben, maybe Joe is best person to do that... talk about threat model and how it might help privacy. 16:49:28 Wip: See if he gets a response from Ben -- 16:49:33 JoeAndrieu: Yes, I can look into that. 16:49:35 https://github.com/w3c/did-resolution/issues/293 16:49:57 JoeAndrieu: Just created an issue -- our references is not working on Github Pages, added an issue for that. 16:50:05 zakim, next agendum 16:50:05 I see a speaker queue remaining and respectfully decline to close this agendum, Wip 16:50:12 q? 16:50:14 ack JoeAndrieu 16:50:14 JoeAndrieu, you wanted to mention multiplicity of threat models. 16:50:16 zakim, next agendum 16:50:16 agendum 5 -- Inconsistent use of resolution \[4\] (15 min) -- taken up [from agendabot] 16:50:23 https://github.com/w3c/did-resolution/issues/226 16:50:35 q+ 16:50:39 Wip: Maybe provide an update on issue 226 -- consistent use of resolution, how is threat modelling going, how is it going w/ this issue. 16:50:41 ack JoeAndrieu 16:52:22 q+ 16:52:33 JoeAndrieu: I added some of the language that has come from the DID Resolution threat model, where I formally talked through things in context of this diagram. Diagram isn't in there, labels might be confusing, but ignore that for now. Shared with a few folks, seems like accurate representation based on some external reviews -- would love to get some feedback. One good meeting w/ Steve McCown that added some things to diagram, profile of at least three 16:52:34 different methods... did:key, did:btcr, did:webvh to see if it aligns. Pull that in, wrt. 226, I hope that next weekend pulls in draft and make pass. 16:52:34 ack Wip 16:53:14 q+ 16:53:16 Wip: That would be good progress. I looked at text now, sentence that says DID Parameters turn into resolution options and passed into DID URL when it is resolved... doesn't resolution take in DID vs. DID URL? 16:53:21 ack JoeAndrieu 16:53:56 JoeAndrieu: Yes, that's an error in the current spec... if resolver doesn't have full DID URL, it might not receive calling parameters, no reason to cut off path / query parts -- shouldn't get rid of path and query parts. 16:54:06 Wip: So, changes? 16:54:10 I have made the request to generate https://www.w3.org/2026/03/05-did-minutes.html TallTed 16:54:16 JoeAndrieu: Why wouldn't we pass on full URL 16:54:16 manu: +1 to passing on full URL 16:54:41 Wip: This sounds like we defined two separate APIs, this is going to collapse into one? 16:54:47 JoeAndrieu: No, it isn't. 16:55:40 JoeAndrieu: swcurran talk about how it could be one thing, but I believe it's two different things. We don't talk about the separation well, and one of the consequences are that we have algorithms in places we shouldn't have those things. 16:56:07 JoeAndrieu: Dereferencing a particular resource may not be resolvable to a particular URL... for example, a DID Ordinal, which doesn't exist at a URL. 16:56:41 Wip: Yes, this all sounds fine -- this will help make spec more clear -- concerned that test suite ramifications aren't that terrible... we'll see. 16:56:46 JoeAndrieu: I hope to have a draft this weekend. 16:56:54 Wip: Any other comments before we close? 16:57:05 Wip: We are pushing to have all of this stuff ready for CR by end of this month. 16:58:24 I have made the request to generate https://www.w3.org/2026/03/05-did-minutes.html TallTed 16:59:31 rrsagent, make minutes 16:59:32 I have made the request to generate https://www.w3.org/2026/03/05-did-minutes.html Wip 16:59:39 m2gbot, link issues with transcript 16:59:40 comment created: https://github.com/w3c/did-resolution/pull/260#issuecomment-4006423856 16:59:41 comment created: https://github.com/w3c/did-resolution/issues/293#issuecomment-4006423914 16:59:42 comment created: https://github.com/w3c/did-resolution/issues/226#issuecomment-4006423986 16:59:48 zakim, please excuse us 16:59:48 leaving. As of this point the attendees have been pchampin, swcurran, TallTed, KevinDean, Om_Goeckermann, Wip, JennieM, smcown, bigbluehat 16:59:48 Zakim has left #did 17:00:07 RRSAgent, please excuse us 17:00:07 I see no action items