23:51:11 RRSAgent has joined #did 23:51:15 logging to https://www.w3.org/2025/04/03-did-irc 23:51:21 rrsagent, draft minutes 23:51:22 I have made the request to generate https://www.w3.org/2025/04/03-did-minutes.html ottomorac 23:51:31 rrsagent, make logs public 23:51:46 Meeting: Decentralized Identifier Working Group 23:51:58 Chair: ottomorac 23:53:25 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Apr/0003.html 00:01:06 present+ 00:03:19 KevinDean has joined #did 00:03:25 present+ 00:03:38 denkeni has joined #did 00:03:39 prsent+ 00:03:42 present+ 00:03:46 scribe+ 00:04:03 present+ 00:05:23 ottomorac has changed the topic to: Volunteers for Horizontal Review Documents 00:05:24 ottomorac: Thanks for attending, first topic is horizontal reviews. 00:05:47 ottomorac: We've been discussing in regards to have volunteers to help out. The DID spec might be easier to do an HR for. DID Resolution will take more work. 00:06:00 https://github.com/w3c/did/issues/885 00:06:01 ottomorac: We do have two issues that we've opened for this. 00:06:11 https://github.com/w3c/did-resolution/issues/139 00:06:16 q+ 00:06:22 ack manu 00:06:23 scribe+ 00:06:41 manu: Horizontal review is required for any normative standards track specification. 00:06:54 ...We have already gone through this for the DID spec. 00:07:12 ...It should go pretty quickly. I volunteered to put together some of it but welcome help in putting it together. 00:07:23 ...The DID Resolution spec is going to take quite a bit of work. 00:07:33 ...There are good instructions on what you have to put together in the issues. 00:07:41 ...W3C has it pretty well documented. 00:08:03 ...Usually what happens is they have a questionnaire and you fill it out. You fill it out and submit to the issue tracker. 00:08:21 ...They review the spec and respond. Sometimes they pull you in to talk about the spec in their meetings. 00:08:25 scribe- 00:08:42 ottomorac: ok, denken if you or anyone else in the group is interested, let us know and we'd be happy to take any help on that. 00:09:01 ottomorac has changed the topic to: DID Core PR Processing 00:09:19 Topic: DID Core PR Processing 00:09:20 https://github.com/w3c/did/pull/887 00:09:37 subtopic: https://github.com/w3c/did/pull/887 00:09:37 TallTed has joined #did 00:09:47 ottomorac: You've gotten some feedback from Ted in there, and from Ivan -- just be aware of the PR. 00:09:57 q+ 00:10:01 ack manu 00:10:09 scribe+ 00:10:24 manu: 887 is a pretty big change. 00:10:40 ...It's not normative. We're still trying to align with the DID spec. 00:11:04 ...We're trying to eliminate the abstract data model and follow what the control spec is doing, which is establish a processing algorithm. 00:11:36 ...It also makes the media type clear. There's now just one media type application/did. And you can also use JSON-LD on it to process it. 00:12:14 ...Basically, what this does, the base specification we depend on is INFRA. It's debatable whether INFRA is abstract data model; I assert that it is, others assert that is isn't. 00:12:29 ...This is the data model for the web and DOM environment, and it has a concrete mapping to JSON. 00:12:40 ...You map INFRA to JSON and that's it. 00:13:11 ...We used to have two representations in the spec, after years of debate. After we had some implementation experience, people asked why we had two. 00:13:45 ...What I've done here is that we have one JSON representation. The PR includes the @context value and deletes the entire JSON-LD representation. 00:14:07 ...We preserved the rules because we can't make breaking changes. We just need other folks to look and see if they agree. 00:14:44 ...The other thing that I couldn't remove that there could be other representations. You can have a document and a YAML representation for it, as long as you can round-trip to JSON losslessly. 00:15:00 ...Any representation is legitimate as long as it can round trip to the concrete data model. 00:15:12 ...I don't think it makes any normative changes so we're within our charter. 00:15:13 q+ 00:15:14 scribe- 00:15:19 ack ottomorac 00:15:33 ottomorac: Yes, that explanation makes sense. 00:15:42 present+ Jennie 00:15:45 present+ TallTed 00:15:53 ottomorac: Seems like we're on the right path forward. 00:16:00 scribe+ 00:16:16 manu: I'm probably going to leave it until the call next week to give extra review time. 00:16:17 scribe- 00:16:26 subtopic: https://github.com/w3c/did/pull/886 00:16:44 Clarify restrictions on identifiers used in DID documents. #886 00:17:00 I have made the request to generate https://www.w3.org/2025/04/03-did-minutes.html TallTed 00:17:06 ottomorac: Same sort of situation -- Ted had some changes that have been merged. 00:17:06 scribe+ 00:17:50 manu: This is asking when parameters should be dropped. 00:18:09 ...Is a DID document with an ID in it, can you put query parameters or fragment identifiers in the ID? 00:18:16 ...This states clearly not. 00:18:56 ...We also provide non-normative guidance, saying if you are going to have a long-lived canonical identifier, you should probably not use a query parameter, unless you really know what's going on there. 00:19:07 ...The query parameter is probably not something you want to store, just the base DID. 00:19:15 previous meeting: https://www.w3.org/2025/03/27-did-minutes.html 00:19:15 next meeting: https://www.w3.org/2025/04/17-did-minutes.html 00:19:27 ...Fragment identifiers, you probably want to use, because it may refer to a validation method. 00:19:42 ...If you do use a fragment identifier, make sure it's unique over the lifetime of the document. 00:20:10 ...If you use key1, key2, key1, key2... over years, it can change the way the document is handled. 00:20:26 ...This text goes over that at a high level and addresses issue 337. 00:20:27 q? 00:20:29 scribe- 00:20:39 +1 to make it clear in did spec 00:20:42 ottomorac: This one makes sense too. 00:20:54 TallTed: I'll take a quick look at it, but expect it'll be fine. 00:21:10 scribe+ 00:21:24 manu: There's a triple-bracket syntax for references. 00:21:42 ...I think you made the right change. ReSpec substitutes the specification for the name in the square brackets. 00:21:48 ...You have to know what it expands to. 00:21:52 scribe- 00:22:24 ottomorac: I think we're nearly ready on it, maybe get final approval from Ted and then wrap it up. 00:22:40 ottomorac has changed the topic to: DID Core Issues 00:22:51 topic: DID Core Issues 00:23:28 ottomorac: I took a look at these, need for a PR from some folks, unless we have a specific issue to discuss, feel free. 00:23:32 q+ 00:23:42 ack manu 00:23:49 scribe+ 00:24:02 manu: There are four issues. We need Joe for one of the class 2 ones. 00:24:12 ...I'm wondering if we can talk about at least one of them. 00:24:44 ...Let's go with 849. 00:24:51 subtopic: https://github.com/w3c/did/issues/849 00:24:56 scribe- 00:25:11 scribe+ 00:25:27 manu: We could either decide to take it over and do the PR or just mark it pending close because they haven't provided something. 00:26:19 ...I suggest we just mark it pending close. If it's really important to folks, they will respond. We haven't received a response in 15 months. 00:26:43 ...We can say that we discussed it in the working group and that we'll close it in seven days unless they raise a PR. 00:27:31 ...In this discussion, the scribe contents will be injected into the issue. 00:27:44 scribe- 00:27:49 ottomorac has changed the topic to: DID Resolution Issue around JSON vs JSON-LD 00:27:59 subtopic: https://github.com/w3c/did-resolution/issues/137 00:28:48 ottomorac: Ivan and Markus provided input here. Any other input? 00:28:49 q+ 00:28:53 ack manu 00:29:00 scribe+ 00:29:16 manu: I think we should use JSON. I don't think there's a strong argument for JSON-LD in the resolution spec. 00:29:47 ...Ivan did raise it, but we would object to using JSON-LD for the API calls, but the data is JSON-LD. I don't think there's a strong argument for JSON-LD in the API. 00:30:07 ...I'll note that the reason we're saying this is that this is exactly what we did in the VC API. 00:30:39 q? 00:30:40 ottomorac: ok, makes sense. 00:30:42 scribe- 00:31:07 ottomorac has changed the topic to: DID Resolution Issue Processing 00:31:12 topic: DID Resolution Issue Processing 00:33:13 https://github.com/w3c/did-resolution/issues/13 00:33:27 scribe+ 00:33:42 subtopic: https://github.com/w3c/did-resolution/issues/13 00:33:51 Validate signatures/proofs of DID Document #13 00:34:20 manu: This one is interesting because of what verifiable history is doing to did:web. 00:34:43 ...You can put any data integrity proof on it. You can sign the entire DID document. 00:35:02 ...The controller of the document can use one of their keys to assert that the DID document is that and that it's digitally signed. 00:35:35 ...You can put a proof on it, and the data integrity spec is very clear about where you put the proof. 00:35:50 ...It's the DID method that needs to specify whether documents are signed or not. 00:36:23 ...did:webvh definitely has a cryptographic log that verifies the changes and you get a mini blockchain over the history of the DID document. 00:36:52 ...You can have one or more signatures. All of those details are in the did:webvh specification and it's clear how you are supposed to construct those. 00:37:35 ...Where DID Resolution comes into it is that you can have a flag in DID Resolution that says I require there to be a signature on the DID document or a cryptographic signature on the event log before returning the result to me. 00:37:56 ...You can, using a DID resolver, that you do not what any DID documents back that don't have any assurance on the DID or the history of the DID. 00:38:35 ...I think the result is that we could add a parameter that says "verify a signature" or "require cryptographic log verification". We should ask Markus what he wants to do here. 00:38:42 scribe- 00:38:59 ottomorac: so that's a DID resolution flag? 00:39:04 manu: Yes, I think so. 00:40:37 https://github.com/w3c/did-resolution/issues/111 00:40:52 subtopic: https://github.com/w3c/did-resolution/issues/111 00:40:59 q+ 00:41:02 ack manu 00:41:20 manu: I think we should just mark this ready for PR. 00:41:37 ...Can you call a DID resolver on your local machine, on localhost? The answer is yes, we should clarify that. 00:43:36 ottomorac: We could move on to DID Rubric/Traits next. 00:43:39 q+ 00:43:44 ack manu 00:44:14 manu: JC was wondering how we were going to integrate the DID traits stuff. 00:44:19 ...We should talk about that. 00:44:19 topic: Next Up: DID Traits and Rubric discusson 00:44:29 subtopic https://github.com/w3c/did-extensions/issues/619 00:44:40 s/subtopic /subtopic: / 00:45:00 q+ 00:46:15 ack manu 00:51:11 manu: Happy to have a discussion about DID Traits and Rubric... I do think we could integrate the traits into the DID Extensions quite easily by adding a 'traits' array with string identifiers for each trait and making it optional for DID Method registrants to fill that out by themselves. We can provide a table of trait identifiers to explanations about what the trait means. 00:52:09 ottomorac: Next week is IIW, so we won't have a call until April 17th. 00:55:16 rrsagent, make minutes 00:55:17 I have made the request to generate https://www.w3.org/2025/04/03-did-minutes.html ottomorac 00:55:33 m2gbot, link issues with transcript 00:55:33 Something wrong happened: Failed loading minutes from https://www.w3.org/2025/04/04-did-minutes.html 00:56:13 zakim, end the meeting 00:56:13 As of this point the attendees have been ottomorac, KevinDean, manu, denkeni, Jennie, TallTed 00:56:15 RRSAgent, please draft minutes 00:56:16 I have made the request to generate https://www.w3.org/2025/04/03-did-minutes.html Zakim 00:56:22 I am happy to have been of service, ottomorac; please remember to excuse RRSAgent. Goodbye 00:56:23 Zakim has left #did 00:58:43 m2gbot, link issues with transcript 00:58:44 Something wrong happened: Failed loading minutes from https://www.w3.org/2025/04/04-did-minutes.html