14:53:10 <RRSAgent> RRSAgent has joined #did
14:53:14 <RRSAgent> logging to https://www.w3.org/2025/06/19-did-irc
14:54:27 <ottomorac> rrsagent, draft minutes
14:54:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/19-did-minutes.html ottomorac
14:54:40 <ottomorac> rrsagent, make logs public
14:54:48 <ottomorac> Meeting: Decentralized Identifier Working Group
14:54:58 <ottomorac> Chair: ottomorac
14:55:39 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Jun/0006.html
14:57:38 <Wip> Wip has joined #did
15:00:40 <Wip> present+
15:01:34 <KevinDean> KevinDean has joined #did
15:01:37 <KevinDean> present+
15:02:14 <pchampin> present+
15:02:16 <JoeAndrieu> JoeAndrieu has joined #did
15:02:19 <ottomorac> present+
15:02:32 <markus_sabadello> markus_sabadello has joined #did
15:02:35 <markus_sabadello> present+
15:02:37 <ivan> present+
15:02:52 <JoeAndrieu> present+
15:05:49 <Wip> scribe+
15:06:53 <ottomorac> Topic: Announcement: Cancelling APAC calls for now
15:07:23 <Wip> ottomorac: Will and I have been discussion what to do around APAC with participants from APAC
15:07:38 <Wip> ... For the next few months we are going to cancel the APAC calls
15:08:05 <Wip> ... We are exploring the possibility of organizing some APAC friendly events in the run up to TPAC
15:08:20 <Wip> ... We will be switching back to the usual time for those weeks
15:08:23 <Wip> q+
15:08:49 <ottomorac> ack Wip
15:08:50 <JennieM> JennieM has joined #did
15:08:53 <ottomorac> scribe+
15:08:56 <JennieM> present+
15:08:57 <Wip> JoeAndrieu: Its a hard problem. Appreciate we tried the alternate time. Not sure there are any real good solutions. Appreciate the effort
15:10:01 <ottomorac> Wip: Agree its a hard problem. We have been talking with Denken and Shigeya, we are looking at some ways to re-engage through CCG (in an APAC friendly time).  Also looking to use TPAC as an opportunity for that.
15:10:05 <ottomorac> scribe-
15:10:41 <Wip> ottomorac: We have reached out to Kim about the DIF APAC group. Kim mentioned they tend to be more use case focus. Might not get much interest.
15:11:18 <Wip> ... Once we have a clear plan of events we may be about to use DIF to distribute this further
15:11:21 <Wip> +1
15:11:33 <ottomorac> q?
15:12:02 <ottomorac> Topic: Possible denial of service issue
15:12:06 <ottomorac> https://github.com/w3c/did-resolution/issues/92
15:12:16 <ottomorac> Topic:   DID Resolution Test Suite Special Topic Call
15:12:20 <ottomorac> https://github.com/w3c/did-resolution/issues/92
15:12:22 <Wip> q+
15:12:33 <ivan> s/Topic: Possible denial of service issue//
15:12:44 <ottomorac> scribe+
15:13:04 <ottomorac> Wip:  I have extracted the  normative statements, approximately 80. Probably need a special topic call to deep dive into how to test the statements.
15:13:37 <ottomorac> Wip: So that those interested can engage, we can review the statements and refine them as well as determining how to test them.
15:13:54 <ottomorac> Wip: Candidate date is July 9th.
15:13:59 <ottomorac> scribe-
15:14:14 <Wip> q?
15:14:15 <Wip> q-
15:14:23 <ottomorac> Topic: Possible denial of service issue
15:14:30 <ottomorac> https://github.com/w3c/did/issues/897
15:14:58 <Wip> ottomorac: this issue is about a possible denial of service raised by Victor Dodds
15:15:16 <Wip> ... It regards to the potential for infinite resolution in his interpretation of how the controller property is used
15:15:28 <Wip> q+
15:15:41 <ottomorac> ack Wip
15:15:51 <ottomorac> scribe+
15:16:44 <ottomorac> Wip: suggest that folks read, it touches on the fact the controller property is used in various places in the spec and perhaps is not well understood.
15:16:50 <KevinDean> q+
15:16:57 <ottomorac> scribe-
15:17:43 <Wip> JoeAndrieu: We did have language that embodied the algorithm described to use verification methods from DIDs
15:17:56 <Wip> ... This lead to an arbitrary and confusing security whole in the spec
15:18:01 <Wip> ... Hence removing it
15:18:07 <KevinDean> s/whole/hole/
15:18:21 <Wip> ... RIght not the controller property does have some confusing bits about self referentiability and whether that makes sense
15:18:26 <Wip> ... The meaning of that is under specified.
15:18:44 <Wip> ... We also have a issue with the controller property in the verificationMethod
15:18:55 <ottomorac> s/RIght not/Right now/
15:19:01 <ivan> q+
15:19:06 <Wip> ... A verificationMethod has a key specified and it also has a controller specified. What does it mean if these are not the same entities
15:19:11 <ottomorac> ack KevinDeean
15:19:45 <Wip> KevinDean: I don't agree that we should be combining the verificaiton methods in anyway. This implies that the verification of the controller is intrisically part of the DID itself
15:19:59 <Wip> ... It is really more of a recursion
15:20:20 <Wip> ... It is not a append these arrays of verification methods from all controllers. Then verify
15:20:30 <ottomorac> ack Ivan
15:20:31 <Wip> ... First verify the controller, then verify the verificationMethods of the DID
15:20:42 <ottomorac> ack KevinDean
15:21:08 <Wip> ivan: I am a little worried about a layering. We are inheriting this document from the CID spec under the VCWG currently.
15:21:42 <Wip> ottomorac: Wills comment is also agrees with this. If we have to update this it will be in the CID spec that the changes need to be made.
15:21:55 <Wip> ivan: May need to raise an issue against the CID spec.
15:21:57 <Wip> q+
15:22:04 <ottomorac> ack Wip
15:22:47 <markus_sabadello> q+
15:22:50 <ottomorac> scribe+
15:23:03 <ottomorac> Wip: Yes I just wanted to raise attention to this issue...
15:23:39 <ottomorac> Wip: I hear Joes point about some confusion with the controller and verification method... there is some language around it requiring dereferencing....
15:23:48 <ottomorac> scribe-
15:23:52 <Wip> q+ JoeAndrieu
15:24:02 <ottomorac> ack markus_sabadello
15:24:08 <Wip> markus_sabadello: I agree with what Will said. Some DID methods use it, some dont
15:24:22 <Wip> ... This is also true for verificaiton methods in the DID document
15:24:39 <Wip> ... We have never required that verification methods in a DID document must be used to authorize updates
15:24:56 <Wip> ... in my mind the controller field has been mostly intended for applications that use DIDs and other technologies like VCs
15:25:18 <Wip> ... I don't really have an answer about the denial of service issue
15:25:20 <ottomorac> ack JoeAndrieu
15:25:59 <Wip> JoeAndrieu: the main reason some DID methods can't use it, is because it can't represent that party as a URL. You can't always put in all the information you need in a URL
15:27:05 <Wip> ... Challenge your algorithm about verificationMethod lookup. Interested to see if in the spec. The verificationMethod has a key in there, if you have to dereference a controller property and check that the verificationMethod is still in there then this adds challenges. THe DID document might have rotated by then
15:27:14 <Wip> ... This might be a data integrity question to answer
15:27:44 <ottomorac> Topic: TTL construct required?
15:27:48 <ottomorac> https://github.com/w3c/did/issues/896
15:28:07 <Wip> ottomorac: Okay moving on
15:28:25 <Wip> ottomorac: This an issue migrated from DID Resolution to DID Core. It is related to caching of DID Resolution results and how this could be managed in the form of some Time To Live (TTL) contruct akin to what DNS does. There was agreement in January that this is something that should be set by the DID Controller, and not something defined by the
15:28:25 <Wip> DID method.
15:28:59 <Wip> ... There was agreement that this is something that should be set by the DID controller not something defined by each DID method
15:29:01 <Wip> 1+
15:29:02 <Wip> q+
15:29:11 <ottomorac> ack Wip
15:29:14 <JoeAndrieu> q+ to suggest a property somewhere
15:29:15 <ottomorac> scribe+
15:29:38 <markus_sabadello> q+
15:29:41 <ottomorac> Wip: Yes we moved from DID resolution to DID core, do we agree that this is still relevant to be addressed?
15:29:54 <ottomorac> ack JoeAndrieu
15:29:54 <Zakim> JoeAndrieu, you wanted to suggest a property somewhere
15:30:11 <Wip> JoeAndrieu: we might be able to address this if we convince ourselves that it is a security fix
15:30:28 <Wip> ... It should be the controller who sets this. They are the best party to state the TTL of their DID
15:30:44 <Wip> ... This suggests to me we want a property somewhere. Probably a top level property in the DID document
15:31:01 <ottomorac> ack markus_sabadello
15:31:04 <Wip> ... Happy to talk with Simone in the security interest group to see if he would view it as a security concern
15:31:21 <Wip> markus_sabadello: I think we should have this. Agree this should be set by the DID controller
15:31:54 <Wip> ... Wonder if this would be a property in the DID document. Or a DID Document metadata property in DID resolution result
15:32:12 <Wip> ... This feels like it could fit in to this set of metadata properties
15:32:23 <Wip> ... This is also related to a parameter we have, no-cache
15:32:28 <Wip> ... This is also in DID resolution
15:32:41 <Wip> ... I am in favour of having this feature, just not sure DID core is the right place
15:32:51 <Wip> q+
15:32:58 <ottomorac> ack Wip
15:33:35 <JoeAndrieu> q+
15:33:42 <ottomorac> Wip:  Yes moved this issue from DID resolution but still unsure if it belongs here....
15:33:50 <ottomorac> ack JoeAndrieu
15:34:15 <Wip> JoeAndrieu: echo what Will  says. In did:btc1 method we don't have a meta layer to store something like ttl.
15:34:19 <markus_sabadello> q+
15:34:25 <Wip> ... Not sure how we would get it in the metadata in some of the methods
15:34:29 <ottomorac> ack markus_sabadello
15:34:59 <Wip> markus_sabadello: I agree with that too. We have a good understanding of how to update DID documents across DID methods. We don't have a good understanding of how to update DID Document metadata
15:35:17 <Wip> ... From a theoretical standpoint metadata would be the right place. TTL describes the DID document not the subject
15:35:44 <Wip> ... Just because we have never had a way for these metadata properties to be set, doesnt mean it isnt the right way for it to be done
15:36:03 <Wip> ... However can see that putting it in  the DID document is a more practical approach
15:36:22 <ottomorac> scribe-
15:36:31 <ottomorac> Topic: DID Core PR Processing
15:36:36 <ottomorac> https://github.com/w3c/did/pulls
15:36:41 <Wip> q+
15:37:36 <ottomorac> Subtopic: Add warning about comparing DID URLs containing query parameters. #895
15:37:42 <ottomorac> https://github.com/w3c/did/pull/895
15:38:05 <Wip> ottomorac: This attempts to clarify that the DID core spec defines no normalization rules for query parameters and warning when comparing DID URLs.
15:38:14 <Wip> ... Just calling this out for review from folks
15:38:21 <Wip> q?
15:38:26 <ottomorac> ack Wip
15:38:27 <Wip> q-
15:38:38 <ottomorac> Topic: DID Resolution Issue Processing
15:38:45 <ottomorac> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20sort%3Aupdated-asc
15:38:58 <ottomorac> Subtopic: Should the HTTPS binding be mandatory? #93
15:39:03 <ottomorac> https://github.com/w3c/did-resolution/issues/93
15:39:36 <Wip> ottomorac: Discussion was held in January as to whether this is something that Resolvers or DID methods need to define and whether an https endpoint is mandatory.
15:39:46 <Wip> ... Also wondering if this belongs in did core
15:39:50 <markus_sabadello> q+
15:40:01 <ottomorac> ack markus_sabadello
15:40:13 <Wip> markus_sabadello: This should not be in DID core. It is DID resolution where we have the binding defined for resolution
15:40:28 <JoeAndrieu> q+ because DID methods need compatible resolvers.
15:40:30 <Wip> ... We just need to decide if it should be mandatory
15:40:38 <JoeAndrieu> q+ to say because DID methods need compatible resolvers.
15:40:44 <ottomorac> ack JoeAndrieu
15:40:44 <Zakim> JoeAndrieu, you wanted to say because DID methods need compatible resolvers.
15:41:14 <Wip> JoeAndrieu: markus has a good point. What is important in DID core is that DID methods to be conformant must have at least one implementation of a resolver with a https binding
15:41:19 <Wip> ... THis is not a requirement on all resolvers
15:41:27 <Wip> ... This is a requirement on DID methods for compatibility
15:41:31 <Wip> q+
15:41:43 <Wip> ... It is the DID method that needs to provide this as a software component
15:41:49 <ottomorac> ack Wip
15:41:54 <ottomorac> scribe+
15:42:50 <ottomorac> Wip: If we agree that this is a requirement for the did method, which sounds reasonable to ask for an https binding, ideally this requirement might need to go into did-core... perhaps challenging because did-core is just in maintenance mode...
15:43:26 <Wip> q?
15:43:44 <ottomorac> scribe-
15:44:00 <ottomorac> Subtopic: Is it graph merge or graph equivalence? #115
15:44:07 <ottomorac> https://github.com/w3c/did-resolution/issues/115
15:44:52 <Wip> ottomorac: This related to the equivalentID term: https://www.w3.org/TR/did-resolution/#dfn-equivalentid And a clarification note in a section of the definition of that term. There is an RDF term in there for &ldquo;full graph merge&rdquo; that seems unclear. Markus agreed that the term "graph equivalence" is a more appropriate term than "graph
15:44:53 <Wip> merge".
15:45:30 <JoeAndrieu> q+ to say this is a place where the properties in the DID document are not about the subject, but about the DID
15:45:45 <markus_sabadello> q+
15:46:01 <ottomorac> ack JoeAndrieu
15:46:01 <Zakim> JoeAndrieu, you wanted to say this is a place where the properties in the DID document are not about the subject, but about the DID
15:46:27 <Wip> JoeAndrieu: this depends on whether you read the JSON as JSONLD or not you have different interpretation
15:46:42 <Wip> ... I don't think anyone meant that "same as" means you should do a graph merge
15:47:22 <Wip> ... This is a statement that is much more about the subject. It is like having two different VCs about the subject. Whether you choose to trust those and merge them in your data set depends
15:47:25 <ottomorac> ack markus_sabadello
15:47:30 <Wip> ... We should not do a merge in a way that is proposed here
15:47:42 <Wip> markus_sabadello: I think at least a part of this issue is obsolete
15:47:50 <Wip> ... DID resolution results should be JSON and not JSONLD
15:48:16 <Wip> ... One of the discussion points was whether equivilantId should be the same as "same as". It is no longer an rdf property
15:48:23 <Wip> ... I don't know if we need to say anything about this
15:48:35 <Wip> ... We are saying something about equivalentId and what it means
15:48:56 <Wip> ... Each equivalentId value is logically equivalent to the id property and refers to the same subject
15:48:56 <JoeAndrieu> q+ to mention security
15:49:11 <Wip> ottomorac: Wondering about the history of this green box clarification
15:49:24 <ottomorac> ack JoeAndrieu
15:49:24 <Zakim> JoeAndrieu, you wanted to mention security
15:49:43 <Wip> JoeAndrieu:  I think it was meant to be a report by the resolver for another way you can get to the same thing
15:50:03 <Wip> ... If we think about equivalentId as giving this intention that you are supposed to merge the graph in the DID document.
15:50:32 <Wip> ... This is back to the pattern where you are supposed to merge the controllers. All verification methods in both documents should be considered as proofs of either DIDs. We need to clarify that that is not what is meant here
15:50:38 <markus_sabadello> q+
15:50:54 <Wip> ... We need to be clear that from a security standpoint you do not want to merge the two sets of verificationRelationships
15:50:55 <ottomorac> ack markus_sabadello
15:51:40 <Wip> markus_sabadello: I remember why we have this. There were DID methods with multiple forms of a DID. The idea was always that you get back the same DID document for these two identifiers acccept that the identifer is in a different form
15:51:54 <Wip> ... From that perspective also a graph merge doesnt really make sense
15:52:06 <Wip> ... It is the same graph. Maybe it is more of a graph equivalence
15:52:17 <Wip> ... Again not sure if there is spec text that should be added
15:52:28 <ivan> q`=
15:52:42 <ivan> s/q`=//
15:52:47 <ottomorac> ack ivan
15:53:06 <Wip> ivan: The important point from Markus is that equivalence means I get back exactly the same DID document
15:53:17 <Wip> ... There is no issue about graph merge
15:53:27 <Wip> ... There is this example about using lowercase and uppercase in the DID URL
15:53:42 <Wip> ... All the rest is confusing things
15:53:57 <Wip> ... From the DID resolver point of view, these two identifiers  lead to the same DID document.
15:54:08 <Wip> ottomorac: So we just simplify things.
15:54:20 <Wip> ivan: The RDF point is moot, as we are not using RDF in DID resolution
15:54:54 <Wip> ottomorac: Sounds like we have a proposal to simplify the language to make this point of the equivalence
15:55:36 <Wip> ottomorac: Need someone to write a PR, but at least we have direction
15:55:40 <ottomorac> Subtopic: Language clarification "A DID document is a representation of information describing a DID subject." #113
15:55:46 <ottomorac> https://github.com/w3c/did-resolution/issues/113
15:55:49 <Wip> q+
15:56:09 <ottomorac> scribe+
15:56:46 <JoeAndrieu> q+ to say this has been a long standing disagreement
15:57:08 <ottomorac> Wip: Yes this sentence was not striking of what a did-document is.  To me a did identifies a did-document... and then we have the verification relationships in the did-document
15:57:16 <ottomorac> ack Wip
15:57:25 <ottomorac> ack JoeAndrieu
15:57:25 <Zakim> JoeAndrieu, you wanted to say this has been a long standing disagreement
15:57:43 <Wip> JoeAndrieu: I have always disagreed with Manu and Dave on this point
15:57:57 <Wip> ... When a DID document was treated as JSONLD you can't make a statment about the identifier
15:58:06 <Wip> ... THe identifier transmutes the statement to be about the subject
15:58:17 <Wip> ... Now that we are not in JSONLD we do not have this constraint.
15:58:29 <Wip> ... This illusion that this DID document is somehow about the subject
15:58:57 <Wip> ... I think it is really important that we should make it clear that you should not be putting statements about the subject in the DID document
15:59:07 <Wip> ... I would like to clarify this in the spec
15:59:17 <Wip> ottomorac: I saw a proposal to try pull in working from the CID spec
15:59:28 <Wip> JoeAndrieu: Wasn't clear what language we should add
16:24:38 <ottomorac> rrsagent, make minutes
16:24:40 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/19-did-minutes.html ottomorac
16:27:57 <ottomorac> m2gbot, link issues with transcript
16:27:58 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/92#issuecomment-2988642688
16:27:59 <m2gbot> comment created: https://github.com/w3c/did/issues/897#issuecomment-2988642719
16:28:00 <m2gbot> comment created: https://github.com/w3c/did/issues/896#issuecomment-2988642754
16:28:01 <m2gbot> comment created: https://github.com/w3c/did/pull/895#issuecomment-2988642802
16:28:02 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/93#issuecomment-2988642835
16:28:03 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/115#issuecomment-2988642864
16:28:04 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/113#issuecomment-2988642897
16:28:28 <ottomorac> zakim, end the meeting
16:28:28 <Zakim> As of this point the attendees have been Wip, KevinDean, pchampin, ottomorac, markus_sabadello, ivan, JoeAndrieu, JennieM
16:28:30 <Zakim> RRSAgent, please draft minutes
16:28:31 <RRSAgent> I have made the request to generate https://www.w3.org/2025/06/19-did-minutes.html Zakim
16:28:37 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
16:28:38 <Zakim> Zakim has left #did
16:29:20 <ottomorac> RRSAgent, please excuse us
16:29:20 <RRSAgent> I see no action items