Meeting minutes
Agenda Review, Introductions (5 min)
ottomorac: welcome. thanks for everyone's support as we drive to CR
… Today we have the security review and threat modeling conversation.
… We are going to go over items in DID core
… DID Resolution
… The core of the call with be about the DID path conversation and try to get to more alignment
… Any additions or items for the agenda?
manu: updates re going into CR
ottomorac: let's take that on first
updates re going into CR
manu: we resolved to take did core into CR around november.
… and our last text was "after the horizontal reviews are complete"
… and that is preventing us from going to CR
… We've pinged them, but there are two outstanding: accessibility and security
… Accessibility has been non-responsive
… 2. Simone has pinged Tomasso about moving into CR and addressing issues then
… We're waiting for a response
… The hope is that we publish CR as soon as we can.
ottomorac: good update. Any reactions?
manu: I need guidance from the group.
… Are we cleared to proceed as soon as Tomasso replies
ottomorac: Is no response an implicit green light?
pchampin: I'll check with the team about calling a timeout with Accessibillity
<Wip> +1 makes sense to me
pchampin: if we also have a green light from the security group, we're good to go
KevinDean: is there any escalation process to get groups to respond?
pchampin: nothing formally defined
… Security is a bit more of a problem with DIDs, but they've been more responsive
JoeAndrieu: Note reviews are done be volunteers generally. So sometimes hard to get a response
<manu> Here's the latest from security: w3c/
KevinDean: Understood, true of many standards orgs
manu: Simone knows we are waiting on it. He asked Tomasso last week. If this goes beyond this weekend, I'll reach out.
Security Review - Initial Threat Modelling (10 min)
ottomorac: so that gets us into our next item
<Wip> w3c/
wip: the did resolution
… There is a security request.
… what Simone suggested we join the security interest group call
… we through out some dates
… Are people able to attend the call at 7am pacific, maybe targeting the 3rd
I can make that
manu: it has a bunch of stuff. it's not complete (local resolver stuff)
… it has 25 threats, like private key compromise
<TallTed> Straw documents are good things to get from LLMs. Easier to poke holes in, and to fill in, than a blank page.
manu: I did read through the vast majority of all of it, so it seems not crazy
<Zakim> JoeAndrieu, you wanted to say we should also queue up our own special topic calls and to talk against using LLMs for threat modeling
JoeAndrieu: couple of things, first manu I think you conflated the DID resolution issue with the DID core spec
… I also wanted to speak against in general using LLMs for this work. The important step is doing the thinking, not just producing a document
… I feel like this work from manu is undermining some of the work I thought I was taking on
… I do not think LLMs are capable of doing a first principles, security first analysis of the threats in the ecosystem
KevinDean: +1 to Joe
… we need to remember that LLMs are conversational agents that can only create based on what's gone before
… Our work is touch on things that LLMs just don't have in scope
… We're going to get something that looks like a threat model, but it won't quite be
manu: did resolution v core.
… my expectation is that we'll create a threat model that is all inclusive
… It would probably be good to do a holistic threat model
… On the use of LLMs, Kevin, have you read the document
joe: yes
manu: I'm not saying we shouldn't have humans look at this
… I'm saying that we should have humans produce this using the tools that are most effecient
… When used by humans it's been shown to be useful
JoeAndrieu: not necessarily
manu: the time is not that great. so we just don't have the time to do it.
… I don't know what others experiences are.
… They have gotten to the point where they are doing a pretty good job.
… I think it is a mistake to dismiss them
… If the people doing the work, don't want to, that's their choice
wip: A few things here. I hear what manu is saying. We have limited time.
… The security group is asking us to do this work.
… I also feel the LLMs are creating leverage
… But joe's point about having the conversation is important.
… Maybe after we identify the threats (in our conversation), we can use LLMs to expand it
… Do the thinking first, then use LLM
… Joe, you mentioned some special topics
swcurran: I support the use of LLMs in certain circumstances
… Manu's statement, that I haven't read the whole thing
… that's a problem
… LLMs aren't an eliminator, but what came across was I put this forward, I'm not going to stand behind it.
manu: I do stand behind it
swcurran: as long as you do, I'm ok with it
KevinDean: + 1/2 to manu, +1/2 to joe
… LLM can provide a good starting point
<Zakim> JoeAndrieu, you wanted to talk about the constellation approach to threat modeling
JoeAndrieu: One thing more logistic, about the structure of the docs...
… we should echo that every spec for the web depends on many other specs. But the threat analysis is dependent and depends on a "constelation of other specs"
… The DID spec should clearly point of the potential issues it has in relation with those other specs...
… there should be a diagram that points out those potential areas of security concern
… acknowledge that this is tricky, I think perhaps the group should have some special topic calls for these
… the diagram lays out the concern areas and helps us think through the potential issues
… some areas missing in the diagram are the did-architectures here
DID Core PR Processing \[2\] (10 min)
manu: Ok. there's enough push back to withdraw the proposal
ottomorac: moving to some PRs
w3c/did#915
Clarify DID document term definition throughout spec #915
ottomorac: we'd appreciate reviews
wip: This has two reviews, but if you care about how we describe a DID document, please chime in
<JoeAndrieu> +1 on that change
w3c/did#916
ottomorac: Manu can you give us a summary
manu: This one is a request from PING to detail considerations for change notification text
manu: this is about VDRs, with a DID in it, how do you let people know about that
manu: PING thinks this matters. Talk about what you need to do to harden that surface
<Zakim> JoeAndrieu, you wanted to ask why we have change notification
JoeAndrieu: I think we should get this section out of the spec...
<swcurran> +1 to Joe
JoeAndrieu: I think we should not be speaking to this in spec
manu: I'm fine with doing that as well. This text came from the early days.
… This talked as if this is a regular thing, but it isn't really.
… It confused the reviewers. Since we haven't done the analysis, we should probably stay quiet
DID Resolution PR Processing \[3\] (10 min)
ottomorac: moving us to another PR
manu: anyone object to removing the section on did notification
… not seeing any objections
ottomorac: thanks
w3c/did-resolution#271
Rename Read to Resolve and clarify introduction #271 by WillSome feedback has been provided by Markus.
wip: this is on issue 230.
<Wip> w3c/
wip: I took a stab at fixing that.
… basically now I've renamed "read" to "resolve" throughout.
… And i added a section that clarifies the Resolution spec is defining an API on top of the resolution methods defined by the methods themselves
… Those two things.
… I was initially more in Marcus's camp: distinguishing between the call to the resolver and the process the method defines
… but now I think it's find to use the same term
<swcurran> +1 to the PR
<JoeAndrieu> +1 to me reviewing it
(it's probably good, but hard to scan while scribing)
manu: No objections to using resolution instead of read
<Wip> https://
manu: are there any changes to DID core we need?
wip: we don't really define the names of the operations, so the text is probably fine. because we don't talk about "read" at all
manu: so DID core is good
… Maybe our registration process should change
wip: agreed. that says "read"
… I'm hearing no objections. If you can take a pass and review, that'd be appreciated.
DID Path Discussion \[4\] (20 min)
ottomorac: thanks. 260 is next
swcurran: based on the conversation that's going on, I've applied the changes discussed last week
… and that markus revised
… instead of introducing a new parameter, use relativeRef as is, for any query components to be appended to the service endpoint path handler
… and to remove the reference about returning the resource
<swcurran> Update comment : w3c/
swcurran: The relative reference, from RFC3986, it looks like path component MUST be required.
swcurran: something about path
… if the service endpoint defines itself as a query parameter, we can't simply append, as that creates a non-standard URL
… The result is just a URL, that's what the resolver returns.
… That's another thing that's returned from resolution
… lists a bunch of things that can be returned
… we need clear boundaries on what the resolver returns and what the client is expected to do
… Please take a look at the commit
… I did revise the definition of relative ref
<Zakim> JoeAndrieu, you wanted to mention 3986 allows PathEmpty
<swcurran> https://
JoeAndrieu: on 3986, the path can be a path empty...
swcurran: Ah ok, yes it was kind of confusing
JoeAndrieu: Another question, the VCWG has moved to the WHATWG definition of URL for good reasons
manu: Agree with what Joe and Markus have said. PathEmpty is allowed.
… the confusing thing in the ABNF is that slashes mean "or"
<swcurran> wow!
manu: WhatWG? Yes, I suggested that. I hate that spec, but everyone has moved over
… It is what browsers implement
… it closes out some corner cases and holes that 3986 has
… problem is it doesn't define ABNF, so we'd have to figure out how to update
<swcurran> I can add an issue on that and try a PR to fix -- separate PR.
manu: but all the specs are moving, we should consider it
<swcurran> Joe -- can you provide the reference to the new spec?
wip: For a DID URL dereferencing, currently the spec returns a content stream
swcurran: I though Markus said the only thing the resolver should return is the resulting URL and the client can do what they want
… I tend to agree, because that makes the resolver too complex.
… The client can figure out the next thing
… That gets into exactly the question of what exactly a DID resolver returns
JoeAndrieu: one the challenges is conflating De-referencing with Resolving
JoeAndrieu: I am a bit frustrated that we are returning things different from just did-resolution data
JoeAndrieu: I am concerned that might make it complex
swcurran: I'm concerned as well. This almost artificial difference between dereferencing and resolution.
… Resolving a DID as its defined is just the degenerate case of dereferencing a DID URL
… that said, there is value in having a consistent way to interpret paths
… so defining what happens with paths should be in the spec
… but if we're returning anything other than DID document, that complicates thing
… For example, we return an "altered" did doc and an array of endpoints
… let's lock that down
manu: Stephen, do you have enough to raise a PR
swcurran: I've raised a PR, but not enough feedback yet
… so what am I returning? Just a string that is more than a URL?
manu: yes, let's do that
swcurran: ok. that's what I have today. But what form? A JSON string?
manu: JSON, since there might be metadata to return
ottomorac: To be continued
swcurran: I'll update the PR after I check with a few folks
ottomorac: Ok. I'll ping you about time on the call next week.