14:52:39 RRSAgent has joined #did 14:52:43 logging to https://www.w3.org/2025/06/12-did-irc 14:52:49 rrsagent, draft minutes 14:52:50 I have made the request to generate https://www.w3.org/2025/06/12-did-minutes.html Wip 14:52:54 rrsagent, make logs public 14:53:06 Meeting: Decentralized Identifier Working Group 14:53:08 Chair: Wip 14:53:12 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Jun/0003.html 14:53:15 present+ 14:54:47 ottomorac has joined #did 14:59:03 TallTed has joined #did 15:00:12 KevinDean has joined #did 15:00:28 present+ 15:02:27 present+ 15:03:10 present+ 15:05:06 Phil has joined #did 15:05:13 scrbe+ 15:05:21 scribe+ 15:05:38 Topic: Agenda Review 15:06:33 present+ 15:06:34 Agenda reiterated 15:06:35 Topic: Scheduling for June 19th 15:07:17 Wip: Next week's meeting June 19th is a US holiday - skip it? 15:08:37 Wip: inclination to have the call on the 19th. 15:08:40 Topic: APAC DID Wg Collaboration 15:08:47 q+ 15:09:12 ack ottomorac 15:09:45 Wip: APAC attendance has been low. Relationship with Asia Pacific colleagues collaboration ideas? Next APAC meeting is in the Asia Pacific. 15:11:01 q+ 15:11:12 ack Wip 15:11:26 JoeAndrieu has joined #did 15:11:31 ottomorac: cancel APAC calls until TPAC to re-engage at that point. Manu suggested the Shigeyu (sp) might worth consulting to get ideas for jumpstarting the group. 15:12:20 Wip: Concerned about cancelling the calls. Who should we be talking to in the Asia Pacific region? 15:12:30 q? 15:13:14 Wip Will reach out to Shigeya and others to search for ideas. 15:13:31 Topic: DID Method Standardization Wg Update 15:13:55 Wip: Marcus wanted to update us on standardization work. 15:13:56 https://lists.w3.org/Archives/Member/w3c-ac-members/2025AprJun/0046.html 15:14:08 https://github.com/w3c/did-methods-wg-charter/ 15:14:38 swcurran has joined #did 15:15:25 pchampin: has a few PRs open. Scope of EU methods, excluding blockchain, and look a whether the scope fits in the attention of this group. 15:15:50 Topic: DID Resolution PR Processing 15:15:57 https://github.com/w3c/did-resolution/pulls 15:16:28 subtopic: https://github.com/w3c/did-resolution/pull/157 15:16:31 Wip: majority of PRs are ready to be merged so everyone should take a close look at them. 15:17:38 Wip: DiD resolvers should be aware of requesters - questions? 15:17:40 q? 15:17:43 Looks good 15:18:16 Topic: DID Resolution Test Suite 15:18:19 Wip No one on the queue. Or input to this PR. 15:18:30 subtopic: https://github.com/w3c/did-resolution/issues/92 15:18:50 https://github.com/w3c-ccg/did-resolution-test-suite 15:18:59 smccown has joined #did 15:19:08 present+ 15:19:46 Wip: Test suite for the DID resolution - good start but needs significant changes. 87 MUST statements need tests. 15:20:44 Seems to be using the cypress testing library 15:22:54 Wip: Resolver URL and set of tests in the /fixtures folder. Does the test suite expect HTTPS url bound to the results. Every resolver needs test cases that may use different DIDs. How are we handling errors? No place to submit resolver implementations 15:23:45 Wip: if there are 87 MUST statements do all need tests? 15:24:01 bigbluehat has joined #did 15:24:11 present+ 15:24:20 q+ 15:24:34 ack bigbluehat 15:24:35 dmitri: Ideally yes. 15:27:11 JennieM has joined #did 15:27:56 Benjamin Young: W3C testing requirements are testing the spec not necessarily the code though you are doing both. Need to assure the test suite is aligned with the spec to make it implementable. Can have requirements on other specs, downstream specs, etc. MUST doesn't mean it's a requirement of the code. Are the tests automatable 15:28:39 q+ 15:29:04 ack bigbluehat 15:29:07 Wip: for these resolvers this DID support the implementation and resolve per the spec 15:30:48 Wip: next step to move test suite forward? SHould we continue to work on the CCG test suite or leave them to work on it? 15:31:09 q+ 15:31:14 ack ottomorac 15:31:29 q+ 15:32:24 q+ 15:32:32 ack bigbluehat 15:32:32 ottomorac: most of this work was done for folks working under Marcus. Is it a you can have untestable MUST statements, is that something that needs to be addressed or left for testing in non-code ways? 15:33:22 present+ 15:33:39 Benjamin Young: just kept a list of those that they couldn't implement them. Helpful in development. Ultimately had to take them out or comment them out as it concerned people if they appeared in the report. Provided a separate list of those were unimplementable because they weren't for software. 15:35:16 s/Benjamin Young/bigbluehat 15:35:17 Benjamin Young: this didn't cause any raised eyebrows. These are implementation not test but spec tests 15:35:20 ack swcurran 15:36:41 q+ 15:37:20 ack Wip 15:37:47 swcurran: should be a list of tests that a DID method should implement. List what you want to test (the inventory), then the DID method would construct DIDS and some bad DIDs to test different conditions. DID resolution test resolves the DID in layered approach. Creating the inventory is key. 15:38:00 q+ 15:38:21 Wip: Resolver implementations need to prove the resolve the DIDs in all the cases they are for. 15:38:25 ack bigbluehat 15:39:46 q+ 15:39:53 q+ 15:40:27 ack Wip 15:40:33 bigbluehat: creating a test suite API sounds like what we're talking about. Just a minimal API. If you were doing something different from VC-API you could wrap it in VC-API then the test suite is always communicating with the same 2 or 3 endpoints. Someone needs to look at the shim to make sure that's not introducing issues. Test suite authors 15:40:34 will be few and stressed to do their work 15:40:58 https://github.com/w3c/did-resolution/issues/93 15:41:11 Note Benjamin Young is bigbluehat in the above comments 15:41:19 ack swcurran 15:41:56 q+ 15:42:18 swcurran: you have a test that's a list of DIDs and run them through the resolver. Any DID resolver needs a way to pass in a DID to it. 15:42:22 +1 to universal resolver as swcurran suggests 15:42:23 ack Wip 15:42:43 Wip: want DIDs and resolutions options as a package as required by the API 15:42:45 q+ to suggest it's not the resolver but the method that needs it 15:43:04 swcurran: it's the DID url not just the DID 15:43:11 ack JoeAndrieu 15:43:11 JoeAndrieu, you wanted to suggest it's not the resolver but the method that needs it 15:44:48 JoeAndrieu: every resolver doesn't need http interface. A resolver might be a library, does that library need to open of an http socket? 15:45:17 JoeAndrieu: for the sake of testing we're using http 15:45:47 Wip: would like some help moving this forward - perhaps from the CCG 15:45:50 swcurran has joined #did 15:45:58 +q 15:47:31 ack swcurran 15:47:34 bigbluehat: the test suites are a working group products. They can begin in the CCG but final test suites need to be workgroup produced. Can work on both at the same time. Bitstringstatus list didn't get into the WG until the last minute but that's an exception. The WG needs to say these are our tests. 15:47:51 q+ 15:48:16 q+ 15:48:22 ack Wip 15:48:24 swcurran: sounds like there is a test suite is in scope for this group. But isn't it just a list of tests the DID method should implement 15:49:01 Wip: Disagree, as we're testing resolvers. This group needs to define the tests then hit the resolver to see they work. 15:49:16 ack bigbluehat 15:49:22 Wip: verifying the test is they are resolved. 15:49:34 Swcurran: need to define a set of tests 15:49:52 q+ 15:50:05 q+ to say this is interoperability 15:50:47 bigblluehat: yes, define the tests and see who can implement them. You're testing the implementation not the Spec. One did method testing the resolution spec but there is value in each of the methods showing up with the test suite showing the resolution spec is implemented against the MUST statements. 15:50:52 ack Wip 15:51:03 s/bigblluehat/bigbluehat 15:51:22 ack JoeAndrieu 15:51:23 JoeAndrieu, you wanted to say this is interoperability 15:51:30 Wip: resolvers abstract over the different DID methods. 15:52:21 JoeAndrieu: point of the tests is test the resolver not the methods. If every resolver has a http endpoint. What's the common interface that makes sense so we have a standard interface 15:52:35 q+ 15:52:44 Wip: next step - look at the MUST statments and figure out what the test are for them. 15:53:07 Wip: need a place for doing that work 15:53:24 ack bigbluehat 15:53:37 q+ 15:54:12 brent has joined #did 15:54:20 bigbluehat: recoommend putting MUST statements in an md file and go through what it would take to test them. 15:54:32 ack ottomorac 15:54:54 q+ 15:55:26 ack Wip 15:55:30 q+ 15:55:33 ottomorac: going back swcurran, leverage what the universal resolver is doing to accomplish these test. Enshrine universal resolver as a way of testing this. 15:55:46 Wip: universal resolver is one way to do this but there should be others. 15:56:05 ack swcurran 15:56:09 Wip: agrees with bigbluehat's point that we reach out to others on this. 15:56:43 q+ 15:57:06 swcurran: universal resolver could be a good tool for the resolution spec itself. But there is one implementation per DID method. DID methods may need 4 implementations of their DID method and need four ways to resolve. The universal resolver is only one. 15:57:16 ack bigbluehat 15:57:45 bigbluehat: agree's what swcurran's suggesting but for the W3C's process 15:58:15 bigbluehat: the only must is between the resolver and the implementation spec. 15:58:54 q+ 15:59:28 For context to what Benjamin is saying -- in the did:webvh group, we are doing all the same things -- inventorying MUSTs, defining tests, creating DIDs for resolution. 15:59:39 ack Wip 15:59:43 noted 15:59:49 bigbluehat: If there not requirements by W3C we should leave them for the CCG and others. Narrowing for getting WG effort done. If it's not a W3C spec it's not formally needed. 16:00:06 Wip: could define a common data structure as one output. 16:00:23 sriibe 1 16:00:31 scrb 16:00:41 RRSAgent, make minutes 16:00:43 I have made the request to generate https://www.w3.org/2025/06/12-did-minutes.html pchampin 16:01:55 m2gbot, link issues with transcript 16:01:56 comment created: https://github.com/w3c/did-resolution/pull/157#issuecomment-2967410751 16:01:57 comment created: https://github.com/w3c/did-resolution/issues/92#issuecomment-2967410785 18:29:45 Zakim has left #did 19:44:39 brent has joined #did 20:55:57 ottomorac has left #did