14:49:17 <RRSAgent> RRSAgent has joined #did
14:49:21 <RRSAgent> logging to https://www.w3.org/2025/08/21-did-irc
14:49:24 <ottomorac> rrsagent, draft minutes
14:49:25 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/21-did-minutes.html ottomorac
14:49:30 <ottomorac> rrsagent, make logs public
14:49:36 <ottomorac> Meeting: Decentralized Identifier Working Group
14:49:41 <ottomorac> Chair: ottomorac
14:49:55 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Aug/0008.html
14:55:57 <Michiko> Michiko has joined #did
15:00:33 <KevinDean> KevinDean has joined #did
15:00:43 <KevinDean> present+
15:00:56 <ottomorac> present+
15:00:57 <swcurran> swcurran has joined #did
15:01:14 <swcurran> present+
15:01:57 <Wip> Wip has joined #did
15:02:00 <Wip> present+
15:05:14 <brent> present+
15:07:03 <KevinDean> https://w3c.github.io/scribe2/scribedoc.html
15:07:06 <denkeni> denkeni has joined #did
15:07:09 <JennieM> JennieM has joined #did
15:07:10 <ivan> present+
15:07:15 <denkeni> present+
15:07:19 <JennieM> present+
15:07:21 <swcurran> scribe+
15:08:08 <swcurran> ottomorac: The agenda overview
15:08:33 <ottomorac> Topic: Debrief Special Topic Call for DID Resolution Test Suite on 20-Aug
15:09:37 <manu> DID Resolution test suite base repo is here: https://github.com/w3c-ccg/did-resolution-mocha-test-suite/
15:09:53 <manu> Current report is here: https://w3c-ccg.github.io/did-resolution-mocha-test-suite/
15:10:33 <swcurran> Wip: Call went well. Benjamin has the infrastructure, fork of what the Working group is using. Repo is available to iterate on. Generates a report, but needs to be fixed. Wip to help Benjamin on the repo.  Looking for others to help with the test suite. Will be discussed again next special call - two weeks. Goal is to submit resolver endpoint and
15:10:33 <swcurran> DIDs to resolve. From there -- how to add more tests across the spec.
15:10:37 <manu> q+
15:10:41 <ottomorac> ack manu
15:11:06 <Wip> Yup I agree. Testing the DID resolution spec, not DID methods
15:11:35 <Wip> This is the open issue we are looking at first - https://github.com/w3c-ccg/did-resolution-mocha-test-suite/issues/1
15:11:52 <swcurran> manu: +1 and nuances. Test suite is not there to test DID Methods, there to test the DID Resolution spec. Testing conformance statements in that spec. Some mods defined for what is there. Questions about what is the best way to test options passed to resolvers. Experience will drive that.  Next test is straight resolution, and then we'll go from
15:11:52 <swcurran> there.
15:12:06 <manu> Minutes from that call are here: https://lists.w3.org/Archives/Public/public-did-wg/2025Aug/0009.html
15:12:17 <ottomorac> Topic: Status Update on DID Methods WG Charter Review
15:12:39 <ottomorac> https://github.com/orgs/w3c/projects/97/views/1?filterQuery=method&pane=issue&itemId=95076644&issue=w3c%7Cstrategy%7C492
15:13:41 <manu> q+
15:13:48 <ottomorac> ack manu
15:13:48 <swcurran> ottomorac: Request feedback and provided. Minor cleanup needed regarding items in the Draft Charter. Wording, Success Criteria, Patent Disclosures adjustments needed. Corrections to chairs?
15:14:14 <swcurran> manu: Not sure where the feedback should go to get adjusted.  Defer to Ivan, PA or Brent.
15:15:12 <ottomorac> need to remove Proposed Recommendation section
15:15:22 <Wip> q+
15:15:27 <manu> q+
15:15:31 <swcurran> ivan: New charter template is available, and the charter should be aligned with that. Ivan has started to look at it vs. another charter to see the adjustments.  Proposed Recommendations should be removed, as should euphamisms for that term.
15:15:36 <ottomorac> ack Wip
15:15:43 <manu> q-
15:15:56 <swcurran> Wip: No need to spend time. The chairs of that working group need to address the issues.
15:16:07 <manu> q+
15:16:11 <manu> q-
15:16:28 <ottomorac> Topic: DID WG Timeline and Overall Status
15:16:28 <swcurran> ottormorac: To send to chairs with comments from here.
15:17:02 <Wip> q+
15:17:31 <manu> q+
15:17:35 <swcurran> ottomorac: Charter continues, but hopefully to be ready for recommendation by December. All issues have been discussed at least once.  Keep aim for end of December.
15:17:36 <ottomorac> ack Wip
15:19:00 <swcurran> Wip: Two things. First time through, would love guidance, and how best to leverage TPAC. DID Resolution has 34 issues -- lots, but 13 are ready for resolution. Still to deal with 21. Need to decide as a group what to bring forward -- not all on Marcus.  What do we want to do and who is going to do it. Need a team effort.
15:19:01 <ottomorac> ack manu
15:20:46 <Wip> q+
15:21:38 <ivan> q+
15:22:18 <ottomorac> ack Wip
15:22:21 <swcurran> manu: +1. Chairs should look at end of Charter April 26 and work back -- using minimum time lengths for events, moratoria, TPAC, etc. and work back. Better be in candidate rec. 6 months before end of charter -- October 2025. We won't be there. Extension is possible as good progress is being made.  Suggest using TPAC to define what should be covered
15:22:21 <swcurran> and not. DID Core is under less pressure, but it should be done for that as well.  Test suite needs to be discussed.  Summary, behind schedule, but making progress. Hard decisions on what to drop.  That said, there is a new process that has fewer/shorter steps, but there is lots of work to get implementations and the test suite sorted out.
15:23:14 <ottomorac> ack ivan
15:23:15 <swcurran> Wip: Big chunk of work to be done is threat modelling and how that fits into Security Considerations. Goal is to get some kind of threat modelling.  Hoping to leverage the special purpose calls on that.
15:23:56 <manu> q+
15:24:20 <ottomorac> ack manu
15:24:26 <swcurran> ivan: No proposed recommendations any more, so just two implementations needed for CR, but there is still a vote for that. The new process saves 2-3 weeks, but the AC review is still there, takes a month and still there.
15:24:36 <swcurran> manu: Good point. Are we under the new process?
15:24:46 <swcurran> ivan: Yes. Since 15th August.
15:25:24 <swcurran> manu: Other thing -- horizontal review hasn't been sent out. Takes 6-9 months so we're behind there.
15:25:43 <ottomorac> Topic: @context URL in the spec: https://www.w3.org/ns/did/v1.1 does not resolve #901
15:25:50 <ottomorac> https://github.com/w3c/did/issues/901
15:25:56 <smccown> smccown has joined #did
15:26:00 <manu> q+
15:26:11 <ottomorac> ack manu
15:26:18 <smccown> present+
15:26:24 <ottomorac> Issue opened by Will, regarding the same context URL. Which he claims does not directly resolve to the context file, but instead redirects to the vocab file.
15:26:41 <manu> We should make this resolve: https://www.w3.org/ns/did/v1.1rc1
15:27:21 <ivan> q+
15:27:40 <ottomorac> ack ivan
15:27:43 <swcurran> manu: True does not resolve and it should. However, the way we work, we publish an Release Candidate in that namespace, because people will get ahead and use it and then we get interop issue. We can publish it, but only make RC1 resolve, so that when someone does it wrong, it won't blow up the ecosystem.
15:28:19 <swcurran> ivan: Regardless, I'm messed up by the redirection, and why it doesn't work and who should have done that.  Manu should provide direction.
15:28:33 <swcurran> manu: Yes -- to take it offline to go through it.
15:28:40 <manu> q+
15:28:45 <ottomorac> ack manu
15:29:15 <Wip> +1 having RC makes sense to me
15:29:37 <ottomorac> +1 makes sense
15:29:49 <swcurran> manu: Before that discussion.  Anyone object to do an RC1 published to that location.  Then we will update after candidate rec. Will do RC2 and so on as needed until final. Give implementers stability and guidance to what is coming.
15:30:00 <ottomorac> Topic: @context is missing JsonWebKey and Multikey #903
15:30:06 <ottomorac> https://github.com/w3c/did/issues/903
15:30:07 <manu> q+
15:30:19 <ottomorac> Issue opened by Markus. It seems the context https://www.w3.org/ns/did/v1.1 doesn't define JsonWebKey and Multikey. He suggests that we copy it from the CID spec definition.
15:30:29 <ottomorac> ack manu
15:30:42 <swcurran> manu: Yes +1 to that. Its the right thing to do.
15:30:55 <swcurran> s/Its/It's/
15:31:05 <ottomorac> Topic: Is percent encoding the fragment (#) really conformant with the URI RFC? #898
15:31:15 <ottomorac> https://github.com/w3c/did/issues/898
15:31:23 <ottomorac> This is related to example 6 in the DID core spec, link:  https://www.w3.org/TR/did-1.1/#example-a-resource-external-to-a-did-document In the last meeting, participants clarified that Example 6 in the DID Core specification is indeed correct: according to the URI standard, the fragment identifier must be percent‑encoded rather than replaced with a literal hash (#). Changing to a literal hash would violate the RFC. However, the group ack
15:31:23 <ottomorac> nowledged that the description could be improved—suggesting they will enhance the explanatory text around this subtle point.
15:32:37 <manu> q+
15:32:42 <ottomorac> ack manu
15:34:09 <swcurran> manu: Trying to distangle this from the DID Resolution issue. Complicated.  Remove example 6 from the spec as it is confusing. Any reference to RelativeRef should happen in the DID Resolution spec and move the conversation to DID Resolution spec.
15:35:30 <Phil> Phil has joined #did
15:35:37 <JoeAndrieu2> JoeAndrieu2 has joined #did
15:35:58 <swcurran> ...: Avoid people asking this at this level of the spec -- hence DID Resolution. We have other fragment examples.
15:36:01 <ottomorac> ack manu
15:36:38 <ottomorac> Topic: DID Resolution PRs
15:36:52 <ottomorac> Subtopic: Update the Metadata Structure to include numbers with a caveat about representations #180
15:36:58 <ottomorac> https://github.com/w3c/did-resolution/pull/180
15:37:07 <ottomorac> Proposes allowing numeric values within the DID Resolution metadata structures—specifically addressing Issue #166—while also including an important non‑normative caveat. The change adds language advising that numbers may be represented differently across platforms and programming languages, potentially leading to inconsistencies. Initially written with normative wording like "SHOULD," feedback prompted a revision toward more advisor
15:37:07 <ottomorac> y terminology (e.g., "advise," "RECOMMENDED") to keep that caveat helpful but non-normative. This ensures interoperability without imposing strict requirements or risking misinterpretation in different technical contexts.
15:37:20 <ottomorac> scribe+
15:38:08 <manu> q+
15:38:15 <Wip> LGTM
15:38:30 <ottomorac> swcurran: This PR allows numbers and puts in a normative note, that advises against numbers that could lead to non verification of a signature because of floating point
15:38:44 <ottomorac> manu: yes agree....
15:39:07 <ottomorac> ... the consensus is that we should just warn implementers but not put in any extra features...
15:39:32 <ivan> q+
15:39:36 <ottomorac> ack ivan
15:39:46 <manu> q-
15:39:47 <ottomorac> ack manu
15:39:53 <manu> q+
15:39:59 <ottomorac> ack manu
15:40:11 <ottomorac> ivan: do we need to check with the TAG on this?
15:40:36 <ottomorac> manu:  the TAG has approved infra, I don't think this will be required...
15:40:54 <swcurran> q+
15:40:55 <ottomorac> Topic: DID Resolution Issue Processing
15:41:43 <ottomorac> swcurran: to note that the test suite should be updated, specifically the tests that fails if there is a number in resolution metadata
15:41:47 <ottomorac> scribe-
15:41:50 <swcurran> scribe+
15:41:55 <ottomorac> Topic: DID Resolution Issue Processing
15:42:10 <ottomorac> Subtopic: Define how DID Methods can specify paths and their dereferencing rules #156
15:42:15 <ottomorac> https://github.com/w3c/did-resolution/issues/156
15:42:20 <ottomorac> Issue created by Will based on a discussion from 29-May. We would need to point to the DID Extensions and state how different DID methods can define the path and processing rules they are using. This is also connected to issue #150 related to whether paths should be processed consistently across DID methods.
15:42:50 <Wip> q+
15:42:56 <manu> q+
15:43:00 <ottomorac> ack swcurran
15:43:02 <ottomorac> ack Wip
15:43:51 <JoeAndrieu> q+
15:43:55 <ottomorac> ack manu
15:43:58 <swcurran> Wip: Raised after discussion with Joe. Do we as a DID spec require a consistent experience across DID Methods, or is it a DID Method responsibility?
15:44:14 <manu> https://github.com/w3c/did-resolution/issues/181
15:44:28 <manu> about a unified way to do path resolution
15:45:09 <ottomorac> ack JoeAndrieu
15:45:16 <swcurran> manu: I think we should. Three similar issues about this.  Doesn't prevent DID Methods from having their own approaches, but we should try to get a consistent approach. Could be a long discussion, but without that we will get interop issues.
15:45:57 <manu> q+
15:46:39 <ottomorac> ack manu
15:46:45 <swcurran> JoeAndrieu: I think we need to do it. Markus had doubts, happy Manu is for it.  Should try to figure out, because there are lots of ways to do it, some in production. Differences in the DID Linked Resources, where is the data about the resource -- DIDDoc or Metadata or path?
15:47:12 <swcurran> manu: Hope is that 181 proposal is not in conflict.  Special topic call to explore this as Joe suggested is a good idea.
15:47:36 <swcurran> ottomorac: Chairs to discuss and set a deep-dive session time.
15:47:51 <ottomorac> Subtopic: Should the HTTPS binding be mandatory? #93
15:47:56 <ottomorac> https://github.com/w3c/did-resolution/issues/93
15:48:12 <ottomorac> Raises the question of whether an HTTPS binding—the ability for resolvers to expose a DID resolution endpoint over HTTPS—should be mandatory
15:48:38 <manu> q+
15:48:49 <ottomorac> There was broad agreement that the decision on whether such a binding should be mandatory should reside with the DID controller or be exposed as metadata—rather than baked into every DID method—though opinions differed on whether this requirement belongs in DID Core given its more maintenance‑mode status
15:49:12 <ottomorac> ack manu
15:50:57 <Wip> q+
15:50:58 <swcurran> manu: Thinks that it should be mandatory because otherwise how do you test anything. It is the only interface in the spec. Not sure how this impacts the DID Controller. Not bad to use DNS or DNS infra, DNS allows for getting a TLS Cert for an IP. Seems like not a big ask to require endpoint over HTTPS and we need something that is testable.
15:51:05 <ottomorac> ack Wip
15:51:28 <manu> q+
15:51:40 <ottomorac> ack manu
15:51:41 <swcurran> Wip: What is the concrete action we need to take.  Need something in the spec and who will do that?
15:52:17 <Wip> q+
15:52:37 <swcurran> manu: Is in the HTTPS binding section that HTTPS is mandatory, others may be provided. Mandatory to use TLS, but not DNS.  Can use Let's Encrypt-style IP certs. PR is needed.
15:52:47 <ottomorac> ack Wip
15:53:08 <manu> q+
15:53:25 <ottomorac> ack manu
15:53:27 <swcurran> Wip: It is mandatory for resolvers -- all resolvers -- to be considered compliant. Or is it that DID Methods provide an implementation with HTTPS binding?
15:54:34 <Wip> q+
15:55:12 <ottomorac> ack Wip
15:55:13 <swcurran> manu: No connection between DID Resolution and DID Methods. Don't think there is a connection. If we don't mandate some interface, the TAG and reviewers will say nothing is testable. How are you testing this?   Response is to say HTTPS by most implementations, but...  Better to mandate and see if anyone complains about why they won't do it.
15:55:37 <manu> q+
15:55:57 <ottomorac> ack manu
15:56:03 <swcurran> Wip: Makes sense.  Anyone else care about this?  Implementors that just implement a library, but not an implementation don't care about it. But if this the route, let's do it.
15:57:13 <swcurran> manu: We could deal with this with a classes of implementation.  Could provide the nuance that separates out libraries from resolvers deployments that includes HTTPS and all of the criteria. Two conformance classes -- library and more than a library that conforms.
15:57:14 <Wip> q+
15:57:21 <ottomorac> ack Wip
15:57:28 <JoeAndrieu> q+ to speak to small device use cases in addition to libraries
15:58:04 <ottomorac> ack JoeAndrieu
15:58:04 <Zakim> JoeAndrieu, you wanted to speak to small device use cases in addition to libraries
15:58:09 <swcurran> Wip: That makes good sense.  I also don't want to take this on. If no one takes this, then we will wind up repeating this conversation.
15:59:05 <manu> q+
15:59:11 <ottomorac> ack manu
15:59:11 <swcurran> JoeAndrieu: I like Manu's suggestion of classes.  Constrained devices class where they don't want to deal with the TLS stack. Could secure the context with Data Integrity. Not sure that is needed.
15:59:49 <swcurran> manu: As long as we need it open, and not saying they can't do that.  May want to in version 1.1 to clarify further. Spec won't stop them from doing it.
16:00:03 <swcurran> ottomorac: I'll take this one.  With help from the community.
16:01:06 <TallTed> TallTed has joined #did
16:03:08 <ottomorac> rrsagent, make minutes
16:03:09 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/21-did-minutes.html ottomorac
16:04:15 <ottomorac> m2gbot, link issues with transcript
16:04:16 <m2gbot> comment created: https://github.com/w3c/did/issues/901#issuecomment-3211228442
16:04:17 <m2gbot> comment created: https://github.com/w3c/did/issues/903#issuecomment-3211228491
16:04:18 <m2gbot> comment created: https://github.com/w3c/did/issues/898#issuecomment-3211228563
16:04:19 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/180#issuecomment-3211228600
16:04:20 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/156#issuecomment-3211228641
16:04:21 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/93#issuecomment-3211228679
16:04:35 <ottomorac> zakim, end the meeting
16:04:35 <Zakim> As of this point the attendees have been KevinDean, ottomorac, swcurran, Wip, brent, ivan, denkeni, JennieM, smccown
16:04:37 <Zakim> RRSAgent, please draft minutes
16:04:38 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/21-did-minutes.html Zakim
16:04:44 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
16:04:45 <Zakim> Zakim has left #did
16:04:55 <ottomorac> RRSAgent, please excuse us
16:04:55 <RRSAgent> I see no action items