Meeting minutes
ottomorac: Reviews the agenda
… Any other topics to add
Horizontal Review Update
ottomorac: No major announcements, we have submitted the TAG issue for the DID resolution spec
IIW
ottomorac: manu has been working on threat modelling which we may discuss later
… On IIW, who will be there?
… A few folks are going to be out, do we still want to meet?
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.
… Would be great to have this talked about at IIW
dmitri: Happy to talk about DID URL derefencing at IIW
swcurran: Its a big PR, looking to get it in soon and have it go as smoothly as possible
Processing PRs
ottomorac: We will have a smaller group, but we will still hold a meeting to discuss some of the issues
w3c/did-resolution#192
ottomorac: This PR is related to changes regarding HTTP Get binding. Noting that Manu has highlighted some duplicates with another PR
<ottomorac> w3c/
ottomorac: PR 182, has the duplicate text
… Proposing removing the overlapping text from 182, to focus on the usage of TLS
manu: Sounds good to me
Dmitri: reminder that if we are going to require TLS, we need to make an exception for testing purposes in local setups
manu: Suggested language, we could say all production deployments must use TLS
… All production deployments that are exposed directly to the internet must use TLS. This would focus on the place that we really need TLS
… 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
markus_sabadello: Not sure I am up to date, but is the language now that all conformant DID Resolvers must implement HTTP binding?
ottomorac: The language is all conformant DID resolvers must use HTTPS binding with the GET as well as optionally supporting the POST
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
… It is just a local library executing a local transformation. It is still a conformant DID resolver
… There is no HTTPS binding
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
… Then a separate conformance class for local DID resolvers
… We need a conformance class that talks about libraries and one that talks about web based
… We should decide about web based or internet based
ottomorac: This shifts us to the other issue around conformance class
… Trying to think about the best way to handle this
… To avoid tangling these issues together
… the other issue is #213 w3c/
… I suggest we merge this for now and then have a disucssion around the conformance classes later
… Would this be okay
<manu> Wip: Don't like merging something that'll be wrong, especially if it has normative language in.
<manu> Wip: This PR will put in a MUST statement that says what Markus has concerns about.
<manu> ottomorac: Maybe you MUST if you are working over network and other specifics?
manu: Usually bad practice to merge in things that we know are wrong
… The thing to do would be to process the PRs in the opposite order.
… What are the conformance classes and the names of these classes. Lets decide that then address this PR after
ottomorac: Okay, makes sense
Complete threat modelling analysis for different DID Resolution architectures #132
<ottomorac> w3c/
ottomorac: Next issue about threat modelling analysis
<ottomorac> 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.
ottomorac: We need to decide as a group what we are going to about the threat modelling for DID resolution
manu:
manu: I was not intending to do this threat modelling work
… Just playing around and exploring, so we can get something to Simone fairly quickly that is a starting place
… 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.
… Then I asked it to generate a threat model. It produced this document almost perfectly
… It is decent, has no errors but needs thorough review
… This is a decent summary and starting place
… There are some downsides. But it managed to produce correct ReSpec. That is a good success.
… It also has in its memory, all of the specs we have published as Recs
… It integrated other writing in blogs etc. Also it used Stride and other frameworks
… It managed to create its own diagrams, with boundaries, storage, processes
… Everything was labelled
… It listed out all components, threat boundaries in tables
… It identified entities, processes, data flows relevant to the DID ecosystem
… Then reviewed architectural considerations and the threats
… 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
… It has attacks and responses for a given threat. and identifies the analysis frameworks that it used
ottomorac: Which model was used?
manu: All of the models. Primarily Claude Sonnet 4.5
… Used different models to spot check the outputs
TallTed: I heard you mention about color coding. Accessibility will have concerns if we use Color coding for anything
… Different fill pattern and gradations make a different
<pchampin> +1, I was about to mention that
JoeAndrieu: Yeah, so manu this is very interesting work. Would love to see the prompts that produced this
… Not a big fan of this. As you described. LLMs talk reasonably and are convincing, but then you have to think deeply to evaluate
… 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
… We have quite a bit of work to do to understand what threats are relevant
… 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
… It is cognitively dangerous to have too many threats
… 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
<Zakim> swcurran, you wanted to ask about the prompt
JoeAndrieu: I will take this as a starting point and provide feedback
swcurran: I was also interesting in the prompts around how this was created
… I am going to say a similar thing with Joe, but on a more positive side
… 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
ottomorac: Not meaning to put you on the spot manu, just wanted to share with the group
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
… Agree, we need to refine and delete things that make this unreadable
… I did not have it read the DID resolution spec, because I did not feel it was complete enough
… 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
… It can be verbose and distracting
… 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
… Happy to get rid of the entire document and start again
… There could be ~100 prompts that generated this. A lot of dead ends
… 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
… For example, we could provide the constraints and threats we cared about.
… +1, I was pleasantly suprised by this output. This feels like a big improvement on what it has previously been able to do
… 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
… This was an experiment. I found it useful
ottomorac: This is using research mode?
manu: It was all over the map. Many prompts to produce and refine
… I will try to share the most useful prompts
Wip: What does the group think of the work of doing the threat model?
Wip: perhaps we do the work in smaller group?
swcurran: to clarify, one person to go through the LLM content. Then a smaller group could work on this
swcurran: I think that would be time well spent to decide if we throw it away, or keep it and iterate
ottomorac: So evaluate what we have for DID core, then decide if we do something similar
… for DID resolution
<Zakim> manu, you wanted to contradict what he just said :P
ottomorac: We just need some more time
manu: Now I feel bad, because I have created work for Joe
… Not the intent to do this
… I was concerned that we were not going to do the work at all
… I think we have higher priorities at the moment. Like just getting DID resolution done
… I wanted to send a signal to Simone, that we don't have the bandwidth
… This was an attemt to see if there was some way to get something done
… I dont want to put work on for Joe.
JoeAndrieu: This is an interesting experiment.
… Not too worried about the extra work
… This is something that we can move forwards, I need to dive into this
… I do think this is very similar for the threat modelling for DID resolution
<Zakim> manu, you wanted to volunteer to at least get the prompts for Joe/the group.
JoeAndrieu: Not too worried that this is more work. I think it will be useful
manu: I appreciate that JoeAndrieu
… I will share the prompts with you and the group
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?
<swcurran> +1 to Manu -- 1 threat model
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
… I did not include DID resolution, because I did not want to include unfinished work
… Would be easy to add it in
… 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
DID Resolution Issue Processing
ottomorac: Okay, moving on
w3c/did-resolution#212
ottomorac: This is related to standardising error responses
<ottomorac> PR updates the OpenAPI specification to provide a consistent error response structure, related to issue 212: w3c/
ottomorac: Markus has responded and suggested discussion this in the group
<ottomorac> w3c/
manu: We are dealing with this in the VCALM group
manu: We have standardised on problem details as the error object
… I think it is a good idea. We should standardize on this. We want to use problem details across the VC and DID ecosystem
… This has worked really well across implementations
… I am not sure what the current mechanism we are using
… We might want to define this more generally across W3C specs, but dont need to do that yet
markus_sabadello: We have already adopted the problem details in DID resolution
… 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
… Or do we return only the problem details
manu: Thats great, its a good question. In the VCAPI group the verify credential call returns the verified credential
… We also had a concept of returning warnings and errors
… There are times when you might want to return warnings and results
… E.g. we had to use a cache beyond the timeout
… The result would include multiple things. The result. A set of warnings. A set of errors
… I am not sure if this applies for the DID resolver
markus_sabadello: I agree with all that. There are situations when you might return a DID document along with some problems
… The PR says, that in case of an error they will return just the problems
… I will respond on the issue and summarise the pros and cons we just discussed
w3c/did-resolution#203
ottomorac: This is related to the timestamp format
<ottomorac> We have a response back from Addison Phillips indicating that there is no normative reference for the date format.
Wip: I was confused about this.
Wip: Do we just reference the VCDM?
<manu> https://
manu: I think the best we could do is reference the VCDM, while being explict that we are not dependent of VCDM at all
… This is not as simple as we think it is. So we should address this
… Adding this to Infra is going to take a long time
… This is a part of WHATWG I think
… Getting this into infra would be a challenge
… I suggest we just depend on the minimal section of VCDM for now
… Deal with getting it into infra later
ottomorac: Is it a should or a must
manu: There is a MUST statement, so it would be a MUST pointing to the time representation in the VCDM