Meeting minutes
<TallTed> /www.w3.org/2025/07/27-did-minutes.html/previous meeting: https://
<TallTed> s|2025/07/27-did-minutes.html |2025/07/24-did-minutes.html |
Agenda Review, Introductions
Wip: Feel free to introduce yourself Junlin (from ANT Group, Alipay), on voice or chat, if you'd like.
Wip: We're focusing on DID Resolution, we have an upcoming special topic call.
Special Topic Call for Test Suite 6th of August
Wip: Next Wednesday, we'll focus on DID Resolution test suite. Every other week is probably too fast for test suite -- we have some momentum, let's build on it.
Wip: Let's try to select 1-5 statements to build infra around, that's the goal.
Wip: Any questions/comments before we move on?
DID Resolution PR Processing
Wip: We have some open PRs for DID Resolution.
<Wip> https://
<Wip> w3c/
w3c/did-resolution#164
Wip: This is about metadata, editorial refactor
Wip: Consolidates two sections into a single section.
markus_sabadello: What you said is correct, we're rearranging some of the sections. Ted had some suggestions about headings/titles of subsections. I proposed to not change that. Ted said it was fine to live with -- if no one is opposed, we can merge. It doesn't change any functionality.
<JoeAndrieu> +1
Wip: Anyone think we should do what Ted's suggesting?
w3c/did-resolution#165
Wip: Not seeing anyone else on queue, moving on.
Wip: This is adding informative text as well
markus_sabadello: Yes, and YAML OpenAPI definition, Ted had some suggestions to improve which were committed. This is already ready to merge.
w3c/did-resolution#167
Wip: Would be good to get extra review if folks have time
Wip: This clarifies that you can use HTTPS in a local set up. Ted has some updates here.
markus_sabadello: This is about section in spec on local bindings... we talk about remote bindings in spec, insight was that HTTPS binding can be remote or local (for example for localhost), small change.
markus_sabadello: Ted you had comment about certificates and running on local network/VPN, not sure if that's part of this PR or what kind of change/language we could add. This topic of TLS/VPN has more to do with issues about how to trust resolver and threat modelling that Joe has been talking about. Maybe we can merge this PR which is about HTTP can be local or remote, not just remote, topic of TLS and VPN we should consider, but maybe in a separate PR.
TallTed: We're advising people to use HTTPS but my understanding is that requires a certificate that comes from somewhere -- selfissued is required for internal networks, or a CA, which is typically used on routable network -- as general advice it's probably fine to say HTTP/S, if we don't give some guidance for TLS on internal space that they're going to bang their head against a wall.
markus_sabadello: I agree with what TallTed said, this PR is just about local vs. remote.
<Wip> +1 to a new issue
TallTed: Maybe we can just turn it into a new issue?
markus_sabadello: Yes, let's do that, new issue... and merge this PR.
w3c/did-resolution#171
Wip: This one is about no-cache and DDoS, we might want to raise this as an error code in errors section.
Wip: Should we merge and create new issue for error code?
markus_sabadello: I think that would be fine -- new issue/error when request is rejected.
Wip: ok, those are all the open PRs, moving on...
Support numbers in metadata structures
w3c/did-resolution#166
Wip: This is about adding numbers in metadata resolution results.
markus_sabadello: I don't know why we wrote it like this originally.
Manu: I think we did it this way just for completeness, JSON-LD does make a differentation, that is why we have the lists and sets....
Manu: We don't support numbers because if you use floating point numbers there is a chance that it will have failures with digital signatures...
Manu: this could create issues on calculations... so we require floating point numbers to be encoded in a string...
Manu: we can add number back in there, but restrict it to integer... but this would probably open the door to questions about supporting decimals...
<ivan> Infra view on numbers
Manu: So we have resorted to restricting things to strings and the supporting local casting of the string to a number locally...
Wip: is that documented anywhere?
<ivan> +1 to will
markus_sabadello: now I remember, wanted to add that the metadat structure is also used for the input options....
markus_sabadello: so this means that we cannot pass numbers as options in the inputs....
markus_sabadello: I think that makes sense, I remember why we did this now. We can't pass numbers as options in the input, which might be fine -- versionId and other options and metadata fields use strings instead of numbers. Maybe we don't have to change anything.
Wip: We could add some text that explains why numbers aren't supported. That should address this issue.
DID Resolution Issue Processing
w3c/did-resolution#144
Wip: This is the internationalization self-test that I did a bit ago.
Wip: What happens at this point?
manu: Yes we should just leave this issue open until the horizontal review happens....
manu: we can close it after they complete their review...
ivan: Maybe it's worth putting text in issue that says that this spec doesn't deal w/ human readable text, it's for machine-to-machine communication. I18N is not really relevant for this specification... but making that clear for i18n is helpful.
Wip: That's my sense, most of the questions were not applicable.
ivan: The same applies for a11y as well.
w3c/did-resolution#79
Wip: Christopher raised this issue, has many items.
Wip: What do we need to do to close this issue?
<ivan> it is already there
manu: Yes I think we just break the issue into another sub issues that may be required... sounds like we have created most of them.... We asked Chris A like 4 months ago....
<ivan> +1 to manu
manu: I think we can close and then Chris A can circle back with us if there is another issue that should be raised....
markus_sabadello: We could also leave it open until other issues have been addressed -- once we have one or more PRs, we could close at that point -- either way is fine.
<Zakim> JoeAndrieu, you wanted to suggest pending close
Wip: Maybe I'll ping Christopher one last time and mark pending close.
JoeAndrieu: That sounds good, we can @mention them and mark pending close and if he still cares to respond, he can.
ivan: Should I put the pending close label on?
Wip: Yes, and ping Christopher as well.
w3c/did-resolution#22
Wip: Signing validation is not defined... should we address or close the issue?
manu: One thing we could is not to define signing validation for now until we see a firm need in the ecosystem. Not sure if we have a strong need for signed resolution responses, we should allow vendors to create their own solutions and then we can standardize it....
manu: The other approach is to define one way of how signing validation is done, which would require a detailed discussion on how it should be done....
<Wip> w3c/
Wip: Chair hat off, I like option 1 -- feels like it should be an extension, at moment I don't think any resolvers do signing validation -- validation of series of updates on signatures. There is another issue 160, document the extension, how do resolvers attest to sign resolution responses they provide.
Wip: One thing I'm hearing is this is future work.
Wip: We have talked about it multiple times, we could move on at this point.
manu: One thing we could do is say we define a constrained method for instance data integrity JCS using ECDSA which is supported by most HSMs, and we are using that same mechanism already for did:webvh....
ivan: Maybe what I'm saying is naive, isn't it simpler to say you can create a VC on the data?
manu: yes we could say that, but then it just postpones the problem to later....
manu: We have interoperability problems and there are many different ways to define VCs....
manu: it gets into discussions around the structure and where the data is stored in the VC....
manu: if we want something truly interoperable we should be very specific of how it works...
<Zakim> JoeAndrieu, you wanted to mention about substantive input
manu: we need to be very specific about the structure of the VC and around the signature
<Wip> That is w3c/
JoeAndrieu: I think we should close this, Manu has some good points, but it's not this issue. I'd like you to create an issue to sign resolution results. This issue isn't what Manu's talking about.
JoeAndrieu: We should close this issue and have Manu restate the issue.
Wip: My read is signing validation of resolution as it goes through process other than what Manu was talking about. How do you verify a resolution result is very DID Method specific, each one does it in a different way.
<ottomorac> +1 yes it is a did method specific issue...
markus_sabadello: I agree with Will and Joe, this issue isn't what Manu was talking about... I also agree with what Manu was talking about, we do talk about it in the section of architecture. The resolution results could be signed, not elaborated, means to do it -- I thought the only thing we may want to do is add a sentence -- DID Methods could use signatures, signed documents, but that's all method specific.
markus_sabadello: That's what I remember from this issue.
markus_sabadello: I think we can close this issue.
w3c/did-resolution#163
Wip: I wonder if `created` property should be included -- don't know if people can rely on it?
markus_sabadello: This is about a broader question, who is authoritative for the values in the DID Document metadata, could be DID Method or controller, metadata like `created` information could come from DID Method, especially blockchain-based DID Methods.
markus_sabadello: There are other DID Methods where metadata could be self-asserted, with web-based DID Methods, in did:web, should it have metadata, could be file on webserver that comes from controller, not be DID Method that enforces that in any way... never really said much about that in spec. We could explain that a bit better, but I don't think it's specific to created property, larger question around metadata.
Wip: I wonder if we could add a Security Considerations about this, people might rely on metadata base don facts that they can depend on, some properties are more dependable than others.
Wip: If you have business processes that depend on that date being correct, you could be misled.
Wip: What do people think, should we add security consideration?
markus_sabadello: The spec already says that source of metadata can be DID Method or controller, but doesn't say what that means wrt. reliability. That makes sense to add a security considerations section to explain that.
Wip: I can take that PR on.
w3c/did-resolution#150
JoeAndrieu: We currently allow open ended additions to extensions registry -- you can have properties that modify parsing for DID Method, we have an avenue for incompatibility where a naieve DID controller could add properties from extensions and not realize they're breaking each other... one might use frament identifier, one might use query parameter... issue with linkedResources... different properties and different ways to put item in DID Document or
DID Document metadata.
manu: this might be limitting innovation a bit, even if it is friendly to implementers...
<Zakim> JoeAndrieu, you wanted to suggest self-labeling on submission
manu: We could limit the extensions that conflit to specific DID Methods.
JoeAndrieu: Maybe when we do the registration, we allow self-labeling on submission of the extension -- point out the conflicts.
Wip: Maybe we should add an issue on DID Extensions registry.
Wip: With that, we're done with today. We're going to do test suite discussion next wednesday, we'll also discuss horizontal review.
Wip: Thanks all, have a great week/weekend, see you next week!
<Wip> 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/
<m2gbot> comment created: w3c/
<m2gbot> comment created: w3c/