14:52:31 RRSAgent has joined #did 14:52:35 logging to https://www.w3.org/2025/10/16-did-irc 14:52:38 rrsagent, make logs public 14:52:47 Meeting: Decentralized Identifier Working Group 14:52:57 Chair: ottomorac 14:53:16 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Oct/0005.html 15:00:47 Wip has joined #did 15:01:18 KevinDean has joined #did 15:01:22 present+ 15:01:29 swcurran has joined #did 15:01:34 present+ 15:01:44 present+ 15:01:54 present+ 15:02:51 JoeAndrieu has joined #did 15:03:35 scribe+ 15:04:27 present+ 15:04:57 ottomorac: Reviews the agenda 15:05:02 ... Any other topics to add 15:05:11 Topic: Horizontal Review Update 15:05:38 ottomorac: No major announcements, we have submitted the TAG issue for the DID resolution spec 15:05:52 Topic: IIW 15:05:53 ... manu has been working on threat modelling which we may discuss later 15:06:17 ... On IIW, who will be there? 15:06:29 q+ 15:06:34 ... A few folks are going to be out, do we still want to meet? 15:06:41 ack swcurran 15:07:14 swcurran: I am working on a PR related to DID URL dereferencing, have reviewed it with a few folks privately. I hope to have it by the end of the week. 15:07:28 ... Would be great to have this talked about at IIW 15:07:49 dmitri: Happy to talk about DID URL derefencing at IIW 15:07:54 q? 15:08:10 swcurran: Its a big PR, looking to get it in soon and have it go as smoothly as possible 15:08:32 Topic: Processing PRs 15:08:34 ottomorac: We will have a smaller group, but we will still hold a meeting to discuss some of the issues 15:08:48 subtopic: https://github.com/w3c/did-resolution/pull/192 15:09:06 markus_sabadello has joined #did 15:09:09 present+ 15:09:20 ottomorac: This PR is related to changes regarding HTTP Get binding. Noting that Manu has highlighted some duplicates with another PR 15:09:26 https://github.com/w3c/did-resolution/pull/182 15:09:29 ... PR 182, has the duplicate text 15:09:51 ... Proposing removing the overlapping text from 182, to focus on the usage of TLS 15:10:03 manu: Sounds good to me 15:10:40 q+ 15:10:41 q+ 15:10:58 Dmitri: reminder that if we are going to require TLS, we need to make an exception for testing purposes in local setups 15:11:04 ack manu 15:11:21 manu: Suggested language, we could say all production deployments must use TLS 15:11:50 ... All production deployments that are exposed directly to the internet must use TLS. This would focus on the place that we really need TLS 15:12:26 ... Production deployments that are directly exposed to the internet MUST use TLS. And then explain that testing and proxy deployments do not need TLS for example 15:12:36 ack markus_sabadello 15:12:52 JennieM has joined #did 15:13:00 present+ 15:13:09 markus_sabadello: Not sure I am up to date, but is the language now that all conformant DID Resolvers must implement HTTP binding? 15:13:35 ottomorac: The language is all conformant DID resolvers must use HTTPS binding with the GET as well as optionally supporting the POST 15:13:40 q+ 15:14:00 markus_sabadello: To me this doesnt make much sense, a DID resolver that resolves a DID key locally as part of a simple library is also a DID resolver without needing HTTP 15:14:17 ... It is just a local library executing a local transformation. It is still a conformant DID resolver 15:14:26 ... There is no HTTPS binding 15:14:29 ack manu 15:15:07 manu: I agree with Markus. Wondering if we could use the language, all conforming web based DID resolvers. This is about the second conformance class we discussed last week 15:15:22 ... Then a separate conformance class for local DID resolvers 15:15:40 ... We need a conformance class that talks about libraries and one that talks about web based 15:15:50 ... We should decide about web based or internet based 15:16:01 present+ 15:16:21 ottomorac: This shifts us to the other issue around conformance class 15:16:36 ... Trying to think about the best way to handle this 15:16:48 ... To avoid tangling these issues together 15:17:23 ... the other issue is #213 https://github.com/w3c/did-resolution/issues/213 15:17:54 ... I suggest we merge this for now and then have a disucssion around the conformance classes later 15:17:59 ... Would this be okay 15:18:00 q+ 15:18:06 ack Wip 15:18:17 scribe+ 15:18:24 Wip: Don't like merging something that'll be wrong, especially if it has normative language in. 15:18:25 q+ 15:18:31 scribe- 15:18:50 Wip: This PR will put in a MUST statement that says what Markus has concerns about. 15:19:10 ack manu 15:19:12 ottomorac: Maybe you MUST if you are working over network and other specifics? 15:19:30 manu: Usually bad practice to merge in things that we know are wrong 15:19:42 ... The thing to do would be to process the PRs in the opposite order. 15:20:02 ... What are the conformance classes and the names of these classes. Lets decide that then address this PR after 15:20:13 ottomorac: Okay, makes sense 15:20:19 Topic: Complete threat modelling analysis for different DID Resolution architectures #132 15:20:19 q+ 15:20:24 q- 15:20:31 https://github.com/w3c/did-resolution/issues/132 15:20:39 ottomorac: Next issue about threat modelling analysis 15:20:42 Joe had mentioned this is not blocked by Simone's guidance, we have to first select the architectures, then model the threats. I know that Manu has also recently been experimenting with some LLM generated threat models. 15:21:29 q+ 15:21:32 ottomorac: We need to decide as a group what we are going to about the threat modelling for DID resolution 15:21:33 ack manu 15:21:34 manu: 15:22:03 manu: I was not intending to do this threat modelling work 15:22:25 ... Just playing around and exploring, so we can get something to Simone fairly quickly that is a starting place 15:22:57 ... I took the research mode for some of the LLMs, fed in ReSpec, DID Core, CID and some threat modelling work from Joe and Eric. 15:23:12 ... Then I asked it to generate a threat model. It produced this document almost perfectly 15:23:22 q+ 15:23:38 ... It is decent, has no errors but needs thorough review 15:23:48 ... This is a decent summary and starting place 15:24:10 ... There are some downsides. But it managed to produce correct ReSpec. That is a good success. 15:24:24 ... It also has in its memory, all of the specs we have published as Recs 15:24:52 present+ 15:24:59 ... It integrated other writing in blogs etc. Also it used Stride and other frameworks 15:25:18 ... It managed to create its own diagrams, with boundaries, storage, processes 15:25:24 ... Everything was labelled 15:25:47 ... It listed out all components, threat boundaries in tables 15:26:20 ... It identified entities, processes, data flows relevant to the DID ecosystem 15:26:37 ... Then reviewed architectural considerations and the threats 15:27:05 ... Some of the threats make no sense really. It requires humans to go in and really pay attention. LLM can be persuasive and still wrong 15:27:30 ... It has attacks and responses for a given threat. and identifies the analysis frameworks that it used 15:27:50 ottomorac: Which model was used? 15:28:01 manu: All of the models. Primarily Claude Sonnet 4.5 15:28:12 ... Used different models to spot check the outputs 15:28:13 q+ to ask about the prompt 15:28:46 TallTed: I heard you mention about color coding. Accessibility will have concerns if we use Color coding for anything 15:28:55 ... Different fill pattern and gradations make a different 15:28:57 q+ 15:29:00 +1, I was about to mention that 15:29:09 ack JoeAndrieu 15:29:34 JoeAndrieu: Yeah, so manu this is very interesting work. Would love to see the prompts that produced this 15:30:07 ... Not a big fan of this. As you described. LLMs talk reasonably and are convincing, but then you have to think deeply to evaluate 15:30:30 ... This document could be a distraction. We could spend a long time arguing about it. I think it is often better to start from scratch then bring in a LLM 15:30:42 ... We have quite a bit of work to do to understand what threats are relevant 15:31:15 ... The goal is not to have an exhaustive list of all the threats, but to curate a list of the most salient threats. Things that implementers should be considering when implementing the spec 15:31:24 ... It is cognitively dangerous to have too many threats 15:31:48 ... At one point in previous work we had 77 threats, we had to do a lot of work to reduce the threats to a more salient sety 15:31:56 ack swcurran 15:31:56 swcurran, you wanted to ask about the prompt 15:32:00 ... I will take this as a starting point and provide feedback 15:32:16 swcurran: I was also interesting in the prompts around how this was created 15:32:27 ... I am going to say a similar thing with Joe, but on a more positive side 15:33:10 ... I find having the structure and the data there very helpful. Hundred percent agree, this needs to be curated first. Having a broad group look at this document will be time consuming. Should have a small group first review this document 15:33:34 ack manu 15:33:38 ottomorac: Not meaning to put you on the spot manu, just wanted to share with the group 15:34:06 manu: +1 to everything that has been said. I don;t think we would ever push this out before a thorough review by people who understand this stuff 15:34:21 ... Agree, we need to refine and delete things that make this unreadable 15:34:36 ... I did not have it read the DID resolution spec, because I did not feel it was complete enough 15:35:07 ... Agree that the set of threats is too much. Needs thorough review. Do not want to overwhelm the humans with reams of LLM generated content 15:35:17 ... It can be verbose and distracting 15:35:39 ... What we are trying to do is create a document that a human can read through and get a good idea of what the threats are 15:35:48 ... Happy to get rid of the entire document and start again 15:36:04 ... There could be ~100 prompts that generated this. A lot of dead ends 15:36:34 ... Found that if you can start from a structured document, you get much better structured output than asking for it to invent something from scratch 15:36:51 ... For example, we could provide the constraints and threats we cared about. 15:37:25 ... +1, I was pleasantly suprised by this output. This feels like a big improvement on what it has previously been able to do 15:37:44 ... The goal was to help us generate these things in a useful way so we can address Simone's request to a threat model in a timely manner 15:37:58 ... This was an experiment. I found it useful 15:38:02 q+ 15:38:21 ottomorac: This is using research mode? 15:38:34 manu: It was all over the map. Many prompts to produce and refine 15:38:40 ack Wip 15:38:40 ... I will try to share the most useful prompts 15:38:44 scribe+ 15:39:01 https://github.com/w3c/did-resolution/issues/132 15:39:04 Wip: What does the group think of the work of doing the threat model? 15:39:21 q+ 15:39:27 Wip: perhaps we do the work in smaller group? 15:39:35 scribe- 15:39:39 ack swcurran 15:39:52 swcurran: to clarify, one person to go through the LLM content. Then a smaller group could work on this 15:40:19 swcurran: I think that would be time well spent to decide if we throw it away, or keep it and iterate 15:40:36 ottomorac: So evaluate what we have for DID core, then decide if we do something similar 15:40:39 q+ to contradict what he just said :P 15:40:41 ... for DID resolution 15:40:50 ack manu 15:40:50 manu, you wanted to contradict what he just said :P 15:40:53 ottomorac: We just need some more time 15:41:04 manu: Now I feel bad, because I have created work for Joe 15:41:08 ... Not the intent to do this 15:41:20 ... I was concerned that we were not going to do the work at all 15:41:32 ... I think we have higher priorities at the moment. Like just getting DID resolution done 15:41:46 ... I wanted to send a signal to Simone, that we don't have the bandwidth 15:42:02 ... This was an attemt to see if there was some way to get something done 15:42:11 ... I dont want to put work on for Joe. 15:42:22 q? 15:42:44 JoeAndrieu: This is an interesting experiment. 15:42:46 q+ 15:42:53 ... Not too worried about the extra work 15:43:02 q+ to volunteer to at least get the prompts for Joe/the group. 15:43:08 ... This is something that we can move forwards, I need to dive into this 15:43:13 q+ 15:43:26 ... I do think this is very similar for the threat modelling for DID resolution 15:43:40 ack manu 15:43:40 manu, you wanted to volunteer to at least get the prompts for Joe/the group. 15:43:41 ... Not too worried that this is more work. I think it will be useful 15:43:50 manu: I appreciate that JoeAndrieu 15:44:00 ... I will share the prompts with you and the group 15:44:11 ack Wip 15:44:15 scribe+ 15:44:32 q+ 15:44:47 Wip: Are we thinking that we are going to create separate threat model for DID core and for DID resolution? Do we want a single one for the DID ecosystem? 15:44:57 ack manu 15:45:46 +1 to Manu -- 1 threat model 15:45:53 manu: If it takes three hours to put together a threat model, not too concerned about that although it does add work for humans to review and understand. My intention was to model the enitre DID ecosystem 15:46:09 ... I did not include DID resolution, because I did not want to include unfinished work 15:46:22 ... Would be easy to add it in 15:46:42 ... A specific DID resolution threat model, would all us to focus specifically on threats relevant to that spec. E.g. if you are implementing a DID resolver 15:46:53 scribe- 15:47:05 Topic: DID Resolution Issue Processing 15:47:06 ottomorac: Okay, moving on 15:47:23 subtopic: https://github.com/w3c/did-resolution/issues/212 15:47:42 ottomorac: This is related to standardising error responses 15:47:42 PR updates the OpenAPI specification to provide a consistent error response structure, related to issue 212: https://github.com/w3c/did-resolution/issues/212 Markus had some comments on the proposed change. 15:48:03 q+ 15:48:13 ... Markus has responded and suggested discussion this in the group 15:48:18 https://github.com/w3c/did-resolution/pull/215 15:48:21 q+ markus_sabadello 15:48:23 ack manu 15:48:41 manu: We are dealing with this in the VCALM group 15:48:53 https://github.com/w3c-ccg/vcalm/blob/28f2a1a2cb71befeee9b5eb7ee48bb89e368232c/components/ProblemDetails.yml#L15 15:48:54 ... We have standardised on problem details as the error object 15:49:18 ... I think it is a good idea. We should standardize on this. We want to use problem details across the VC and DID ecosystem 15:49:27 ... This has worked really well across implementations 15:49:42 ... I am not sure what the current mechanism we are using 15:49:56 ack markus_sabadello 15:50:03 ... We might want to define this more generally across W3C specs, but dont need to do that yet 15:50:21 markus_sabadello: We have already adopted the problem details in DID resolution 15:50:35 q+ 15:50:49 ... This question is to do with if there is an error, do we return the DID resolution result containing the problem details in the metadata 15:50:55 ack manu 15:50:56 ... Or do we return only the problem details 15:51:31 manu: Thats great, its a good question. In the VCAPI group the verify credential call returns the verified credential 15:51:41 ... We also had a concept of returning warnings and errors 15:51:55 ... There are times when you might want to return warnings and results 15:52:08 ... E.g. we had to use a cache beyond the timeout 15:52:38 ... The result would include multiple things. The result. A set of warnings. A set of errors 15:53:15 ... I am not sure if this applies for the DID resolver 15:53:38 markus_sabadello: I agree with all that. There are situations when you might return a DID document along with some problems 15:53:53 ... The PR says, that in case of an error they will return just the problems 15:54:14 ... I will respond on the issue and summarise the pros and cons we just discussed 15:54:25 subtopic: https://github.com/w3c/did-resolution/issues/203 15:54:49 ottomorac: This is related to the timestamp format 15:54:52 We have a response back from Addison Phillips indicating that there is no normative reference for the date format. 15:55:17 q+ 15:55:22 ack Wip 15:55:27 scribe+ 15:55:48 Wip: I was confused about this. 15:55:57 q+ 15:56:07 Wip: Do we just reference the VCDM? 15:56:11 ack manu 15:56:41 https://w3c.github.io/vc-data-model/#representing-time 15:56:46 manu: I think the best we could do is reference the VCDM, while being explict that we are not dependent of VCDM at all 15:57:14 ... This is not as simple as we think it is. So we should address this 15:57:24 ... Adding this to Infra is going to take a long time 15:57:34 ... This is a part of WHATWG I think 15:57:53 ... Getting this into infra would be a challenge 15:58:06 ... I suggest we just depend on the minimal section of VCDM for now 15:58:21 ... Deal with getting it into infra later 15:58:36 ottomorac: Is it a should or a must 15:59:00 manu: There is a MUST statement, so it would be a MUST pointing to the time representation in the VCDM 15:59:08 q+ 15:59:15 ack Wip 16:01:41 brent has joined #did 16:03:10 zakim, end the meeting 16:03:10 As of this point the attendees have been KevinDean, swcurran, Wip, ottomorac, pchampin, markus_sabadello, JennieM, bigbluehat, JoeAndrieu 16:03:12 RRSAgent, please draft minutes 16:03:13 I have made the request to generate https://www.w3.org/2025/10/16-did-minutes.html Zakim 16:03:20 I am happy to have been of service, ottomorac; please remember to excuse RRSAgent. Goodbye 16:03:20 Zakim has left #did 16:04:23 rrsagent, make minutes 16:04:24 I have made the request to generate https://www.w3.org/2025/10/16-did-minutes.html ottomorac 16:04:47 m2gbot, link issues with transcript 16:04:48 comment created: https://github.com/w3c/did-resolution/pull/192#issuecomment-3411603461 16:04:52 comment created: https://github.com/w3c/did-resolution/issues/132#issuecomment-3411603531 16:04:52 comment already there: https://github.com/w3c/did-resolution/issues/132#issuecomment-3411603531 16:04:52 comment created: https://github.com/w3c/did-resolution/issues/212#issuecomment-3411603745 16:04:52 comment created: https://github.com/w3c/did-resolution/issues/203#issuecomment-3411603898 16:05:45 RRSAgent, please excuse us 16:05:45 I see no action items