14:58:42 <RRSAgent> RRSAgent has joined #did
14:58:47 <RRSAgent> logging to https://www.w3.org/2025/04/24-did-irc
14:58:53 <ottomorac> rrsagent, draft minutes
14:58:54 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/24-did-minutes.html ottomorac
14:59:00 <ottomorac> rrsagent, make logs public
14:59:06 <ottomorac> Meeting: Decentralized Identifier Working Group
14:59:16 <ottomorac> Chair: ottomorac
14:59:44 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Apr/0008.html
15:00:56 <TallTed> present+
15:01:02 <ottomorac> present+
15:01:10 <TallTed> previous meeting: https://www.w3.org/2025/04/17-did-minutes.html
15:01:12 <TallTed> next meeting: https://www.w3.org/2025/05/01-did-minutes.html
15:03:01 <denkeni> present+
15:03:59 <Wip> scribe+
15:04:29 <manu> present+
15:04:38 <ottomorac> Topic: DID Rubric & Traits Special Topic Call - 30th of April
15:05:14 <Wip> ottomorac: We will be continuing the discussion around DID Rubric and traits. Figuring out the next steps for integrating this work
15:05:16 <ivan> present+
15:05:16 <Wip> q?
15:05:33 <ottomorac> Topic: Allow verification method identifiers to be HTTPS URLs?
15:05:38 <ottomorac> https://github.com/w3c/did/issues/879
15:05:43 <manu> q+
15:05:57 <dmitriz> dmitriz has joined #did
15:06:06 <Wip> ottomorac: Current DID documents do not allow other the DID URLs to be IDs for verification methods
15:06:13 <Wip> ... This issue tracks if we should change this
15:06:15 <ottomorac> ack manu
15:06:19 <JoeAndrieu9> q+ to say we should let the CID spec define that
15:06:32 <markus_sabadello> markus_sabadello has joined #did
15:06:36 <markus_sabadello> present+
15:06:39 <Wip> manu: This came up because the controlled identifier spec talks about https URLs
15:06:44 <TallTed> i|DID Rubric and traits. Figuring|https://www.w3.org/events/meetings/7fcaaebc-61ac-4f87-921d-accdb271496a/20250430T100000/
15:06:47 <Wip> ... it uses them for its IDs
15:07:09 <Wip> ... Since then we have moved the CID spec through the standard process. It will become a formal standard
15:07:20 <Wip> ... Some feedback was, why do we have the CID spec again..
15:07:34 <Wip> ... It is true the DID spec can do all the CID spec can
15:07:43 <Wip> ... did:web can do all that the CID spec can
15:08:13 <Wip> ... So applying that to this issue, I think the answer is no because if someone wants to refer to a https based verification method they can just use did:web or its variations
15:08:15 <ottomorac> ack JoeAndrieu
15:08:15 <Zakim> JoeAndrieu, you wanted to say we should let the CID spec define that
15:08:46 <Wip> JoeAndrieu: +1 to manu, we should not water now our security guarantees. CID spec was a compromise
15:08:50 <ottomorac> q?
15:08:59 <manu> q+
15:09:15 <ottomorac> ack manu
15:09:21 <Wip> manu: To be clear, this means no spec changes. The text stays as is
15:09:31 <ottomorac> Topic: Guidance on Normalization Rules Enforcement
15:09:38 <ottomorac> https://github.com/w3c/did/issues/842
15:09:41 <JennieM> JennieM has joined #did
15:09:56 <Wip> ottomorac: This issue relates to string URIs in the serviceEndpoint property
15:10:10 <Wip> ... manu requested we use the WHATWG working group spec for normalization
15:10:15 <dmitriz> present+
15:10:27 <manu> q+
15:10:37 <KevinDean> KevinDean has joined #did
15:10:40 <KevinDean> present+
15:10:50 <Wip> ... KevinDean proposed a direction
15:11:20 <Wip> q?
15:11:27 <ottomorac> ack manu
15:11:59 <JennieM1> JennieM1 has joined #did
15:12:06 <KevinDean> q+
15:12:08 <Wip> manu: On the proposal from KevinDean, a couple of things to talk about
15:12:27 <smccown> smccown has joined #did
15:12:31 <Wip> ... First, what would it take to move the CID spec into this group. Trying to keep these specs aligned in different working groups and timelines is very difficult
15:12:40 <smccown> present+
15:12:56 <JennieM1> present+
15:12:57 <Wip> ... Second. The problem with URIs is we should move to the URL spec because the browser vendors have effectively killed URIs
15:13:18 <ivan> +1 to manu on URL vs URI/IRI
15:13:20 <Wip> ... I think using URIs and RFC3986 is not the best direction. It is the URL spec that WHATWG is in control of
15:13:23 <JoeAndrieu9> also endpoints must have an end, i.e., they actually must be locators (URLs) not just identifiers (URIs)
15:13:29 <smccown> +1 for moving to URLs
15:13:35 <Wip> ... I don't know about the normalization rules, will check the CID spec
15:13:49 <Wip> ... I think there are some normalization rules in the URL standard. If there are we can just use those
15:14:02 <Wip> ... If not we cannot use RFC3986. There will be all sorts of interop issues
15:14:12 <Wip> ... That is why the URL standard was created to address these
15:14:21 <JennieM> JennieM has joined #did
15:14:51 <Wip> ... I understand where you are trying to go Kevin. I think the longterm path is to move the CID spec into this group
15:15:02 <KevinDean> KevinDean has joined #did
15:15:06 <KevinDean> present+
15:15:07 <KevinDean> q+
15:15:12 <ottomorac> ack KevinDean
15:15:16 <Wip> * notes scribe lost audio
15:15:39 <ottomorac> scribe+
15:15:40 <manu> q+
15:15:54 <ivan> /me there is an URL equivalence in the URL spec: https://url.spec.whatwg.org/#url-equivalence I did not see normalization
15:16:00 <ottomorac> Kevin: there is not hard and fast set of rules for URL normalization....
15:16:25 <ivan> q+
15:16:40 <ottomorac> scribe-
15:16:51 <ottomorac> Kevin: happy to close this
15:17:07 <ottomorac> Kevin: once we have control of the CID spec we can change it later
15:17:11 <ottomorac> ack manu
15:17:34 <Wip> manu: To answer the first question KevinDean asked. A DID is a URL per the definition of a URL in the URL standard
15:17:49 <Wip> ... I searched for the words canonicalization and normalization in the URL standard and they don't exist.
15:17:54 <KevinDean> q+
15:18:05 <Wip> It says the spec defines canonical forms of ***
15:18:26 <Wip> ... The only examples I can see they give is for the windows drive path.
15:18:48 <Wip> ... There is a bunch of code point canonical rules e.g. % encoding
15:18:59 <Wip> ... You could argue there are normalization and canonicalization rules in the URL standard
15:19:16 <Wip> ... If it is not defined in the URL spec, then the DID spec is not going to define additional rules
15:19:17 <JoeAndrieu9> q+ to mention "serializers"
15:19:26 <JoeAndrieu9> https://url.spec.whatwg.org/
15:19:37 <Wip> ... in the CID spec we currently do the right thing. We said the ID value must be a URL conforming to the URL standard
15:19:53 <Wip> ... We do say URI, I think mistakenly in the also known as
15:20:03 <Wip> ... This is the wrong thing if we want to say everything is a URL
15:20:47 <Wip> ... We might want to add to the spec to say, that all rules for normalization and canonicalization are defined in the URL standard. That addresses this issue
15:20:51 <ottomorac> ack ivan
15:21:25 <Wip> ivan: I also didnt find normalization in the URL spec.
15:21:37 <manu> q+ to say, yes to a recharter - eventually :)
15:21:55 <ottomorac> ack KevinDean
15:21:57 <Wip> ... To take on the CID spec to be maintained, would require rechartering this WG
15:22:40 <ottomorac> ack JoeAndrieu
15:22:40 <Zakim> JoeAndrieu, you wanted to mention "serializers"
15:22:43 <Wip> KevinDean: Given that the URL spec is meant to replace the URI spec, it is removing the normalization guidance provided in this spec
15:23:15 <ottomorac> ack Manu
15:23:15 <Zakim> manu, you wanted to say, yes to a recharter - eventually :)
15:23:16 <Wip> JoeAndrieu: In the URL spec, I think the define parsers and serializers. And serializers are handling the normalization, just not using those terms
15:23:29 <Wip> ... +1 to referring to that spec and removing a reference to URIs
15:24:01 <Wip> manu: +1 to ivan and JoeAndrieu. There are enough algorithms in here for people to look at recognise that these are canonicalization rules
15:24:26 <Wip> ... KevinDean's point is interesting, but again all browser vendors dont implement that stuff anymore
15:24:44 <dmitriz> q+
15:24:45 <Wip> ... Also, if you have a URL and that URL has query parameters. Position matters for those parameters now
15:25:05 <Wip> ... I don't think this changes anything. I still think we can point to the URL standard for the rules to address this issue
15:25:23 <Wip> ... Also, responding to ivan. Totally agree that we would have to recharter to take on the CID spec.
15:25:33 <Wip> ... This is a long term thing. In our next recharter we should do that.
15:25:48 <Wip> ... The best time to do that might be when we charter the DID method work
15:26:00 <ottomorac> ack dimitriz
15:26:03 <Wip> ... We could send them both out in the same vote
15:26:19 <dmitriz> q-
15:26:23 <Wip> dmitriz: minor point, removing myself from queue
15:26:38 <Wip> ottomorac: Seems like we have some direction on this issue, thanks
15:26:45 <ottomorac> Topic: DID Resolution Architecture Issues Discussion
15:26:55 <ottomorac> https://github.com/w3c/did-resolution/issues/79
15:27:13 <Wip> q+
15:27:22 <ottomorac> scribe+
15:27:55 <ottomorac> subtopic: Add examples to illustrate different DID Resolution Architectures #131
15:28:05 <ottomorac> Subtopic: Add examples to illustrate different DID Resolution Architectures #131
15:28:10 <ottomorac> https://github.com/w3c/did-resolution/issues/131
15:28:16 <markus_sabadello> q+
15:28:20 <Wip> q-
15:28:21 <ottomorac> ack Wip
15:28:31 <ottomorac> ack markus_sabadello
15:28:54 <Wip> markus_sabadello: This is a good idea. To add some more concrete diagrams for different architectures
15:29:29 <ottomorac> scribe-
15:29:31 <ottomorac> q?
15:29:33 <Wip> ... The current architecture section covers some concepts. Mentioning local and remote resolvers. And talks about how the read operation can be verified or not verified. There are some diagrams in the section right now, but all of it needs some more work
15:29:45 <markus_sabadello> https://github.com/w3c/did-resolution/pull/143
15:29:54 <Wip> ... The diagrams that exist right now are quite high level. There is an open PR that updates these diagrams
15:30:16 <ottomorac> (link to diagrams from Markus)
15:30:28 <Wip> ... This PR 143, adds additional diagrams for more concrete architecture
15:31:08 <Wip> ... For example the different ways that resolution against the bitcoin network could be implemented
15:31:13 <ottomorac> q?
15:31:18 <Wip> +1 that looks great markus_sabadello
15:31:46 <manu> q+
15:31:52 <ottomorac> ack manu
15:32:05 <Wip> manu: Just a quick note on the diagrams markus
15:32:24 <Wip> ... We are going to be required to add accessible descriptions for them. We would fail the accessibility review without those
15:32:39 <markus_sabadello> q+
15:32:50 <ottomorac> ack markus_sabadello
15:33:23 <manu> q+
15:33:25 <Wip> markus_sabadello: Another thing I am doing in this PR, is changing to svg files. These include a short caption about what the image is
15:33:28 <ottomorac> ack manu
15:33:32 <Wip> ... Wondering if that is enough
15:33:48 <Wip> manu: My experience is they require us to indetail describe what is in the picture
15:34:43 <Wip> ... you have to describe to someone who cannot see literally what is on the screen
15:35:03 <Wip> ... not sure if that has changed, but i doubt it
15:35:07 <ottomorac> Subtopic: Complete threat modelling analysis for different DID Resolution architectures #132
15:35:12 <ottomorac> https://github.com/w3c/did-resolution/issues/132
15:35:26 <ottomorac> scribe+
15:36:03 <JoeAndrieu9> q+ to discuss threat modeling
15:36:16 <ottomorac> Wip: yes, I think this came up on our discussion before....  The diagrams describe different architectures, it would be good to do an analysis of each and this could fit into the security considerations....
15:36:23 <markus_sabadello> q+
15:36:28 <ottomorac> ack: JoeAndrieu
15:36:36 <ottomorac> scribe-
15:36:42 <ottomorac> ack JoeAndrieu
15:36:42 <Zakim> JoeAndrieu, you wanted to discuss threat modeling
15:36:50 <Wip> JoeAndrieu: +1 to making it a separate note. We dont want to be concerned about making it concise
15:37:09 <Wip> ... I think it makes sense to look at each of those architectures and break down the threats
15:37:15 <Wip> ... I am keen to help with that work
15:37:37 <Wip> ... The plans for the security interest group is to great a guide for all groups to do some threat modelling as part of their spec development work
15:37:43 <Wip> ... Getting ahead of this is a good idea
15:37:44 <ottomorac> ack markus_sabadello
15:38:04 <Wip> markus_sabadello: Wondering if it is a separate note, why would we still have a security considerations in the main specification
15:38:18 <Wip> ... I would have thought this would go into the security consideration section
15:38:28 <JoeAndrieu9> q+ to say good question
15:38:33 <Wip> ... Not really sure what the difference would be between the note and the security section
15:38:34 <ottomorac> ack JoeAndrieu
15:38:34 <Zakim> JoeAndrieu, you wanted to say good question
15:38:56 <Wip> JoeAndrieu, thats a good question. Still trying to figure it out. I do think there are security considerations that would not be part of threat modelling
15:39:14 <Wip> ... Simone is still figuring out what threat modelling would mean for the W3C groups
15:39:34 <Wip> ... My invitation to the group is lets help figure out what this means by applying it to our spec
15:39:37 <Wip> q+
15:39:46 <ottomorac> ack Wip
15:40:21 <ottomorac> Wip:  yes my sense is that a separate document could then inform the security considerations , we can figure it out
15:40:29 <ottomorac> Subtopic: Add DID Resolution architecture security and privacy considerations #133
15:40:46 <ottomorac> https://github.com/w3c/did-resolution/issues/133
15:40:53 <ottomorac> scribe+
15:41:21 <markus_sabadello> q+
15:41:21 <JoeAndrieu9> q+
15:41:26 <ottomorac> Wip: not much more to add to it...  main thing is what considerations do implementers of the resolvers need to have in mind
15:41:31 <ottomorac> scribe-
15:41:38 <ottomorac> ack markus_sabadello
15:41:51 <Wip> markus_sabadello: In the current section about architectures there are some short comments about some of these considerations
15:42:23 <Wip> ... For example there is a sentence that says when you use a remote resolver service you could use a VPN. Or some form of authentication. Or query multiple resolvers to check results
15:42:46 <Wip> ... These ideas probably need to be expanded and elaborated on so they can be added into the security considerations section
15:42:50 <ottomorac> ack JoeAndrieu
15:42:51 <JoeAndrieu9> RFC 3552 Guidelines for Writing RFC Text on Security Considerations
15:43:23 <Wip> JoeAndrieu: I think we should improve our guidance for what should go in security and privacy consideration section
15:44:03 <Wip> ... In our work with Simone we have incorparated RFC 3552. I think we should point DID method implementers to this RFC or additional guidance for writing these sections
15:44:10 <ottomorac> Subtopic: Update future work section #134
15:44:18 <ottomorac> https://github.com/w3c/did-resolution/issues/134
15:44:26 <ottomorac> scribe+
15:44:41 <ottomorac> Wip: yes this also came out of our discussion with ChristopherA...
15:44:43 <smccown> Is RFC 3552 the newest document?  The spec I'm finding is dated 2003
15:45:08 <JoeAndrieu9> (not sure Steve. It's the one Simone referred me to)
15:45:11 <ottomorac> Wip:  one option could be we remove the section completely, or perhaps we update and add some new future items....
15:45:28 <ottomorac> Wip: interested in what the group thinks?
15:45:32 <JoeAndrieu9> q+
15:45:32 <ottomorac> scribe-
15:45:38 <ottomorac> ack JoeAndrieu
15:45:47 <markus_sabadello> q+
15:45:50 <Wip> JoeAndrieu: I think we should keep this issue around. We are early in our cycle to know whats future
15:46:02 <Wip> ... Lets circle back to this when we are closer to the finish line
15:46:04 <ottomorac> ack markus_sabadello
15:46:18 <Wip> markus_sabadello: I agree with JoeAndrieu. Lets come back to this
15:46:43 <Wip> ... We have discussed in the last few meetings some enhancments but put them as issues in the extensions registry
15:47:10 <Wip> ... Other topics we arent sure yet how and if we might incorporate them into this spec
15:47:30 <Wip> ... For example Christophers work on gordian and selective disclosure etc
15:47:47 <ottomorac> Topic: Should we use JSON or JSON-LD for the resolution spec?
15:47:55 <ottomorac> https://github.com/w3c/did-resolution/issues/137
15:48:20 <manu> q+
15:48:21 <Wip> ottomorac: Briefly touched on this in the APAC call. manu voiced wanting to just use JSON
15:48:23 <ottomorac> ack manu
15:48:27 <ottomorac> scribe-
15:48:53 <Wip> manu: Yep, since them markus_sabadello has mentioned that a benefit of using JSONLD means you could fully digitally sign the response that came back.
15:49:01 <Wip> ... Resolvers could sign all their responses
15:49:07 <Wip> ... I found this compelling as an argument
15:49:24 <Wip> ... Wondering if we could through data integrity still use JSON and use JCS based signatures instead
15:49:39 <Wip> ... We could optionally express this response using JSONLD
15:50:09 <Wip> ... Meaning we could keep it JJSON, Use data integrity with JCS to sign the responses. And not flat our require JSONLD processors
15:50:22 <ivan> s/JJSON/JSON/
15:50:26 <Wip> ... Trying to find a way to define DID resolution responses in JSON
15:50:52 <Wip> ... We almost certainly will have a context. If we do that, we should probably change the context from v1 to v1rc1
15:51:08 <Wip> ... We have found people will ship v1 to production so the group can't easily change the context
15:51:14 <Wip> ... This creates confusion
15:51:15 <ivan> q+
15:51:44 <Wip> ... Lets use v1rc1 for all examples in the spec to contain some of these issues
15:52:02 <Wip> q+
15:52:10 <ottomorac> ack ivan
15:52:12 <markus_sabadello> q+
15:52:49 <Wip> ivan: Not sure I understand manu. First, I raised this issue a while ago. I think what manu said about using JCS is fine. We can and should use it. That should not be enough of an argument to turn it into JSONLD every time
15:52:49 <dmitriz> dmitriz has joined #did
15:52:54 <manu> q+
15:53:06 <ottomorac> ack Wip
15:53:18 <Wip> ... Not sure I understand how the context file comes into the picture. If using JSON there is no context
15:53:54 <Wip> manu: ivan using the context file is about trying to find a middle ground. So people that dont like jcs or rdfc can both be happy
15:54:23 <ivan> q+
15:54:26 <Wip> ... It would be nice if we could digitally sign the responses from the resolver. If we use data integrity and jcs we dont have to go to rdf
15:54:39 <Wip> ... This doesnt mean that DID resolvers cant also use a different data integrity mechanism
15:54:59 <Wip> ... We don't want to cut ourselves off from future usecases. We say please include the context. Here it is
15:55:08 <Wip> ... If we do that, then I think we leave all options open
15:55:26 <manu> q-
15:55:57 <ottomorac> ack markus_sabadello
15:56:07 <manu> q+ on including signing.
15:56:23 <Wip> markus_sabadello: We don't currently talk about signing resolution responses in the spec. But it has come up in the discussion
15:56:57 <Wip> ... Commenting on manu, if we use jcs then there is no graph canonicalization. However, I thought if you use data integrity with jcs you would still only do that with jSONLD document.
15:57:04 <Wip> ... didnt realise you could do that with place JSON
15:57:15 <Wip> s/place/plain/
15:57:38 <dmitriz> @markus - that's the cool thing about JCS canon -- you can use it without @context! :)
15:57:57 <Wip> In verifiable presentations you use JSONLD. VPs contain VCs which are JSONLD. In my mind DID document and resolution results work ion a simlar way
15:58:02 <ottomorac> ack ivan
15:58:51 <Wip> ivan: What manu is saying, if we introduce a context then we are using JSONLD. We have to define formally a vocab. Adding complexity. Implementers will see that a context is necessary. Some will complain that they dont want to use JSONLD etc etc
15:59:04 <Wip> ... For applications like VC, there are good arguments why JSONLD is useful
15:59:26 <Wip> ... For something else, like resolution, the resolution data that you use is not combined with other data
15:59:42 <JoeAndrieu9> q+ to say once we start signing it becomes an open system unless we restrict the signing to a specific algorithm
15:59:44 <Wip> ... if you are not combining, then rdf is not necessary
15:59:46 <ottomorac> ack manu
15:59:46 <Zakim> manu, you wanted to comment on including signing.
15:59:53 <Wip> zakim, close the queue
15:59:53 <Zakim> ok, Wip, the speaker queue is closed
16:00:11 <Wip> manu: agree with ivan. With DID resolution I am not sure if this is true
16:00:14 <smccown> JSONLD is really useful.  However, from a security perspective, the "linked" parts never seem to be covered by signatures.
16:00:22 <Wip> ... I am just trying to keep the door open
16:00:50 <JoeAndrieu9> once we start signing it becomes an open system unless we restrict the signing to a specific algorithm
16:00:52 <JoeAndrieu9> q-
16:00:56 <Wip> manu: we might want to include signing in the DID resolution spec. It keeps coming up
16:01:05 <Wip> ... We should say it is possible to sign these things
16:01:33 <ottomorac> rrsagent, make minutes
16:01:35 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/24-did-minutes.html ottomorac
16:02:52 <dmitriz> dmitriz has joined #did
16:03:18 <ottomorac> m2gbot, link issues with transcript
16:03:19 <m2gbot> comment created: https://github.com/w3c/did/issues/879#issuecomment-2828150179
16:03:20 <m2gbot> comment created: https://github.com/w3c/did/issues/842#issuecomment-2828150214
16:03:21 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/79#issuecomment-2828150245
16:03:22 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/131#issuecomment-2828150287
16:03:23 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/132#issuecomment-2828150332
16:03:24 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/133#issuecomment-2828150367
16:03:25 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/134#issuecomment-2828150414
16:03:26 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/137#issuecomment-2828150455
16:04:14 <ottomorac> zakim, end the meeting
16:04:14 <Zakim> As of this point the attendees have been TallTed, ottomorac, denkeni, manu, ivan, markus_sabadello, dmitriz, KevinDean, smccown, JennieM
16:04:17 <Zakim> RRSAgent, please draft minutes
16:04:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/04/24-did-minutes.html Zakim
16:04:24 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
16:04:24 <Zakim> Zakim has left #did
16:06:07 <ottomorac> RRSAgent, please excuse us
16:06:07 <RRSAgent> I see no action items