15:00:19 <RRSAgent> RRSAgent has joined #did
15:00:23 <RRSAgent> logging to https://www.w3.org/2025/10/23-did-irc
15:00:23 <Zakim> Zakim has joined #did
15:00:23 <TallTed> TallTed has changed the topic to: DID WG Agenda 2025-10-23 https://www.w3.org/events/meetings/de82c11f-a06f-4bf1-bb94-bd968af528e1/20251023T080000/
15:00:33 <TallTed> present+
15:00:35 <KevinDean> KevinDean has joined #did
15:00:35 <TallTed> meeting: DID Working Group
15:00:37 <TallTed> agenda: https://www.w3.org/events/meetings/de82c11f-a06f-4bf1-bb94-bd968af528e1/20251023T080000/
15:01:06 <Wip> Wip has joined #did
15:01:23 <KevinDean> present+
15:01:26 <Wip> present+
15:02:42 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/23-did-minutes.html TallTed
15:03:15 <swcurran> swcurran has joined #did
15:03:17 <TallTed> previous meeting: https://www.w3.org/2025/10/16-did-minutes.html
15:03:19 <TallTed> next meeting: https://www.w3.org/2025/10/30-did-minutes.html
15:03:29 <swcurran> present+
15:03:43 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/23-did-minutes.html TallTed
15:04:44 <TallTed> chair: Wip
15:04:45 <bigbluehat> bigbluehat has joined #did
15:05:33 <Wip> Topic: Agenda Review
15:05:45 <bigbluehat> scribe+
15:06:00 <ottomorac> ottomorac has joined #did
15:06:00 <bigbluehat> Wip: we'll start with talking about Stephen's PR
15:06:09 <bigbluehat> swcurran: yeah, I think it's ready
15:06:17 <bigbluehat> Wip: and then we'll talk about DID resolution issues
15:06:31 <bigbluehat> ... manu we did not put any DID core things on the agenda
15:06:34 <bigbluehat> ... should we have?
15:06:47 <Wip> Topic: DID URL Dereferencing PR
15:06:48 <bigbluehat> manu: there's the ID equivalence one
15:06:53 <bigbluehat> Wip: let's see if we get to that one
15:06:55 <Wip> https://github.com/w3c/did-resolution/pull/221
15:07:02 <bigbluehat> Wip: let's start with swcurran's PR
15:07:20 <bigbluehat> swcurran: I can start with a slide presentation
15:07:55 <bigbluehat> ... DID URL can have any combination of URI components
15:08:12 <bigbluehat> ... handling a DID should feel like handling a URL
15:08:23 <bigbluehat> ... a Browser is more similar to a DID Client
15:08:31 <bigbluehat> ... on difference is a DID Resolver
15:08:39 <bigbluehat> ... which is more constrained than a Web Server
15:08:51 <bigbluehat> ... but there are still similarities
15:09:21 <bigbluehat> ... The spec calls a difference between a resolver and a dereferencer
15:09:28 <bigbluehat> ... and I'm still not sure what the difference is there
15:09:37 <bigbluehat> ... and I must confess I merge those two concepts in the PR
15:09:48 <bigbluehat> ... and am not sure if that's OK or not...
15:10:02 <Wip> q?
15:10:22 <bigbluehat> ... so, fragments are not a DID Resolver issue, the Client handles the fragment
15:10:44 <bigbluehat> ... if the resource is some other resource that a DID Doc, then it should use that resource response's media type
15:10:53 <bigbluehat> ... not sure how Joe and Cosmos feel about it
15:10:56 <markus_sabadello> markus_sabadello has joined #did
15:11:05 <bigbluehat> ... because they created their linked resources as fragment identifiers
15:11:13 <bigbluehat> ... because that's Cosmos' best practice
15:11:19 <bigbluehat> ... but I think it's still aligned
15:11:54 <manu> q+ to point out difference between DID Resolver vs. DID URL Dereferencer.
15:12:01 <bigbluehat> ... but it stays something only the Client uses
15:12:43 <Wip> did:cosmos is defined here - https://github.com/EarthProgram/did-cosmos
15:12:49 <bigbluehat> ... Query Parameters. I moved into their own area...like "mini-specs"
15:13:04 <bigbluehat> ... I tried to highlight that the ones involved in resolution are called out specifically
15:13:22 <bigbluehat> ... hopefully they are more complete with normative statements expressed now
15:13:38 <bigbluehat> ... for HTTP, obviously, query params are completely up for interpretation
15:13:49 <bigbluehat> ... whereas, DIDs have some specified
15:14:07 <bigbluehat> ... Path processing. There's currently no clean definition of what to do when one appears
15:14:14 <bigbluehat> ... and `relativeRef` is ugly
15:14:21 <bigbluehat> ... because it has to be URI encoded
15:14:37 <bigbluehat> ... The use cases center around storage location
15:14:58 <bigbluehat> ... paths could also enable redirection
15:15:36 <bigbluehat> ... and there are scenarios where parameters are introduced for handling the path
15:15:47 <bigbluehat> ... so, the idea we came up with is that there would be services
15:16:00 <bigbluehat> ... with a `prefix` attribute in the service definition
15:16:06 <manu> q+ to speak to switching off of type instead of prefix.
15:16:59 <bigbluehat> ... the processing is to take the path, check it against the `prefix`'s of the services, use it to dereference the resource OR return an error if unfound
15:17:26 <bigbluehat> ... the `FileService` type of `service` then would remove the `prefix` from the path, and resolve the rest against the file service
15:19:11 <bigbluehat> ... I used a different example in the slide deck than in the PR
15:19:27 <bigbluehat> ... it uses a different type
15:20:05 <ottomorac> scribe+
15:20:43 <ottomorac> swcurran: provides various examples in the slide deck of how did paths could function with his proposal
15:21:39 <ottomorac> swcurran:  Path + Query parameters, some query parameters might be known to / processed by the DID resolver prior to matching
15:22:25 <ottomorac> swcurran: service=<type> is used to limit the types of services that can be used
15:23:17 <Wip> q?
15:23:24 <Wip> ack manu
15:23:24 <Zakim> manu, you wanted to point out difference between DID Resolver vs. DID URL Dereferencer. and to speak to switching off of type instead of prefix.
15:23:24 <ottomorac> swcurran:  Questions / concerns: 1)  DID Resolvers  vs. DID URL Dereferencer, 2) Handling "left over" query parameters,  3) Formatting conventions
15:24:35 <ottomorac> manu: This is great work thanks.  My comments: difference between DID Resolver and DID dereferencer. The purpose is to give you the entire path to the resolver.
15:24:46 <ottomorac> swcurran: but it may be part of the resolver....
15:25:01 <ottomorac> I think that could be handled with the service type...
15:25:42 <ottomorac> we could just define special handlers for these...
15:25:54 <ottomorac> manu: we could have a conversation about something like that...
15:26:07 <ottomorac> ... we did not have the focus on paths before
15:26:41 <ottomorac> manu: It looks like the algs also have a focus on type and prefix
15:27:08 <Wip> q+
15:27:15 <ottomorac> manu: if we can switch off from type, we can better understand what the prefix is trying to do
15:27:33 <ottomorac> manu: we need a tighter coupling between the type and the prefix
15:27:51 <manu> q+
15:27:52 <ottomorac> swcurran: Yes but you would the service or service type query param....
15:28:02 <manu> q+ to note that you don't have to have serviceType in query parameter.
15:28:15 <ottomorac> swcurran: if you go by type you may have some default ones, but that might be tricky
15:28:26 <ottomorac> swcurran: I just used the word prefix as an initial suggestion
15:28:53 <Wip> ack Wip
15:28:55 <ottomorac> swcurran: I would like to avoid being forced to use query parameters to specify the types of services
15:29:17 <ottomorac> Wip:  We use prefix to understand the service....
15:29:21 <ottomorac> swcurran: yes
15:29:22 <Wip> ack manu
15:29:22 <Zakim> manu, you wanted to note that you don't have to have serviceType in query parameter.
15:29:44 <ottomorac> manu:  on the servicetype... I dont think we are forcing it as a query param
15:29:58 <ottomorac> manu: this would be up to each implementation...
15:30:21 <ottomorac> manu: we can keep the URLs clean and not require that
15:31:29 <ottomorac> manu: the reason that I am concerned about switching off from Prefix .... it feels cleaner to me to just say "here are the types that we process that have prefix associated with it.."
15:31:52 <ottomorac> manu: this would give us a more clear processing model and helps us avoid collisions
15:32:36 <ottomorac> swcurran: we have the service end point, which is a well known attribute, would that help with the path prefix?
15:33:24 <ottomorac> manu: suppose we have an implementer that does not use JSON LD... there could be a corner case...  we should match on type first therefore...
15:33:55 <Wip> q+
15:33:55 <ottomorac> swcurran: ok I think I can solve that
15:33:58 <Wip> ack Wip
15:34:13 <markus_sabadello> q+
15:34:27 <ottomorac> Wip: I was wondering have you spoken to the folks from Cheqd or Cosmos, they are bound to have opinions on this?
15:35:14 <ottomorac> swcurran:  yes, my reading is that linked resource  is an extension and should no interfere with this....
15:35:14 <Wip> q+
15:35:42 <ottomorac> swcurran: I think also fragment should happen post resolution...
15:36:11 <ottomorac> swcurran: the Cheqd folks are using did linked resources and are bypassing query params altogether...
15:36:23 <ottomorac> swcurran: I think there should not be any conflict...
15:36:52 <ottomorac> swcurran: we are however specifying that query params should suppport "versionid"
15:37:08 <Wip> ack markus_sabadello
15:37:19 <ottomorac> swcurran: Cheqd can define the linked resources as a query param if they like in the spec...
15:37:44 <ottomorac> markus_sabadello:  I think the Cheqd folks are also using a path...
15:37:47 <markus_sabadello> https://dev.uniresolver.io/#did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b
15:37:50 <markus_sabadello> https://dev.uniresolver.io/#did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47
15:38:31 <ottomorac> markus_sabadello:  these are just some examples of how they do it....
15:39:03 <markus_sabadello> did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b
15:39:06 <markus_sabadello> did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47
15:39:22 <manu> q+
15:39:28 <ottomorac> swcurran: ok, I will take another look at how Cheqd does it...
15:39:34 <manu> q+ to note how it might work for cheqd.
15:39:51 <Wip> ack Wip
15:39:54 <ottomorac> swcurran: I will reach out to Alex T., we may need to go to some kind of type
15:40:30 <ottomorac> Wip: I think we also talked about a way of how the Cheqd and cosmos folks could work together....
15:40:37 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/23-did-minutes.html TallTed
15:40:44 <markus_sabadello> q+
15:40:44 <swcurran> q+
15:40:55 <Wip> ack manu
15:40:55 <Zakim> manu, you wanted to note how it might work for cheqd.
15:41:22 <swcurran> +1
15:42:14 <ottomorac> manu: Yes, one of the most useful things of this PR is that it would be fully backwards compatible,  the other benefit is that since have specific types that define the dereferencing rules... then the Cheqd folks can decide if they would like to use that or not...
15:43:01 <Wip> ack markus_sabadello
15:43:24 <manu> q+
15:43:30 <ottomorac> markus_sabadello:  I cannot speak on behalf of cheqd, but I think it may break a few things of how they operate...
15:44:27 <ottomorac> ... this proposal may break it because it defines how you have to interpret the path... although this is left to the did method...
15:44:53 <Wip> ack swcurran
15:46:13 <ottomorac> swcurran: I think the Cheqd folks would not have to change their URLs... but they might need to change their did documents, just like we have to do it for did:webvh
15:46:35 <markus_sabadello> q+
15:46:54 <ottomorac> swcurran: but now having a type param, can allow each did method to decide which approach to follow in interpreting the path...
15:47:19 <Wip> ack manu
15:47:51 <ottomorac> manu: in response to Markus,  I think I read it differently, but maybe there is some language you are seeing in the spec that makes you think differently....
15:48:32 <Wip> +1 that was my understanding
15:48:42 <ottomorac> ... my understanding is the did Cheqd urls based on how they are right now, they do not have servicetype defined...
15:49:19 <swcurran> q+
15:49:30 <ottomorac> ... maybe we just need stronger language to indicate that you should first use the algs that we define in the spec and if not, then follow a did method specific alg....
15:49:47 <Wip> ack markus_sabadello
15:50:09 <manu> q+
15:50:24 <Wip> ack swcurran
15:50:28 <ottomorac> markus_sabadello: Looking at the PR, there is some language that doesnt agree with that....
15:50:40 <ottomorac> swcurran: Yes apologies, I should have looked into Cheqd more...
15:50:48 <markus_sabadello> q+
15:51:09 <manu> q+
15:51:12 <manu> q- later
15:51:14 <ottomorac> swcurran: perhaps we can add language to allow did method specific handling of path, but we try to discourage it...
15:51:15 <Wip> ack markus_sabadello
15:51:43 <Wip> q+
15:51:47 <ottomorac> markus_sabadello:  Ok but this feature may not work with all did methods....
15:52:27 <Wip> ack manu
15:52:44 <swcurran> +1 to Manu
15:53:17 <ottomorac> manu: I am not that concerned, we need to decide how define a standard way whilst still allowing some backwards compatibility...
15:53:56 <ottomorac> manu: also we need to acknowledge that in some cases implementers will willfully disregard the specs....
15:54:38 <ottomorac> manu: I think we can still have the new standard way and still allow the cheqd or cosmos way of interpreting the path to work....
15:55:27 <Wip> ack Wip
15:55:35 <ottomorac> manu:  I would rather not stop us from deciding on this just because a couple of did methods do it differently...
15:55:48 <markus_sabadello> q+
15:56:03 <ottomorac> Wip: Yes my interpretation was that this would allow that backwards compatibility...
15:56:31 <ottomorac> Wip: if the PR doesnt it say that way, we can still adjust it....
15:56:32 <Wip> ack markus_sabadello
15:56:55 <ottomorac> markus_sabadello:  I think we should Alex T. from Cheqd to see what they think...
15:57:20 <swcurran> q+
15:57:26 <ottomorac> ... perhaps they may find a way to make it interoperable...
15:58:13 <ottomorac> markus_sabadello: there are some benefits of the cheqd approach...
15:59:00 <manu> yes, +1, we shouldn't depend on HTTPS
15:59:13 <ottomorac> swcurran: just to clarify, that HTTP is the service end point... also I noted that we should watch for cycles
15:59:13 <manu> (nor do I think we do)
15:59:17 <manu> ...and if we do, it's a bug :)
15:59:39 <ottomorac> Wip: Yes maybe we should reach to Cheqd and the Cosmos team and have a special topic call?
15:59:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/23-did-minutes.html TallTed
16:02:09 <ottomorac> scribe-
16:02:22 <ottomorac> present+
16:18:07 <ottomorac> zakim, end the meeting
16:18:07 <Zakim> As of this point the attendees have been TallTed, KevinDean, Wip, swcurran, ottomorac
16:18:09 <Zakim> RRSAgent, please draft minutes
16:18:11 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/23-did-minutes.html Zakim
16:18:17 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
16:18:17 <Zakim> Zakim has left #did
16:18:22 <ottomorac> rrsagent, make minutes
16:18:24 <RRSAgent> I have made the request to generate https://www.w3.org/2025/10/23-did-minutes.html ottomorac
16:18:47 <ottomorac> m2gbot, link issues with transcript
16:18:47 <m2gbot> nothing to do (no issue in the (sub)topics)
16:19:15 <ottomorac> RRSAgent, please excuse us
16:19:15 <RRSAgent> I see no action items