Meeting minutes
<KevinDean> https://
ottomorac: The agenda overview
Debrief Special Topic Call for DID Resolution Test Suite on 20-Aug
<manu> DID Resolution test suite base repo is here: w3c-ccg/
<manu> Current report is here: https://
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
DIDs to resolve. From there -- how to add more tests across the spec.
<Wip> Yup I agree. Testing the DID resolution spec, not DID methods
<Wip> This is the open issue we are looking at first - w3c-ccg/
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
there.
<manu> Minutes from that call are here: https://
Status Update on DID Methods WG Charter Review
ottomorac: Request feedback and provided. Minor cleanup needed regarding items in the Draft Charter. Wording, Success Criteria, Patent Disclosures adjustments needed. Corrections to chairs?
manu: Not sure where the feedback should go to get adjusted. Defer to Ivan, PA or Brent.
<ottomorac> need to remove Proposed Recommendation section
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.
Wip: No need to spend time. The chairs of that working group need to address the issues.
DID WG Timeline and Overall Status
ottormorac: To send to chairs with comments from here.
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.
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.
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
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.
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.
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.
manu: Good point. Are we under the new process?
ivan: Yes. Since 15th August.
manu: Other thing -- horizontal review hasn't been sent out. Takes 6-9 months so we're behind there.
@context URL in the spec: https://www.w3.org/ns/did/v1.1 does not resolve #901
<ottomorac> w3c/
<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.
<manu> We should make this resolve: https://
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.
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.
manu: Yes -- to take it offline to go through it.
<Wip> +1 having RC makes sense to me
<ottomorac> +1 makes sense
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.
@context is missing JsonWebKey and Multikey #903
<ottomorac> w3c/
<ottomorac> Issue opened by Markus. It seems the context https://
manu: Yes +1 to that. It's the right thing to do.
Is percent encoding the fragment (#) really conformant with the URI RFC? #898
<ottomorac> w3c/
<ottomorac> This is related to example 6 in the DID core spec, link: https://
<ottomorac> nowledged that the description could be improved—suggesting they will enhance the explanatory text around this subtle point.
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.
… : Avoid people asking this at this level of the spec -- hence DID Resolution. We have other fragment examples.
DID Resolution PRs
Update the Metadata Structure to include numbers with a caveat about representations #180
<ottomorac> w3c/
<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
<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.
<Wip> LGTM
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
manu: yes agree....
… the consensus is that we should just warn implementers but not put in any extra features...
ivan: do we need to check with the TAG on this?
manu: the TAG has approved infra, I don't think this will be required...
DID Resolution Issue Processing
swcurran: to note that the test suite should be updated, specifically the tests that fails if there is a number in resolution metadata
DID Resolution Issue Processing
Define how DID Methods can specify paths and their dereferencing rules #156
<ottomorac> w3c/
<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.
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?
<manu> w3c/
<manu> about a unified way to do path resolution
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.
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?
manu: Hope is that 181 proposal is not in conflict. Special topic call to explore this as Joe suggested is a good idea.
ottomorac: Chairs to discuss and set a deep-dive session time.
Should the HTTPS binding be mandatory? #93
<ottomorac> w3c/
<ottomorac> Raises the question of whether an HTTPS binding—the ability for resolvers to expose a DID resolution endpoint over HTTPS—should be mandatory
<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
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.
Wip: What is the concrete action we need to take. Need something in the spec and who will do that?
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.
Wip: It is mandatory for resolvers -- all resolvers -- to be considered compliant. Or is it that DID Methods provide an implementation with HTTPS binding?
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.
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.
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.
<Zakim> JoeAndrieu, you wanted to speak to small device use cases in addition to libraries
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.
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.
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.
ottomorac: I'll take this one. With help from the community.
<ottomorac> m2gbot, link issues with transcript
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/