15:56:07 <RRSAgent> RRSAgent has joined #did
15:56:11 <RRSAgent> logging to https://www.w3.org/2026/02/12-did-irc
15:56:13 <Wip> Meeting: Decentralized Identifier Working Group
15:56:15 <Wip> Chair: Wi[
15:56:24 <Wip> s/Wi[/Wip
15:56:34 <TallTed> TallTed has joined #did
15:56:36 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Feb/0006.html
15:56:36 <agendabot> clear agenda
15:56:36 <agendabot> agenda+ Agenda Review, Introductions (5 min)
15:56:36 <agendabot> agenda+ DID Resolution Issues \[1\] (20 min)
15:56:36 <agendabot> agenda+ DID Resolution Ready for PR \[2\] (5 min)
15:56:36 <agendabot> agenda+ DID Extensions question - How to handle PR 651 from Jonathan Rayback \[3\] (5 min)
15:56:39 <agendabot> agenda+ DID Resolution Threat Modelling (continuation) \[4\] (20 min)
15:56:43 <Wip> previous meeting: https://www.w3.org/2026/02/05-did-minutes.html
15:56:49 <Wip> next meeting: https://www.w3.org/2026/02/19-did-minutes.html
16:01:41 <ottomorac> ottomorac has joined #did
16:01:42 <Wip> present+
16:01:43 <swcurran> swcurran has joined #did
16:01:56 <ottomorac> present+
16:03:00 <KevinDean> KevinDean has joined #did
16:03:07 <KevinDean> present+
16:05:30 <KevinDean> scribe+
16:05:35 <Wip> zakim, next agendum
16:05:35 <Zakim> agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot]
16:05:46 <TallTed> present+
16:05:51 <manu> q+ to note DID v1.1 CR
16:06:03 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html TallTed
16:06:29 <Wip> ack manu
16:06:29 <Zakim> manu, you wanted to note DID v1.1 CR
16:06:47 <dmitriz> dmitriz has joined #did
16:06:53 <dmitriz> present+
16:06:54 <KevinDean> manu: I just want to make sure that DID v1.1 candidate recommendation is taken forward.
16:07:00 <KevinDean> wip: I think it's been a holiday this week.
16:07:16 <KevinDean> manu: That's going to be a problem to publish it on the schedule that we agreed to, which is the 19th.
16:07:20 <KevinDean> wip: I'll ping him.
16:07:47 <Wip> zakim, next agendum
16:07:47 <Zakim> agendum 2 -- DID Resolution Issues \[1\] (20 min) -- taken up [from agendabot]
16:08:04 <KevinDean> ...There's a few issues, not labelled.
16:08:06 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3Adiscuss
16:08:29 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/274
16:08:29 <KevinDean> ...Four to discuss. I'll probably jump around a little.
16:08:38 <JoeAndrieu> JoeAndrieu has joined #did
16:08:48 <KevinDean> ...This is from TAG review. It's pointing to a fuzzy statement we have in the spec around proofs.
16:09:22 <manu> q+
16:09:26 <KevinDean> ...In the DID document metadata and the DID resolution metadata we define this value called "proof" but one of our sentences makes it sound like not much of a proof, e.g., "this is only a proof if you trust the DID resolver".
16:10:14 <KevinDean> ...I looked at it, and I feel that proof in this context is more like a data integrity proof. The problem is both proof values in our spec are just placeholders for DID method developers to fill in and may not be very good in that respect.
16:10:20 <Wip> ack manu
16:10:27 <KevinDean> ...I don't feel that there's guidance about what we should do with the proof.
16:10:32 <JoeAndrieu> q+ to ask about implementations
16:10:48 <KevinDean> manu: The purpose of this is so that proxies can cache DID resolution results and you could do a lot more edge caching with this mechanism.
16:11:33 <KevinDean> ...There would be some resolver or set of resolvers that you trust out there, and you don't have to talk to them directly to get the results. Rather, you can talk to the caching layer, and the caching layer needs to talk to the upstream resolver e.g., only every five minutes.
16:12:13 <KevinDean> ...You need to trust the upstream resolver but we haven't defined this at all, so maybe we should delete the sentence until we refine it. I don't feel give where we are that we have time for it right now.
16:12:23 <Wip> ack JoeAndrieu
16:12:23 <Zakim> JoeAndrieu, you wanted to ask about implementations
16:12:39 <Wip> q+
16:13:01 <KevinDean> joeandrieu: I don't feel that caching is a legitimate use case. It's an echo of the proxy conversation. +1 to your proposal to remove it, and I don't think that we have any implementations that do this.
16:13:10 <Wip> ack Wip
16:13:18 <KevinDean> ...We should start to figure out what the use cases are so we can update the spec.
16:14:15 <JoeAndrieu> q+ to say the immediate proof is from TLS
16:14:22 <KevinDean> wip: The simple solution is to delete this sentence, but it points to a bigger problem that the whole proof property is a little questionable. It took me some time to realize that this proof property referred to a data integrity proof. I think the proof in the DID document metadata is more of a proof in that you could provide e.g., all the
16:14:22 <KevinDean> transactions in Bitcoin that lead to this document.
16:14:24 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html TallTed
16:14:30 <JennieM> JennieM has joined #did
16:14:30 <JennieM> present+
16:14:41 <ottomorac> q+
16:14:42 <KevinDean> ...I don't know what we're trying to gain by saving this proof name in the metadata without telling anyone how to use it.
16:14:43 <Wip> ack JoeAndrieu
16:14:43 <Zakim> JoeAndrieu, you wanted to say the immediate proof is from TLS
16:15:22 <TallTed> s/transactions in Bitcoin that lead/... transactions in Bitcoin that led/
16:15:23 <KevinDean> joeandrieu: I agree with everything you just said with the proof being a data integrity style attachment. But we are using TLS, so we can prove that it came from the resolver we think we're talking to.
16:15:47 <Wip> ack ottomorac
16:15:52 <KevinDean> ...I think we should remove the proof from DID documents because we don't have a firm definition. If you have a resolver you can trust, you can trust what it provides.
16:16:06 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html TallTed
16:16:29 <ottomorac> dev.uniresolver.io
16:16:34 <KevinDean> ottomorac: We just mentioned that very few or no people are using the caching feature and I'm curious about that. I asked Gemini, and it came back with saying that the DIF universal resolver uses caching.
16:16:41 <ottomorac> Affinidi DID Resolver Cache: There is a specific Rust-based SDK
16:16:46 <KevinDean> ...There's also one in Affinity that I believe is built in Rust.
16:17:16 <KevinDean> ...There's also one in Python that mitigates what's called "Thundering Herd" problems on a resolver.
16:17:22 <JoeAndrieu> q+ to say it isn't that people aren't caching, its that we have not defined a standard way to do that with any guarantees of integrity
16:17:37 <manu> q+
16:18:17 <ottomorac> Affinidi DID Resolver Cache: There is a specific Rust-based SDK built by Affinidi to add a high-performance caching layer to the Universal Resolver architecture. It is designed to minimize the latency of blockchain-based lookups (like did:ethr or did:indy) which can be slow.
16:18:18 <KevinDean> swcurran: We use short caching to prevent multiple resolutions in five-second spans where each one involves pulling the same DID document. So, short caching for what amounts to a single activity prevents going out to the source every time for the duration of the activity.
16:18:25 <KevinDean> ...We have a TTL attribute as well.
16:18:42 <Wip> ack JoeAndrieu
16:18:42 <Zakim> JoeAndrieu, you wanted to say it isn't that people aren't caching, its that we have not defined a standard way to do that with any guarantees of integrity
16:18:56 <smccown> smccown has joined #did
16:19:29 <ottomorac> dev.uniresolver.io: often use Nginx or similar reverse proxies to cache resolution results based on the DID URL.
16:19:43 <KevinDean> joeandrieu: It's not that people aren't caching, it's whether we come up with a standard way to guarantee the integrity of cache results. Right now, if you are using the DIF resolver, you have to trust that they're giving a good result, but we don't have a way to know that any resolver that DIF proxied to gave you a valid result.
16:19:45 <Wip> ack manu
16:20:05 <KevinDean> manu: I agree with Joe. We should just delete the sentence. We're out of time.
16:20:29 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/289
16:21:59 <KevinDean> wip: I raised this because I was confused about a few things that Steven raised. I came to the realization that this statement in the spec that support for DID parameters should be optional. Should it apply to DID methods only and not DID resolvers? It feels strange that a DID resolver is queried with a set of parameters, some of which it doesn't
16:21:59 <KevinDean> understand, and then just drops them. How does the client know that it has happened, and will the results be different because of it?
16:22:16 <Wip> q?
16:22:18 <KevinDean> ...If a request has DID parameters that you don't recognize, you should fail, and the client should change the request.
16:22:20 <JoeAndrieu> q+ to say the requester may not be the did creator
16:22:21 <KevinDean> +1
16:22:31 <Wip> ack JoeAndrieu
16:22:31 <Zakim> JoeAndrieu, you wanted to say the requester may not be the did creator
16:22:51 <KevinDean> joeandrieu: I think I disagree, but you're saying two things I'm confused by.
16:23:22 <KevinDean> ...The requestor is likely not the creator of the DID. At their level, it's an opaque stream. If I've given a DID on a business card, I don't know how to unpack it.
16:23:23 <Wip> q+
16:23:51 <KevinDean> ...One thing that was confusing was the statement that they have to understand all the parameters that they process.
16:23:53 <Wip> ack Wip
16:23:59 <KevinDean> ...If they process it, they understand it.
16:24:15 <swcurran> q+
16:24:27 <manu> q+ to note I agree in general, but wondering about corner cases such as foo=bar in a path?
16:24:33 <KevinDean> wip: If you're talking about the client, I agree. They don't need to understand the DID itself, but they need to understand if the DID resolver dropped any of the parameters.
16:24:33 <JoeAndrieu> q+ to say they trust that resolver for that method
16:24:34 <Wip> ack swcurran
16:25:11 <KevinDean> swcurran: Can we learn from HTTP here, where if you put in a parameter, if the web server doesn't understand it, the parameter is silently ignored?
16:25:29 <KevinDean> ...Do we add something in the metadata to say that a parameter was ignored?
16:25:48 <KevinDean> ...The only possible exception is if it's one of the core parameters. Every resolver should handle them.
16:25:58 <Wip> q+ to mention version
16:26:01 <Wip> ack manu
16:26:01 <Zakim> manu, you wanted to note I agree in general, but wondering about corner cases such as foo=bar in a path?
16:26:06 <KevinDean> ...It shouldn't error off if it couldn't process them.
16:26:49 <KevinDean> manu: I like what Steven just said. I think the problem with "it must" is that I'm wondering what happens with a parameter meant for a path. People aren't going to encode these things in relative references.
16:27:06 <KevinDean> ...I like Steven's solution that you must process the parameters defined in the spec.
16:27:07 <swcurran> q+
16:27:31 <KevinDean> ...You're not going to throw just anything at a resolver and expect it to handle it.
16:27:35 <Wip> ack JoeAndrieu
16:27:35 <Zakim> JoeAndrieu, you wanted to say they trust that resolver for that method
16:27:46 <KevinDean> ...I think this is as good as we're going to do for this iteration of the spec.
16:28:32 <KevinDean> joeandrieu: I push back against more parameters that are "musts", as that puts too much of a burden on each DID method implementation.
16:28:56 <ottomorac> +1 to what Joe is saying
16:28:56 <KevinDean> ...I think this is overblown, because if I trust a resolver for a DID method, then it should handle very parameter defined by the DID method.
16:29:01 <Wip> ack Wip
16:29:01 <Zakim> Wip, you wanted to mention version
16:29:05 <KevinDean> s/ very / every /
16:29:16 <swcurran> q-
16:29:39 <JoeAndrieu> +1 to "if you implement this property, it should do this"
16:29:45 <KevinDean> wip: I think we talked about this. There are some DID parameters like version ID and version time, where if you're implementing a resolver for a DID method, then you must implement support for those parameters.
16:30:10 <KevinDean> ...If someone passes in a DID with a version ID and the DID doesn't support it, then I just ignore it.
16:30:20 <KevinDean> q+
16:30:24 <Wip> ack KevinDean
16:30:29 <KevinDean> scribe-
16:30:35 <manu> scribe+
16:32:04 <manu> KevinDean: I agree with Joe in that if a resolver supports a group of DID Methods, it should support the parameters for those DID Methods. If someone passes in a parameter that DID Method doesn't support, such as versionId, that's a problem for the requesting client, they're asking for something DID Method doesn't support. The best I think we can do is return some metadata on ignored parameters. To Joe's point, if I'm asking a resolver, any parameter
16:32:04 <manu> that's in the spec, plus ones in DID Core, should be supportable as defined in the spec for method X.
16:32:05 <manu> q+
16:32:08 <manu> scribe-
16:32:10 <Wip> ack manu
16:32:17 <KevinDean> scribe+
16:32:40 <KevinDean> manu: I think this just comes down to just how strict the resolution process should be. When we detect an error, do we fail or just warn?
16:33:08 <KevinDean> ...Developers using vibe coding etc. are not going to check metadata etc., but they don't have the time to learn it all anyway.
16:33:22 <KevinDean> ...The system loudly complaining or refusing to proceed is sometimes the better option.
16:33:25 <swcurran> q+
16:33:35 <Wip> ack swcurran
16:33:38 <KevinDean> ...We need to decide on the philosophy and apply it evenly across the algorithms.
16:34:20 <KevinDean> swcurran: I would make it a warning and put it in the metadata and return it to the client. I don't think it's as much of a concern for this case.
16:34:25 <manu> q+ to note "strict mode" might be an option.
16:34:30 <Wip> ack manu
16:34:30 <Zakim> manu, you wanted to note "strict mode" might be an option.
16:34:54 <KevinDean> manu: One thing we could tell people is that there's a strict mode that forces an error rather than a warning.
16:35:06 <ottomorac> I like the idea of an optional strict mode
16:35:17 <KevinDean> ...I'm concerned that there's going to be some kind of horrible security error by ignoring the warnings and that's going to come back on the ecosystem.
16:35:22 <KevinDean> q+
16:35:27 <KevinDean> q-
16:35:42 <Wip> zakim, next agendum
16:35:42 <Zakim> agendum 3 -- DID Resolution Ready for PR \[2\] (5 min) -- taken up [from agendabot]
16:35:42 <JoeAndrieu> +1 to considering "strict mode"
16:35:47 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22good%20first%20issue%22
16:35:57 <KevinDean> +1, but it's another parameter...
16:36:04 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/286
16:36:28 <KevinDean> wip: Someone needs to do a spec review with an eye to references to DID document properties like the DID resolution extension.
16:36:45 <KevinDean> ...Some are extensions to DID resolution, some are extensions to DID document.
16:37:41 <KevinDean> ottomorac: I can work on it, but not immediately.
16:37:52 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/287
16:38:14 <Wip> https://w3c.github.io/did-resolution/#datetime
16:38:21 <KevinDean> wip: I noticed that some of the properties using date/time aren't using the up-to-date definition of date/time.
16:38:42 <KevinDean> ...Every option we have for a date/time object should point to this definition rather than rehashing it.
16:39:20 <KevinDean> ...I'll do it when I can.
16:39:20 <Wip> zakim, next agendum
16:39:20 <Zakim> agendum 4 -- DID Extensions question - How to handle PR 651 from Jonathan Rayback \[3\] (5 min) -- taken up [from agendabot]
16:40:19 <KevinDean> ottomorac: So, I believe that this came about because of the did:webs method that Jonathan is involved with. He's proposing to add this conditional proof 2022 as a type.
16:40:32 <KevinDean> ...Should he engage with the group and discuss it?
16:40:34 <Wip> This is the PR https://github.com/w3c/did-extensions/pull/651
16:40:39 <swcurran> q+
16:40:50 <KevinDean> ...I saw some comments that are beyond me, and I wanted to get guidance from the group here.
16:41:03 <Wip> ack swcurran
16:41:10 <KevinDean> wip: I think this is a good discussion to have, as we haven't really discussed a process for DID extensions,
16:41:52 <KevinDean> swcurran: My issue is that there's no detail on what this means. It's replacing an existing one with only the change in the year. I don't know what I'm approving. At least with the DID method registry there's a pointer to a specification. This has nothing.
16:41:57 <manu> q+
16:42:02 <Wip> ack manu
16:42:10 <KevinDean> ...I don't have the history with this group as to what is supposed to happen.
16:42:18 <manu> https://w3c-ccg.github.io/verifiable-conditions/
16:42:19 <ottomorac> I believe this is related to did:webs
16:42:26 <KevinDean> manu: +1. We allow just about anybody to register something as long as there's a spec.
16:42:42 <KevinDean> ...I note that the spec is very light on detail, but it does exist.
16:43:07 <JoeAndrieu> +1 for this being a VC-related feature
16:43:16 <KevinDean> ...I think this needs to go into the VC extensions repo, not the DID extensions repo. Ultimately, data integrity should be its own thing.
16:43:33 <KevinDean> ...What we might try is move all of the verification stuff into the VC extensions repo.
16:43:46 <manu> https://www.w3.org/TR/vc-extensions/#securing-mechanisms
16:44:03 <swcurran> q+
16:44:40 <KevinDean> ...The only thing I'm wondering about is the type. We don't specify the classes of the types in the VC extensions registry, whereas we do that in the DID extensions registry.
16:44:58 <KevinDean> ...High level, I think we tell them to register in VC extensions.
16:45:15 <KevinDean> swcurran: My concern is that I didn't even see the link in the comment. The text in the PR has no link to that spec.
16:45:22 <KevinDean> manu: It's there, line 1523.
16:46:06 <KevinDean> manu: What they're doing is not wrong. The problem is us. We have some types in the DID extensions registry and the data integrity types in the VC extensions registry.
16:46:17 <KevinDean> ...Let them register in both places and we'll clean it up.
16:46:29 <Wip> q?
16:46:31 <KevinDean> ...Tell them we'll figure out the proper place in time.
16:46:35 <ottomorac> q+
16:46:37 <Wip> ack swcurran
16:46:47 <Wip> ack ottomorac
16:46:52 <ottomorac> Hello @jrayback
16:46:52 <ottomorac> This should be registered in the VC Extensions Repo: https://www.w3.org/TR/vc-extensions/#securing-mechanisms
16:46:52 <ottomorac>  in addition to here. Apologies we are figuring out the process for this.
16:47:11 <manu> also, allow registration in DID Extensions
16:47:26 <KevinDean> ottomorac: I just pasted my potential response in the chat.
16:48:03 <Wip> zakim, next agendum
16:48:03 <Zakim> agendum 5 -- DID Resolution Threat Modelling (continuation) \[4\] (20 min) -- taken up [from agendabot]
16:48:58 <Wip> This is the repo - https://github.com/w3c/did-resolution-threat-model
16:49:07 <KevinDean> joeandrieu: I don't have a lot scheduled as the repo isn't quite there. PA has some time off. We don't have GitHub Pages setup yet, so it's not a functional place to work on the spec.
16:49:29 <KevinDean> ...Who are the editors? I've volunteered, does anyone else want to join?
16:49:34 <manu> +1 for JoeAndrieu being the lead Editor
16:49:40 <KevinDean> wip: Anyone want to help Joe?
16:50:24 <KevinDean> ottomorac: I believe that the best person is Stephen Curran.
16:50:29 <KevinDean> swcurran: I'd be happy to help.
16:50:34 <ottomorac> :-)
16:50:35 <KevinDean> s/Steven/Stephen/
16:51:10 <manu> s/swcurran/SteveMcCown/
16:51:36 <ottomorac> Steve Mccown would be ideal
16:51:51 <KevinDean> s/is Stephen Curran/is Steve McCown/
16:52:00 <smccown> smccown has joined #did
16:52:19 <KevinDean> joeandrieu: We're not ready to go into Echidna. We haven published the confidence method.
16:52:24 <KevinDean> s/haven/have/
16:52:40 <KevinDean> ...So we'll just get the GitHub pages to show the current draft.
16:53:20 <KevinDean> ...I'd like to do a deep dive once we have a first draft list of threats.
16:53:28 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html TallTed
16:53:34 <KevinDean> wip: Do you think it's best of have a full call on that?
16:53:55 <TallTed> s/that's in the spec, plus ones/...that's in the spec, plus ones/
16:53:57 <KevinDean> joeandrieu: We could do a full call, but I think half an hour is better if we want to do it in the main call. It would also justify a special topic call.
16:54:12 <TallTed> s/understand, and then just/...understand, and then just/
16:54:13 <KevinDean> ...Let's start in the main call until we get a sense of the scope of the work.
16:54:30 <KevinDean> ...I think we can start next week if Steve McCown has time.
16:54:47 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html TallTed
16:54:53 <KevinDean> smccown: I'm at a conference all of next week. I can work on the side during that time, but I might not be here at the next meeting.
16:55:11 <KevinDean> joeandrieu: We'll do a check-in on next week's call and do a detailed session later.
16:56:01 <KevinDean> scribe-
16:57:16 <Wip> rrsagent, make minutes
16:57:17 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html Wip
16:57:23 <Wip> m2gbot, link issues with transcript
16:57:23 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/274#issuecomment-3892127966
16:57:23 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/289#issuecomment-3892128073
16:57:23 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/286#issuecomment-3892128176
16:57:23 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/287#issuecomment-3892128266
16:57:24 <Wip> zakim, end the meeting
16:57:24 <Zakim> As of this point the attendees have been Wip, ottomorac, KevinDean, TallTed, dmitriz, JennieM
16:57:26 <Zakim> RRSAgent, please draft minutes
16:57:28 <RRSAgent> I have made the request to generate https://www.w3.org/2026/02/12-did-minutes.html Zakim
16:57:34 <Zakim> I am happy to have been of service, Wip; please remember to excuse RRSAgent.  Goodbye
16:57:34 <Wip> RRSAgent, please excuse us
16:57:34 <RRSAgent> I see no action items
16:57:34 <Zakim> Zakim has left #did