14:55:51 <RRSAgent> RRSAgent has joined #did
14:55:55 <RRSAgent> logging to https://www.w3.org/2025/08/28-did-irc
14:56:01 <Wip> rsagent, draft minutes
14:56:08 <Wip> rrsagent, make logs public
14:56:26 <Wip> Meeting: Decentralized Identifier Working Group
14:56:31 <Wip> Chair: Wip
14:56:34 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Aug/0012.html
14:57:51 <ottomorac> ottomorac has joined #did
15:00:36 <Wip> present+
15:00:47 <ivan> present+
15:00:59 <KevinDean> KevinDean has joined #did
15:01:11 <KevinDean> present+
15:01:47 <ottomorac> present+
15:02:06 <pchampin> present+
15:02:08 <swcurran> swcurran has joined #did
15:02:14 <swcurran> present+
15:02:16 <TallTed> TallTed has joined #did
15:04:45 <pchampin> scribe+
15:05:01 <Wip> Topic: Agenda Review
15:05:20 <TallTed> present+
15:05:27 <pchampin> Wip: we have a basic agenda today.
15:05:44 <pchampin> ... Status of DID-core by Manu, looking at PRs for DID Resolution.
15:06:04 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html TallTed
15:06:18 <Wip> q?
15:06:26 <pchampin> ... Then I want to spend time of DID Resolution issue processing.
15:06:31 <Wip> Topic: DID Core Update
15:06:57 <pchampin> manu: No issue we need to focus on. DID-Core is in a fine shape.
15:07:25 <pchampin> ... We have ways to move forward about fragments in DID-URLs (which we discussed previously), we have a PR.
15:07:30 <TallTed> previous meeting: https://www.w3.org/2025/08/21-did-minutes.html
15:07:33 <TallTed> next meeting: https://www.w3.org/2025/09/04-did-minutes.html
15:07:47 <TallTed> s/rsagent, draft minutes//
15:08:22 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html TallTed
15:08:29 <pchampin> ... Overall, the text is fine; I don't think we have figured out how to prove interop for the 1.1. spec.
15:08:38 <pchampin> ... We need to have this dicussion.
15:08:51 <pchampin> s/we have a PR/PR coming
15:09:13 <pchampin> ... We need horizontal reviews done as well, they are on other groups.
15:09:27 <pchampin> ... We would like to get DID 1.1 as CR for TPAC, possibly before.
15:09:47 <pchampin> Wip: what is your take about how we can prove interop?
15:09:56 <JoeAndrieu> JoeAndrieu has joined #did
15:10:15 <pchampin> manu: in a perfect world, we would have multiple DID implementers upgrading their method to DID 1.1.
15:10:23 <JennieM> JennieM has joined #did
15:10:24 <ivan> q+
15:10:28 <JennieM> present+
15:10:36 <JoeAndrieu> present+
15:10:45 <pchampin> ... I don't know if we would get much coverage, given the number of DID methods.
15:11:03 <pchampin> ... Another possible path: we have a bunch of DID documents provided by people.
15:11:21 <pchampin> ... We could inject the new 1.1 context in these documents and check that JSON-LD processors handle them correctly.
15:11:46 <Wip> q+
15:11:49 <pchampin> ... This would prove that we have not made any backward incompatible change, and that the new 1.1. context will not break 1.0 implementations.
15:12:10 <pchampin> ... This is hacky but I suggest that we do that. It is doable in short time.
15:12:28 <pchampin> ... Another possible path, better in the long term:
15:12:52 <pchampin> ... use the interface we are using for DID resolution, and modify the test suite to modify the context that comes back.
15:13:14 <pchampin> ... At Digital Bazaar, we plan to use the 1.1 context in the documents we return.
15:13:47 <pchampin> ... That would be more work, but better in the long term, compared to the current static test suite that we have.
15:14:01 <pchampin> ... To summarize:
15:14:17 <pchampin> ... option 1: modify the current test suite, search and replace the 1.0 context with the 1.1 context
15:14:37 <pchampin> ... option 2: modify the DID resolution test-suite, replace the context
15:14:41 <Wip> ack ivan
15:14:55 <pchampin> ... option 3: update the DID resolution test-suite, have people use the 1.1 context
15:15:36 <Wip> ack Wip
15:15:45 <pchampin> ivan: when replacing the 1.0 context with 1.1 context, how do we prove we didn't break anything?
15:15:45 <Wip> q+
15:16:17 <pchampin> ... I would assume by computing the hash based on RDF C14N and check that it didn't change?
15:16:22 <pchampin> manu: that's one way to do it
15:16:47 <Wip> ack Wip
15:17:08 <pchampin> ... some implementers do not want to use JSON-LD but we only need two to pass.
15:17:33 <ivan> q+
15:17:42 <pchampin> Wip: I like the hacky and quick option, but will it satisfy W3C?
15:18:14 <pchampin> ... we could mix it with option 3: use native 1.1 implementation when available, or patch 1.0 implementation otherwise
15:18:15 <Wip> ack ivan
15:18:38 <pchampin> ivan: doing the first one avoids to open the floodgate of discussions with outsider
15:18:52 <pchampin> ... the changes in 1.1 are not changing the documents, as per our charter
15:19:14 <pchampin> ... 1.0 documents have already passed the tests for 1.0; we do the minimal thing to validate our minimal changes
15:20:10 <pchampin> Wip: I like that, but let's not forbid ourselves to prepare the future with option 3.
15:20:15 <Wip> Topic: DID Resolution PR Processing
15:20:25 <Wip> https://github.com/w3c/did-resolution/pulls
15:20:54 <pchampin> Wip: Markus is not on the call, but we can discuss some of the PRs.
15:20:57 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/180
15:21:42 <pchampin> swcurran: I think this one is ready to go. Manu made some suggestions.
15:21:52 <Wip> q?
15:21:57 <pchampin> Wip: OK, I will let Markus know.
15:22:01 <Wip> Topic: DID Resolution Issue Processing
15:22:10 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20sort%3Aupdated-asc
15:22:29 <pchampin> i|Topic: DID Resolution Issue Processing|... Please everyone also have a look at 178 and 179.
15:22:53 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/38
15:23:25 <pchampin> Wip: we need to decide what we need to address this issue.
15:23:28 <JoeAndrieu> q+
15:23:31 <Wip> ack JoeAndrieu
15:23:43 <pchampin> JoeAndrieu: I think we still need to deal with this.
15:23:56 <pchampin> ... It fits within the scope of the "Resolution architecture and thread modelling" stream.
15:24:07 <pchampin> ... We've made some progress since this issue was opened.
15:24:32 <pchampin> ... There are related issues (on Threat modeling).
15:24:36 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/148
15:24:47 <pchampin> i|subtopic|Wip: I'll put a link to the related issue
15:25:02 <manu> q+
15:25:08 <pchampin> Wip: this one is a good "first issue" for submiting a PR
15:25:09 <Wip> ack manu
15:25:30 <manu> https://www.specref.org/
15:25:32 <pchampin> manu: I'm looking at what the current reference is.
15:25:48 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html TallTed
15:25:57 <pchampin> ... Specref (link above) crawls all W3C and IETF specifications and allow to make references.
15:26:58 <pchampin> ... The good news is that the refs are now auto-generated.
15:27:11 <pchampin> ottomorac: I can do it.
15:27:19 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/131
15:27:23 <TallTed> s|178 and 179.|w3c/did-resolution#178 and w3c/did-resolution#179.|
15:27:41 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html TallTed
15:27:54 <pchampin> Wip: I guess this one is related to the threat modeling discussion.
15:27:57 <JoeAndrieu> q+
15:28:02 <Wip> ack JoeAndrieu
15:28:31 <pchampin> JoeAndrieu: I have seen this, didn't have time yet to dig into it, but will do.
15:28:45 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/172
15:29:14 <pchampin> Wip: this one was originally raised against DID-core.
15:29:28 <TallTed> present+ manu
15:29:42 <pchampin> ... We discussed this, concluding that DID Resolution should set a limit.
15:29:49 <manu> q+
15:29:51 <Wip> ack manu
15:30:17 <pchampin> manu: it probably should not be in the Security Consideration section, it should go in the main text, and we should have a test for that.
15:30:23 <Wip> q+
15:30:27 <Wip> ack Wip
15:30:29 <pchampin> ... It will be painful to write that test, but it is important.
15:30:55 <pchampin> Wip: I'm trying to work through what the problem described is.
15:31:26 <pchampin> manu: you resolve a DID, find the verification method from the DID document, and the verification method lives in a separate document.
15:31:55 <pchampin> ... that other DID document points back to the original document, creating a cycle.
15:32:20 <pchampin> ... This would be an attack. To prevent it, you keep track of the URLs you join to and detect cycles and avoid looping forever.
15:32:44 <pchampin> Wip: so we need text in DID Resolution about detecting these cycles. Should be straighforward.
15:32:54 <swcurran> q+
15:33:00 <Wip> ack swcurran
15:33:17 <manu> q+
15:33:24 <Wip> ack manu
15:33:43 <pchampin> swcurran: it's at the level of a universal resolver. Most resolvers resolve a single method.
15:33:55 <pchampin> manu: it depends on the method. did:key can not have this problem, but did:web can.
15:34:01 <Wip> q+
15:34:15 <Wip> q-
15:34:17 <pchampin> ... Not all implementation should demonstrate that they have cycle detection, but we only need two.
15:34:43 <dmitriz> heh the other thing I bet most resolvers don't currently deal with is -- controller logic
15:34:49 <pchampin> ... May be what I just explained is not even possible with the spec, we need to explore this.
15:34:57 <dmitriz> like, if a did has no methods but its controller does, which resolvers fetch those
15:35:24 <pchampin> ... We need to see what happens with did:web in particular.
15:35:49 <pchampin> ... We could provide two did:web document that point to each other, which would prevent people from writing their own test.
15:36:16 <pchampin> Wip: I would like to assign this issue.
15:36:23 <pchampin> swcurran: I'll take it, sounds like fun!
15:36:26 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/133
15:36:27 <dmitriz> though I think this is ok because our spec currently is very light on Controller semantics
15:37:22 <pchampin> Wip: IIUC, this issue is about providing some architecture diagram from which we can derive Security and Privacy considerations.
15:37:28 <pchampin> JoeAndrieu: that's a good description
15:37:30 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/92
15:38:31 <manu> q+
15:38:31 <pchampin> Wip: This test suite is pointing to a place controlled by the VC test suite.
15:38:44 <pchampin> ... I'm wondering whether we should create our own repo.
15:38:49 <Wip> ack manu
15:39:03 <pchampin> manu: we could do that, and I think that's what Benjamin was thinking.
15:39:16 <pchampin> ... we have gotten to a state where we have 3 such repositories...
15:39:32 <pchampin> ... it would be nice to get down to 1 implementers repo.
15:39:48 <Wip> This is the repo for reference - https://github.com/w3c-ccg/did-resolution-test-suite
15:39:57 <Wip> Actually that isnt right
15:40:05 <pchampin> ... people could contribute their implementations and opt-in to different test-suite, regardless of the WG working on them
15:40:27 <Wip> https://github.com/w3c-ccg/did-resolution-mocha-test-suite
15:40:32 <pchampin> s|This is the repo for reference - https://github.com/w3c-ccg/did-resolution-test-suite|
15:40:38 <pchampin> s|Actually that isnt right|
15:40:48 <Wip> https://github.com/w3c-ccg/vc-test-suite-implementations
15:41:31 <pchampin> Wip: the did-resolution-mocha-test-suite repo, containing our test suite, is currently pointing to the vc-test-suite-implementations repo for the list of implementations
15:42:01 <Wip> https://github.com/w3c-ccg/vc-test-suite-implementations/blob/main/implementations/DanubeTech.json
15:42:02 <pchampin> ... it is strange that the latter says "VC" but maybe that's ok.
15:42:11 <manu> Here's the other one, to make things even more complicated: https://github.com/w3c/vc-test-suite-implementations :)
15:42:34 <pchampin> ... the JSON file above is how Danube Tech defines their implementation of the test suite
15:42:45 <manu> q+
15:42:50 <Wip> ack manu
15:43:16 <pchampin> manu: I think we should get rid of the CCG repo
15:43:41 <pchampin> ... and we should agree (amongst the VC and DID WG) to put all our implementations in the same repo
15:43:45 <pchampin> ... let's not fork it!
15:43:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html TallTed
15:44:19 <ivan> q+
15:44:19 <pchampin> s/amongst/amonst the CCG,
15:44:23 <Wip> ack ivan
15:44:36 <manu> q+
15:44:40 <Wip> ack manu
15:44:40 <pchampin> ivan: I presume that includes future WG as well...
15:44:53 <pchampin> ... like the proposed DID Methods WG
15:44:57 <pchampin> manu: exactly
15:45:36 <pchampin> ... that means that registered implementations must be able to indicate which test-suite their expect to pass
15:46:15 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/173
15:46:44 <pchampin> Wip: TallTed, do you want to talk about this?
15:46:51 <manu> q+
15:46:54 <Wip> ack manu
15:46:57 <pchampin> TallTed: I know this is an issue, but I don't know what the answer is.
15:47:02 <pchampin> manu: TallTed is correct, it is a problem.
15:47:12 <pchampin> ... I'm wondering if we need to say anything, though.
15:47:58 <pchampin> ... In any context, when you run an HTTPS in a local environment, you need to jump through some hoops, that are not good security practices
15:48:42 <pchampin> ... Maybe just a sentence in the Security Consideration section: "if you run an HTTPS service on a private IP range, consult your sysadmin"
15:48:55 <pchampin> ... we should not explain *how* to solve it.
15:48:57 <pchampin> TallTed: I agree
15:49:46 <manu> q+
15:49:51 <Wip> ack manu
15:50:01 <pchampin> Wip: I would like somebody to volunteer to write a PR for that.
15:50:09 <pchampin> ... Otherwise we will have to close this.
15:50:27 <pchampin> manu: not volunteering, but this is the kind of job an LLM could help with.
15:50:34 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/174
15:50:57 <pchampin> Wip: this one is about specifying a new error code.
15:51:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html TallTed
15:51:47 <pchampin> ottomorac: I can take it.
15:51:56 <pchampin> Wip: good, you should have a look at the error's section.
15:52:24 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/161
15:52:48 <pchampin> Wip: I don't remember where we are with this one.
15:53:04 <pchampin> ... Currently, DID Resolution is specified with GET only. We discussed supporting also POST or only POST.
15:53:07 <bigbluehat> bigbluehat has joined #did
15:53:20 <manu> q+
15:53:23 <Wip> ack manu
15:53:27 <bigbluehat> present+
15:53:32 <pchampin> ... Some people are reluctant to drop GET.
15:53:48 <pchampin> manu: reading through the minutes from last time, I think we agreed to do both.
15:54:09 <pchampin> ... Markus argued that banning GET would make old resolvers non-conformants.
15:54:25 <swcurran> +1 to MAY on POST
15:54:54 <pchampin> ... We could say "you MUST implement either POST or GET."
15:55:02 <pchampin> ... It would create complexity for the test suite.
15:56:02 <pchampin> Wip: we need to figure out what we want as a group.
15:56:30 <pchampin> ... It was a great call, we pretty much got through the first page of pending issues, and assigned a bunch of them.
15:56:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html pchampin
17:48:52 <ottomorac> ottomorac has left #did
20:45:20 <TallTed> Zakim, end meeting
20:45:21 <Zakim> As of this point the attendees have been Wip, ivan, KevinDean, ottomorac, pchampin, swcurran, TallTed, JennieM, JoeAndrieu, manu, bigbluehat
20:45:22 <Zakim> RRSAgent, please draft minutes
20:45:24 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/28-did-minutes.html Zakim
20:45:29 <Zakim> I am happy to have been of service, TallTed; please remember to excuse RRSAgent.  Goodbye
20:45:30 <Zakim> Zakim has left #did
20:45:32 <TallTed> RRSAgent, bye
20:45:32 <RRSAgent> I see no action items