15:43:57 <RRSAgent> RRSAgent has joined #did
15:44:02 <RRSAgent> logging to https://www.w3.org/2026/02/26-did-irc
15:44:11 <ottomorac> rrsagent, make logs public
15:44:20 <ottomorac> Meeting: Decentralized Identifier Working Group
15:44:23 <ottomorac> Chair: ottomorac
15:44:27 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Feb/0014.html
15:44:28 <agendabot> clear agenda
15:44:28 <agendabot> agenda+ Agenda Review, Introductions (5 min)
15:44:28 <agendabot> agenda+ DID Core Candidate Rec Update \[1\] (5 min)
15:44:28 <agendabot> agenda+ DID Path PR - Final Call \[2\] (10 min)
15:44:28 <agendabot> agenda+ DID Resolution Privacy Review \[3\] (10 min)
15:44:31 <agendabot> agenda+ DID Resolution Test Suite \[4\] (10 min)
15:44:33 <agendabot> agenda+ DID Resolution Threat Modelling Update \[5\] (15 min)
15:44:40 <ottomorac> previous meeting: https://www.w3.org/2026/02/19-did-minutes.html
15:44:44 <ottomorac> next meeting: https://www.w3.org/2026/03/05-did-minutes.html
15:56:25 <TallTed> TallTed has joined #did
16:00:30 <pchampin> present+
16:00:47 <KevinDean> KevinDean has joined #did
16:00:48 <JoeAndrieu> JoeAndrieu has joined #did
16:00:54 <KevinDean> present+
16:01:53 <TallTed> present+
16:01:56 <swcurran> swcurran has joined #did
16:02:01 <swcurran> present+
16:02:08 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/26-did-minutes.html TallTed
16:02:26 <Wip> Wip has joined #did
16:03:08 <bigbluehat> bigbluehat has joined #did
16:03:20 <dmitriz> dmitriz has joined #did
16:03:43 <bigbluehat> present+
16:03:46 <bigbluehat> scribe+
16:04:08 <bigbluehat> ottomorac: welcome everyone
16:04:16 <bigbluehat> ... we'll look at the update on DID Core
16:04:19 <bigbluehat> ... the DID path PR
16:04:29 <bigbluehat> ... and a few issues raised by someone at Mozilla
16:04:46 <bigbluehat> ... and then we can wrap with 15 minutes or so about threat modeling
16:04:51 <bigbluehat> ... anything else?
16:05:00 <ottomorac> zakim, next item
16:05:00 <Zakim> agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot]
16:05:09 <ottomorac> zakim, next item
16:05:09 <Zakim> agendum 1 was just opened, ottomorac
16:05:16 <manu> q+
16:05:21 <bigbluehat> ottomorac: the CR update
16:05:34 <ottomorac> ack manu
16:05:39 <ottomorac> zakim, next item
16:05:39 <Zakim> agendum 1 was just opened, ottomorac
16:05:43 <bigbluehat> manu: I made some changes to the status of the document section
16:05:52 <bigbluehat> ... and I could use some feedback
16:05:54 <pchampin> q+
16:06:04 <bigbluehat> ... we didn't point to a test suite link, but now we do
16:06:24 <bigbluehat> ... we warn implementers as class 1-3 might result in changes to the spec
16:06:39 <bigbluehat> ... we clearly highlight what we need in order to exit CR
16:07:02 <bigbluehat> ... for statements that are machine testable, there must be ___ implementations
16:07:27 <ottomorac> For CR criteria:
16:07:32 <ottomorac> there should be a test suite for DiD 1.1 (it's the case but not explicit).
16:07:33 <bigbluehat> ... we've heard that we'll need 2 producers and 2 consumers
16:07:34 <JennieM> JennieM has joined #did
16:07:36 <ottomorac> we'd like to see a dependency between DiD 1.1 and DiD Resolution, ie DiD 1.1 shouldn't move beyond CR if DiD Resolution isn't able to do the same as well.
16:07:41 <ottomorac> conforming implementation is defined using conforming producer and conforming consumer. At least, we'd like to see two consumers interoperating with one producer and two producers interoperating with one consumer.
16:07:43 <bigbluehat> ... which is different than the typical "2 implementers"
16:08:02 <bigbluehat> ... these are complaints from previous iterations and so I think the goal is to avoid that this time
16:08:10 <JennieM> present+
16:08:19 <ottomorac> q?
16:08:27 <bigbluehat> ... additionally there's pressure to make sure DID Resolution exits at the same time as DIDv1.1
16:08:32 <bigbluehat> ... which raises the bar a bit
16:08:53 <bigbluehat> ... there's also some boundary setting language about formats and resolution
16:09:05 <bigbluehat> ... but there have been no new comments on it--positive or negative
16:09:11 <bigbluehat> ... so I plan to merge it after the call
16:09:17 <bigbluehat> ... prepping the doc for publication
16:09:35 <bigbluehat> ... and PLH has approved it once his concerns have been addressed--which they are now
16:09:41 <ottomorac> ack pchampin
16:09:46 <ivan> present+
16:09:50 <bigbluehat> ottomorac: so the two specs are kinda joined at the hip now, correct
16:09:55 <bigbluehat> manu: yes, and that's new
16:10:14 <bigbluehat> pchampin: did you see that PLH +1'd the transition issue?
16:10:25 <bigbluehat> ... you can count him as approving the other PR also
16:10:29 <bigbluehat> ... so we're good to go
16:10:46 <bigbluehat> manu: excellent. I'll let you know when it's done
16:10:55 <pchampin> https://github.com/w3c/did/pull/921
16:11:03 <pchampin> https://github.com/w3c/transitions/issues/774
16:11:12 <ottomorac> zakim, next item
16:11:12 <Zakim> agendum 2 -- DID Core Candidate Rec Update \[1\] (5 min) -- taken up [from agendabot]
16:11:19 <ottomorac> zakim, next item
16:11:19 <Zakim> agendum 2 was just opened, ottomorac
16:11:30 <TallTed> Zakim, close item 2
16:11:30 <Zakim> agendum 2, DID Core Candidate Rec Update \[1\] (5 min), closed
16:11:31 <Zakim> I see 4 items remaining on the agenda; the next one is
16:11:31 <Zakim> 3. DID Path PR - Final Call \[2\] (10 min) [from agendabot]
16:11:36 <TallTed> Zakim, next item
16:11:36 <Zakim> agendum 3 -- DID Path PR - Final Call \[2\] (10 min) -- taken up [from agendabot]
16:11:48 <ottomorac> https://github.com/w3c/did-resolution/pull/260
16:11:52 <bigbluehat> ottomorac: next topic
16:11:59 <swcurran> q+
16:12:05 <bigbluehat> ... we are mostly done on this one, I think
16:12:15 <bigbluehat> swcurran: I had a great conversation with JoeAndrieu yesterday
16:12:20 <bigbluehat> ... I think we agree on the state of it
16:12:26 <bigbluehat> ... but language clarification would help
16:12:28 <ottomorac> ack swcurran
16:12:35 <bigbluehat> ... JoeAndrieu would like me to go through it one more time
16:12:44 <bigbluehat> ... and I think he was going to take a look at it lalso
16:12:51 <bigbluehat> s/lalso/also
16:13:14 <bigbluehat> ... our disagreements that remain seem separate from this PR at this point
16:13:28 <bigbluehat> ... so I plan to do one last pass to clean up anything that remains awkward or unclear
16:13:34 <bigbluehat> ... and thanks to TallTed for his help also
16:13:37 <ottomorac> q?
16:13:49 <ottomorac> zakim, next item
16:13:49 <Zakim> agendum 4 -- DID Resolution Privacy Review \[3\] (10 min) -- taken up [from agendabot]
16:13:53 <JoeAndrieu> +1 to Stephen's report out
16:14:19 <ottomorac> subtopic: https://github.com/w3c/did-resolution/issues/294
16:14:26 <ottomorac> HTTP Bindings could be more tightly specified #294
16:14:43 <bigbluehat> ottomorac: there are some suggested improvements hese
16:15:43 <ottomorac> scribe+
16:15:58 <Wip> q+
16:16:05 <ottomorac> ack Wip
16:16:16 <danpape> danpape has joined #did
16:16:39 <ottomorac> Wip: are we using http headers?
16:16:48 <manu> q+
16:16:49 <bigbluehat> q+
16:16:53 <ottomorac> ack manu
16:17:09 <ottomorac> Manu: I think he is saying we are vague about what layer we are trying to target....
16:17:37 <ottomorac> Manu:  so he is basically saying we are not clarifying caching and which headers are ok....
16:17:47 <bigbluehat> q-
16:17:48 <ottomorac> Manu: Also regarding the client and resolver trust relationship....
16:17:51 <smccown> smccown has joined #did
16:18:05 <ottomorac> Manu: He wants more clarity that
16:18:19 <JoeAndrieu> q+
16:18:54 <smccown> present+
16:18:55 <ottomorac> Manu: He is also asking about browser apis vs just pure http.... it sounds like you guys are using pure http... and then we need to clarify what changes we might make before raising PR
16:19:03 <ottomorac> q?
16:19:08 <ottomorac> ack JoeAndrieu
16:19:53 <bigbluehat> q+
16:19:54 <manu> q+
16:19:57 <ottomorac> JoeA:  We are not using HTTP headers in a meaningful way, we are only using https so we need to put some detail around that
16:20:01 <manu> scribe+
16:20:02 <ottomorac> ack bigbluehat
16:20:26 <ottomorac> bigbluehat: In the context of a privacy review he does want more detail about referer....
16:20:52 <ottomorac> bigbluehat:  I dont think he wants the whole expansion of http headers, perhaps a paragraph or two could suffice...
16:20:58 <manu> bigbluehat: In the context of a privacy review, he's looking for specific callouts that "void the warranty" on privacy -- origin cookies, things of that nature -- it is in the context of a privacy review. I don't think he's looking for a full expansion, and how we treat each one, perhaps something on privacy conscious clients and things that might explore those things.
16:21:01 <manu> q-
16:21:07 <ottomorac> q?
16:21:21 <ottomorac> q?
16:21:23 <Wip> q+
16:21:24 <manu> scribe-
16:21:27 <ottomorac> ack Wip
16:21:35 <bigbluehat> Wip: anyone want to take this on?
16:21:54 <bigbluehat> ... we have maybe 4 weeks
16:22:05 <bigbluehat> ... so it'd be great to have someone tackle it
16:22:28 <bigbluehat> bigbluehat: I'll do it
16:22:31 <bigbluehat> ottomorac: thanks!
16:22:44 <ottomorac> subtopic: https://github.com/w3c/did-resolution/issues/293
16:22:49 <bigbluehat> ottomorac: we have another one from the same reviewer
16:22:50 <ottomorac> Tracking of resolutions and dereferences by downstream entities from the resolver
16:23:49 <JoeAndrieu> q+ to say we it's likely out of scope
16:24:06 <ottomorac> ack JoeAndrieu
16:24:06 <Zakim> JoeAndrieu, you wanted to say we it's likely out of scope
16:24:31 <bigbluehat> JoeAndrieu: I appreciate the concern raised, but I think because of our security model that this is out of scope
16:24:38 <bigbluehat> ... essentially, the trust is in the resolver
16:24:46 <Wip> q+
16:25:04 <bigbluehat> ... I do think we need to be more clear about that
16:25:07 <ottomorac> ack Wip
16:25:16 <bigbluehat> ... otherwise, I don't know how to address this one
16:25:33 <TallTed> s/trust the resolver/rely on the resolver to keep secret information secret/
16:25:33 <TallTed> `trust` is a terrible word to use
16:25:42 <bigbluehat> Wip: my first read left me feeling like he's thinking primarily of Web-based resolvers
16:25:56 <ottomorac> q?
16:25:59 <bigbluehat> ... and this is privacy focused review again
16:26:07 <bigbluehat> q+
16:26:12 <ottomorac> scribe+
16:26:21 <bigbluehat> TallTed: trust is a terrible word
16:26:34 <bigbluehat> ... relying on the resolver to keep secret information secret would be better
16:27:12 <ottomorac> q?
16:27:19 <bigbluehat> q-
16:27:20 <JoeAndrieu> q+
16:27:44 <TallTed> s|s/trust the resolver/|<TallTed> instead of "trust the resolver",
16:27:46 <bigbluehat> manu: I need to look through again because I'd though we'd added stuff about OHTTP, etc.
16:27:54 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/26-did-minutes.html TallTed
16:28:00 <bigbluehat> ... I do agree we should write more in the privacy concern section
16:28:06 <bigbluehat> ... he mentions mentioning techniques
16:28:13 <bigbluehat> ... and OHTTP would be one
16:28:27 <bigbluehat> ... one our specs does do that...maybe VC Data Model?
16:28:30 <ottomorac> q?
16:28:41 <bigbluehat> Wip: we do say steps can be taken to obfuscate requests
16:28:51 <bigbluehat> manu: yeah, but we don't spell it out and point to options
16:28:56 <bigbluehat> ... which I think is what he wants
16:29:36 <manu> https://w3c.github.io/vc-bitstring-status-list/#validate-algorithm
16:29:42 <bigbluehat> manu: here it is
16:29:46 <manu> We say this: "Verifiers SHOULD cache the retrieved status list and SHOULD use proxies or other mechanisms, such as Oblivious HTTP, that hide retrieval behavior from the issuer."
16:30:03 <ottomorac> q?
16:30:07 <bigbluehat> ... we could say something like this in the DID Resolution privacy section
16:30:10 <ottomorac> ack JoeAndrieu
16:30:14 <bigbluehat> ... I think that's what he's after
16:30:23 <bigbluehat> JoeAndrieu: I agree we could improve the language
16:30:31 <bigbluehat> ... but I'm not sure caching should be here
16:30:37 <bigbluehat> s/be here/be there
16:30:49 <bigbluehat> ... it's not really part of our architecture
16:31:23 <bigbluehat> ... I think we should add that, again, one shouldn't ask a resolver for a DID unless there's some trust in what the resolver may do with that DID
16:31:32 <bigbluehat> ... I'm honestly not sure how the obfuscation helps
16:31:32 <ottomorac> q?
16:31:32 <bigbluehat> q+
16:31:33 <manu> q+
16:31:40 <ottomorac> scribe+
16:31:46 <ottomorac> ack bigbluehat
16:31:55 <ottomorac> bigbluehat: the question is who are you being private from?
16:32:05 <ottomorac> bigbluehat:  http will only mask so much...
16:32:46 <ottomorac> bigbluehat: as Joe said we need to clarify what level of trust is expected
16:32:50 <bigbluehat> ottomorac: so, maybe we're clarifying what level of trust is being expected?
16:33:01 <bigbluehat> JoeAndrieu: TallTed's right. We should avoid saying trust
16:33:06 <bigbluehat> ... it is more about reliance
16:33:17 <bigbluehat> ... the protocol may need you to talk to a central server
16:33:24 <bigbluehat> ... as sad as that makes me, it's possible
16:33:29 <bigbluehat> ... and that may leak PII
16:33:35 <ottomorac> q?
16:33:51 <bigbluehat> ... and the fact that the resolver can do all that stuff is just part of the pioneering part of this ecosystem
16:34:08 <bigbluehat> ottomorac: and I guess the concern here is that the resolver may not work on behalf of the user?
16:34:22 <bigbluehat> JoeAndrieu: it's just like browser choice
16:34:22 <ottomorac> ack manu
16:34:54 <bigbluehat> manu: so, the reviewer is coming from a browser vendor
16:35:08 <bigbluehat> ... and browsers do try to mask certain requests through things like caching
16:35:26 <bigbluehat> ... to really know something, you do have to GET the newest thing
16:35:33 <bigbluehat> ... but what if you do it 10 seconds later?
16:35:40 <JoeAndrieu> q+ caching is a thing that people will do. We don't have a secure way to do that.
16:35:45 <JoeAndrieu> q+ to say caching is a thing that people will do. We don't have a secure way to do that.
16:35:56 <ottomorac> zakim, close the queue
16:35:56 <Zakim> ok, ottomorac, the speaker queue is closed
16:36:01 <bigbluehat> ... one thing that caching does do is mask how many requests are being made which can help obfuscate usage patterns
16:36:09 <bigbluehat> ... OHTTP can help by masking who's asking
16:36:26 <bigbluehat> ... that plus caching can be helpful for further obfuscation
16:36:39 <bigbluehat> ... so I don't think it's quite the same as choosing a browser
16:36:48 <bigbluehat> ... I do think there are places where this stuff matters
16:36:52 <bigbluehat> q?
16:36:58 <ottomorac> ack JoeAndrieu
16:36:58 <Zakim> JoeAndrieu, you wanted to say caching is a thing that people will do. We don't have a secure way to do that.
16:37:30 <bigbluehat>  JoeAndrieu: if we're talking about making OHTTP optional, I think  that's fine
16:37:38 <KevinDean> q+
16:37:40 <manu> q+
16:37:42 <bigbluehat> ... making it mandatory would be a mistake
16:37:50 <bigbluehat> ... I think encouraging caching would also be a mistake
16:37:56 <bigbluehat> ... because it's not actually resolution
16:38:00 <KevinDean> What to cache and for how long is a business decision based on the use case.
16:38:11 <bigbluehat> ... and if we encouraged that, we'd be doing a disservice to the client
16:38:24 <ottomorac> zakim, next item
16:38:24 <Zakim> agendum 5 -- DID Resolution Test Suite \[4\] (10 min) -- taken up [from agendabot]
16:38:26 <manu> hmm, "stay silent on caching" feels like sticking our heads in the sand -- people will do it, fine to warn, but think it's a mistake to not talk about it as a privacy concern.
16:38:29 <bigbluehat> ottomorac: k. I want us to move on. Let's let this on simmer
16:38:39 <bigbluehat> Wip: I'm taking the lead on the test suite
16:38:44 <Wip> https://github.com/w3c-ccg/did-resolution-mocha-test-suite/pulls
16:38:46 <manu> q+
16:38:56 <bigbluehat> ... there is an open PR on this repo which has a pretty solid base
16:39:09 <bigbluehat> ... not sure who's implementing, but I'd love to hear from folks who are
16:39:17 <bigbluehat> ... I've implemented resolution locally
16:39:21 <bigbluehat> ... but it's not live
16:39:28 <bigbluehat> ... so not sure how we want to do that
16:39:43 <bigbluehat> ... if you have a library, just plug it in locally
16:40:00 <bigbluehat> ... there are some tests that are still unstable
16:40:10 <bigbluehat> ... but many of these feel complete
16:40:14 <ottomorac> q?
16:40:18 <ottomorac> ack manu
16:40:51 <bigbluehat> manu: glad to see we have 2 implementations!
16:40:55 <bigbluehat> ... this PR looks good to me
16:41:05 <bigbluehat> ... I'd say we make this the new base
16:41:15 <ottomorac> scribe+
16:41:17 <bigbluehat> ... and I don't think the WG really needs to give it a deep review yet
16:41:31 <ottomorac> q?
16:41:33 <manu> q+
16:41:37 <ottomorac> ack manu
16:42:00 <ottomorac> manu: on the local implementation vs remote, when we do what we did for did-core we already paid the price for longterm....
16:42:23 <ottomorac> manu:  some people just want to up a simplified docker instance and try to call it a resolver...
16:42:49 <Wip> q+
16:42:59 <ottomorac> manu: I don;t want us to put it in the effort and then people abandon those resolvers...
16:43:11 <bigbluehat> q+
16:43:24 <ottomorac> manu: I would rather help you out
16:43:47 <ottomorac> ack Wip
16:44:03 <ottomorac> Wip: yes thats fine, what I meant is i DO have an https wrapper...
16:44:23 <ottomorac> Wip:  last thing, swcurran do you have a resolver implementation?
16:44:23 <bigbluehat> q-
16:44:43 <ottomorac> swcurran: I think so, but let me take a look at what you did
16:44:44 <bigbluehat> swcurran: the DID webvh meeting is soon. I need to do a bit more work
16:44:52 <ottomorac> q?
16:45:02 <ottomorac> scribe-
16:45:17 <ottomorac> zakim, next item
16:45:17 <Zakim> agendum 6 -- DID Resolution Threat Modelling Update \[5\] (15 min) -- taken up [from agendabot]
16:45:45 <bigbluehat> ottomorac: so, JoeAndrieu I think you've been tackling these
16:45:59 <bigbluehat> JoeAndrieu: we've made some adjustments to the diagrams
16:46:12 <bigbluehat> ... one thing to share is that I went over this with swcurran
16:46:18 <bigbluehat> ... mostly to focus on the path PR
16:46:35 <bigbluehat> ... some of this was tangled up in resolution vs. dereferencing
16:47:01 <bigbluehat> ... these clarifications should allow me to clean some stuff up this weekend
16:47:55 <bigbluehat> ... I've walked through the diagram with various methods, etc.
16:48:04 <bigbluehat> ... and each time I've gone through it, it's gotten "richer"
16:48:47 <bigbluehat> ... the goal here is that each component in the diagram is shared across each of the flow diagrams
16:49:12 <bigbluehat> ... so, for example, when one is offline, there are fewer components, etc.
16:49:32 <bigbluehat> ... as I think through this for my personal situation, I'm the client admin for example
16:49:53 <bigbluehat> ... but in a larger organization, that may be a completely different person in a different part of the organization
16:50:01 <bigbluehat> ... swcurran is hopefully going to do this one for webvh
16:50:16 <ottomorac> q?
16:50:22 <bigbluehat> ... I'm hopeful that these diagrams will give us things to point at when reviewing methods
16:50:44 <bigbluehat> ... like my disdain for DNS in did:webvh presents as a particular threat in the modeling
16:51:00 <bigbluehat> ... so we can point at those and discuss them more accurately and narrowly in future
16:51:14 <bigbluehat> ... there is more work to do here on extensibility
16:51:27 <bigbluehat> ... and think about where those introduce threats
16:51:45 <bigbluehat> ... for example, when we get into DID Core and start talking about verification methods
16:52:01 <bigbluehat> JoeAndrieu: swcurran and I are setup to do regular meetings
16:52:08 <ottomorac> q?
16:52:12 <manu> q+
16:52:16 <ottomorac> ack manu
16:52:17 <bigbluehat> ... I could talk through some of these threats now, if we want
16:52:33 <bigbluehat> manu: this might derail us... All of this made good sense, JoeAndrieu
16:52:50 <bigbluehat> ... however, I am concerned about other people being able to do this same sort of work being done here
16:53:12 <bigbluehat> ... is there a way to productionize this work, basically
16:53:19 <bigbluehat> ottomorac: are we saying other spec writers?
16:53:23 <bigbluehat> manu: all of them
16:53:24 <JoeAndrieu> q+
16:53:29 <bigbluehat> ... we don't want a bottleneck here
16:53:42 <bigbluehat> ... for example, we don't all have access to the diagramming tool
16:53:47 <bigbluehat> ... so could we use Mermaid?
16:53:54 <ottomorac> ack JoeAndrieu
16:54:04 <bigbluehat> ... we don't have to solve any of this right now, but I do want to highlight the concern
16:54:20 <bigbluehat> JoeAndrieu: the threat modeling guide actually already speaks to this
16:54:32 <bigbluehat> ... it's not tool or even diagramming approach specific
16:54:39 <bigbluehat> ... the output just needs to be accessible
16:55:00 <bigbluehat> ... I think the threat modeling is the solution, not the creator of the problem
16:55:12 <bigbluehat> ... software developers don't really have training in any of this
16:55:29 <manu> q+
16:55:29 <bigbluehat> ... and we've been abdicating to SING...and they are eternally backlogged
16:55:32 <ottomorac> q+
16:55:36 <ottomorac> ack manu
16:55:46 <bigbluehat> ... so the hope is that training all of us in threat modeling will alleviate that a bit
16:55:59 <bigbluehat> manu: sorry, that wasn't what I was trying to convey
16:56:07 <JoeAndrieu> q+
16:56:18 <bigbluehat> ... mostly, I'm after "where's the respec for threat modeling" sort of questions
16:56:24 <ottomorac> ack JoeAndrieu
16:56:25 <bigbluehat> JoeAndrieu: just ask. We have plans for these things
16:56:33 <bigbluehat> ... we're trying to JSON-ify these things
16:56:40 <bigbluehat> ... and WGs can model threat models in JSON
16:56:50 <bigbluehat> ... and then a respec plugin will render them
16:57:00 <bigbluehat> ... we do have a threat modeling spec in respec
16:57:02 <ottomorac> q?
16:57:07 <bigbluehat> ... it's not JSON-ified yet
16:57:09 <ottomorac> ack ottomorac
16:57:19 <bigbluehat> manu: thank you. that's actually what I was looking for
16:57:32 <bigbluehat> ottomorac: specifically on some of there charts
16:57:37 <JoeAndrieu> q+
16:57:40 <bigbluehat> ... are you expecting everyone to make these?
16:57:46 <bigbluehat> ... like at least DID Method authors?
16:57:48 <ottomorac> ack JoeAndrieu
16:57:50 <bigbluehat> JoeAndrieu: yes. that's the goal
16:57:56 <bigbluehat> ... really anyone could do a threat model
16:58:02 <bigbluehat> ... we state this in the guide
16:58:07 <ottomorac> zakim close the queue
16:58:16 <bigbluehat> ... we have a weird thing with the high extensibility of DID methods
16:58:20 <ottomorac> zakim, close the queue
16:58:20 <Zakim> ok, ottomorac, the speaker queue is closed
16:58:28 <bigbluehat> ... but we expect that people will use this as foundations in their own work
16:58:45 <bigbluehat> ... for example, we don't say anything about key management
16:59:00 <bigbluehat> ... but the hope is that each group would express how they're doing it via a threat model
16:59:07 <bigbluehat> ottomorac: k. let's come back in a few weeks
16:59:10 <bigbluehat> JoeAndrieu: sounds good!
16:59:16 <bigbluehat> ottomorac: thanks everyone
17:00:56 <ottomorac> rrsagent, make minutes
17:00:58 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/26-did-minutes.html ottomorac
17:02:09 <ottomorac> m2gbot, link issues with transcript
17:02:09 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/260#issuecomment-3967923903
17:02:10 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/294#issuecomment-3967924011
17:02:11 <m2gbot> comment already there: https://github.com/w3c/did-resolution/issues/294#issuecomment-3967924011
17:02:12 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/293#issuecomment-3967924251
17:02:45 <ottomorac> zakim, please excuse us
17:02:45 <Zakim> leaving.  As of this point the attendees have been pchampin, KevinDean, TallTed, swcurran, bigbluehat, JennieM, ivan, smccown
17:02:45 <Zakim> Zakim has left #did
17:03:02 <ottomorac> RRSAgent, please excuse us
17:03:02 <RRSAgent> I see no action items