15:52:59 <RRSAgent> RRSAgent has joined #did
15:53:04 <RRSAgent> logging to https://www.w3.org/2025/12/11-did-irc
15:53:04 <Wip> rrsagent, make logs public
15:53:09 <Wip> Meeting: Decentralized Identifier Working Group
15:53:11 <Wip> Chair: Wip
15:53:16 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Dec/0003.html
15:53:17 <agendabot> clear agenda
15:53:17 <agendabot> agenda+ Agenda Review, Introductions (5 min)
15:53:17 <agendabot> agenda+ Holiday Schedule (5 min)
15:53:17 <agendabot> agenda+ Discussion around Issue Assignment (5 min)
15:53:17 <agendabot> agenda+ DID Core PR Export Terms \[1\] (5 min)
15:53:20 <agendabot> agenda+ DID Resolution ""Read"" operation \[2\] (5 min)
15:53:22 <agendabot> agenda+ DID Path URL Discussion \[3\] (30 min)
15:53:33 <Wip> previous meeting: https://www.w3.org/2025/12/04-did-minutes.html
15:53:41 <Wip> next meeting: https://www.w3.org/2025/12/11-did-minutes.html
15:58:39 <pchampin> present+
15:59:15 <swcurran> swcurran has joined #did
15:59:28 <swcurran> present+
15:59:34 <Wip> present+
16:01:43 <KevinDean> KevinDean has joined #did
16:01:53 <KevinDean> present+
16:02:39 <TallTed> TallTed has joined #did
16:02:59 <JoeAndrieu> JoeAndrieu has joined #did
16:03:04 <manu> scribe+
16:04:13 <Wip> Topic: Agenda Review
16:04:57 <manu> Wip: Holidays coming up -- need to cover that, then DID Methods charter, then this WG and work we have to do, then some PRs on exporting terms, READ operation discussion, then Path URL discussion.
16:05:10 <manu> Wip: Any other changes to agenda?
16:05:13 <Wip> q?
16:05:20 <manu> rrsagent, draft minutes
16:05:21 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-did-minutes.html manu
16:05:28 <Wip> Topic: Holiday Schedule
16:05:48 <manu> Wip: We will have a call next week, but then a break for multiple weeks, coming back on Jan 8th.
16:05:52 <JoeAndrieu> +1 for two week break
16:06:05 <manu> manu: +1 for a multiple week break.
16:06:22 <manu> Wip: In two weeks, we need to try to make progress on PRs. Will move onto next discussion.
16:06:24 <Wip> Topic: WG Progress Update
16:07:24 <manu> Wip: There are a few things around this -- DanubeTech is no longer a member of W3C and doesn't have financial support to be a Member and be an Editor -- Markus will still be around, but until he has more funding/support, he won't be very active. Since he's not in W3C, he can't be Editor, but in practice it's been Markus mostly doing the PRs.
16:08:14 <JoeAndrieu> JoeAndrieu has joined #did
16:08:14 <KevinDean> KevinDean has joined #did
16:08:14 <swcurran> swcurran has joined #did
16:08:14 <Wip> Wip has joined #did
16:08:14 <rhiaro> rhiaro has joined #did
16:08:27 <manu> Wip: I'm happy to take on work, but need others to take responsibility to write PRs and merge PRs. Second part is around issue assignment, we have a lot of issues, but issues are marked ready for PR, most of them are straightforward, everyone on call needs to get this done, we have six months to get through everything, need to get 1 PR a week done, that will moev things faster.
16:08:29 <manu> q+
16:08:29 <JennieM> JennieM has joined #did
16:08:36 <JennieM> present+
16:08:44 <Wip> ack manu
16:08:45 <manu> Wip: We can assign them to folks, happy to do that, we have limited participants, we need people to do PRs and move work forward.
16:08:46 <pchampin> scribe+
16:09:03 <pchampin> manu: let me explain my thinking here
16:09:14 <pchampin> ... participating in a WG is not a spectators sport
16:09:37 <pchampin> ... specifically, invited experts are expected to provide some value to the group
16:09:52 <pchampin> ... as Wip said is not a huge amount of work
16:10:00 <pchampin> ... every person on this call should be taking on a PR
16:10:00 <JennieM> JennieM has joined #did
16:10:00 <JoeAndrieu> JoeAndrieu has joined #did
16:10:00 <KevinDean> KevinDean has joined #did
16:10:00 <Wip> Wip has joined #did
16:10:00 <rhiaro> rhiaro has joined #did
16:10:16 <pchampin> ... if you don't know how to write a PR, write your contribution in an issue
16:11:03 <pchampin> ... every person on the call should be able to take a PR
16:11:05 <pchampin> scribe-
16:11:25 <manu> Wip: On the Editors -- you are listed as Editor on DID Resolution, Markus can't participate anymore, do you have time/capacity to step into role more?
16:11:54 <manu> Dmitri: I see, didn't realize that about Markus -- ok, will set aside time to work on DID Resolution, do some PR processing.
16:12:05 <manu> Wip: That would be great, shouldn't be too much -- but would help if others do it.
16:12:21 <Wip> Topic: DID Methods WG
16:12:42 <swcurran> swcurran has joined #did
16:12:50 <swcurran> present+
16:12:51 <ivan> present+
16:13:13 <manu> pchampin: We have issue w/ Chairs role on DID Methods WG -- we are short of a Chair for DID Methods WG -- I will send an email to DID mailing list calling for volunteers from W3C Member, would send a better signal.
16:13:15 <manu> q+
16:13:48 <manu> pchampin: We can re-appoint Markus if DanubeTech becomes a member again, goal isn't to pull Markus away, just to remove blocking point and have charter go to vote.
16:14:01 <Wip> ack manu
16:14:03 <manu> pchampin: There are only so many people on the call, I'll reach out for more member orgs on mailing list.
16:14:09 <pchampin> scribe+
16:14:19 <ivan> q+
16:14:27 <manu> manu: You might also send it to CCG.
16:14:27 <Wip> ack ivan
16:14:31 <manu> pchampin: Good point, thank you.
16:14:35 <pchampin> manu: you might also send it to the CCG. Not all of them are members, but you would have more eyes on this.
16:15:02 <manu> ivan: There might be another problem w/ Markus -- if we want to reappoint, he has to be Invited Expert -- giving IE to someone that is a former member of a W3C Member is an uphill battle.
16:15:06 <pchampin> scribe-
16:15:28 <Wip> Topic: DID Core PR Export Terms
16:15:34 <Wip> subtopic: https://github.com/w3c/did/pull/913
16:16:56 <manu> otto: This PR is attempting to solve issue about duplicate terms between DID Core and DID Resolution, before we do the PR for DID Resolution, we need to export some terms from DID Core to make it possible to refer to them in DID Resolution. Proposed terms, most of them use DID prefix so they won't conflict, but there are some (resources/services that could work w/ local alias) . Just trying to export terms, once this PR is merged, there will be another PR
16:16:57 <manu> for DID Resolution.
16:17:26 <manu> Wip: Service endpoint is too generic?
16:17:37 <manu> otto: Could avoid conflits by using DID Service Endpoint.
16:17:38 <Wip> q?
16:17:39 <manu> q+
16:17:48 <Wip> ack manu
16:18:03 <pchampin> scribe+
16:18:08 <smccown> smccown has joined #did
16:18:19 <smccown> present+
16:18:24 <pchampin> manu: there is a way to deconflict the terms when using them (specify which spec they come from)
16:18:45 <JoeAndrieu> q+ to mention CIDs
16:18:46 <pchampin> ... we are contemplating reusing "serviceEndpoint" in CID
16:18:53 <Wip> ack JoeAndrieu
16:18:53 <Zakim> JoeAndrieu, you wanted to mention CIDs
16:18:54 <pchampin> ... so I would not make it specific to DIDs.
16:19:01 <pchampin> ... But this looks like a good PR, I will review it.
16:19:25 <manu> JoeAndrieu: We should also look at CID spec and see what we need to synchronize there -- service endpoint might not be owned by DID. We can't change CID spec. We should figure out impact.
16:19:29 <pchampin> scribe-
16:19:42 <Wip> Topic: DID Resolution "Read" operation
16:19:46 <Wip> https://github.com/w3c/did-resolution/issues/230
16:20:14 <JoeAndrieu> q+
16:20:15 <manu> Wip: What is the impact here? Move resolve to read? What are we doing here?
16:20:30 <Wip> ack JoeAndrieu
16:20:32 <manu> Wip: There is significant change to change Read -> resolve.
16:21:09 <manu> JoeAndrieu: I don't think we had consensus -- I think I'm on the opposite side... DID Methods define resolve -- what they dont' define is how they read from the VDR. Bitcoin defines how you read from Bitcoin, Method says how to resolve.
16:21:13 <manu> q+
16:21:19 <manu> JoeAndrieu: I think we need more conversation.
16:21:20 <Wip> ack manu
16:22:32 <Wip> q+
16:22:35 <Wip> ack Wip
16:22:38 <manu> manu: We need to tease out the nuance here, more discussion needed.
16:23:23 <manu> Wip: It feels like what is being said is "Read" as an operation needs to be moved from Resolution spec -- resolver has "resolve" function, which then calls "resolve" operation for DID Method? I'll take another pass and have a look.
16:24:14 <manu> Wip: I was looking through did:cel and that defines a "READ" operation -- read algorithm, that's true of many DID Methods... they don't define "resolve", they define "read".
16:24:23 <Wip> q?
16:25:12 <JoeAndrieu> q+ to mention you don't "call" resolve on a method
16:25:15 <Wip> Topic: https://www.w3.org/TR/did/upcoming/#method-operations
16:25:46 <Wip> ack JoeAndrieu
16:25:46 <Zakim> JoeAndrieu, you wanted to mention you don't "call" resolve on a method
16:25:47 <manu> Wip: DID Core spec might say they have to define "read" operaiton, but it doesn't say that ... <quotes from DID spec>
16:26:39 <manu> JoeAndrieu: I think one of the things that is happening, is that you don't call "resolve" on the method, it's abstract, it's not something you call -- the resolver PERFORMS resolution... we are creating terra firma between DID client and rresolver, some nuance on the language.
16:27:02 <manu> Wip: Maybe we can address Jeffreys' concern by talking about "resolution" instead?
16:27:07 <Wip> Topic: DID Path URL Discussion
16:27:09 <manu> Wip: I'll take a look at this some more.
16:27:54 <manu> swcurran: I've prepared a presentation about DID URL Path Handling -- https://bit.ly/DIDPath
16:28:41 <manu> swcurran: A DID URL can have any combination of frament, query, and path.  handling should feel like HTTP URL processing...
16:29:00 <manu> swcurran: Fragments are not a DID Resolver issue... they are handled by client after it gets a resource back
16:29:11 <manu> swcurran: thus, we can exclude fragments from remainder of the discussion.
16:30:18 <manu> swcurran: query parameters are combined with paths... very flexible -- some are applied/defined in DID Resolution, some are in extensions, some can be combined w/ path handling, some can be applied as DID Resolution path process... unknown to DID Resolution.
16:30:40 <ottomorac> ottomorac has joined #did
16:30:47 <ottomorac> present+
16:30:52 <manu> swcurran: path processing -- relativeRef is ugly, have to URL encode it... awkward, not natural... there is no clean, DID Resolution definition of what to do with <did>/path/to/file
16:31:20 <ottomorac> ottomorac has joined #did
16:31:20 <smccown> smccown has joined #did
16:31:20 <swcurran> swcurran has joined #did
16:31:20 <JennieM> JennieM has joined #did
16:31:20 <JoeAndrieu> JoeAndrieu has joined #did
16:31:20 <KevinDean> KevinDean has joined #did
16:31:20 <Wip> Wip has joined #did
16:31:20 <rhiaro> rhiaro has joined #did
16:31:49 <manu> swcurran: some use cases -- single storage location, multiple storage locations, dreidct to resource in specific location, storage location with parameters for retrieving resource, etc.
16:33:15 <manu> swcurran: proposal -- services with a `prefix` attribute -- new algorithm would be:
16:33:22 <manu> swcurran: 1. Extract the path from the DID URL
16:33:32 <manu> swcurran: 2. Collect services based on the known path-handling types.
16:33:47 <manu> swcurran: if service and service-type query parameters are used, consider only services of those types.
16:34:11 <manu> swcurran: 3. Determine longest matching prefix in the path and use that service -- if there are none or more than one match, return an eror
16:34:31 <manu> swcurran: 4. Use the type of the service to process the dereferencing... DID Resolution spec only defines the FileService type (for now).
16:34:41 <JoeAndrieu> q+
16:34:47 <manu> swcurran: but maybe not Services... perhaps Resources?
16:35:02 <Wip> ack JoeAndrieu
16:35:17 <manu> JoeAndrieu: That was a good segue -- I didn't follow the connection between the path and the service? Why would path be mapped to service endpoint?
16:36:09 <manu> Wip: The path in the DID URL is used to identify the service and service contains prefix which then uses service endpoint to resolve.
16:36:27 <manu> swcurran: I have examples that might be helpful later on.
16:36:38 <manu> swcurran: One objection that Markus had was overloading services.
16:36:47 <manu> swcurran: The FileService type of service does the following:
16:36:53 <manu> swcurran: 1. Remove the prefix from the path
16:37:00 <manu> swcurran: 2. Append result to the serviceEndpoint
16:37:16 <manu> swcurran: 3. Resolve the resulting URL, if possible (noting errors and cycles)
16:37:53 <manu> swcurran: <shows simplest example>
16:38:01 <manu> q+
16:38:17 <Wip> ack manu
16:39:08 <manu> swcurran: <shows IPFS example>
16:39:33 <manu> swcurran: Noting that the "<CID>" shouldn't exit on serviceEndpoint.
16:39:47 <manu> swcurran: <shows google slides example>
16:40:26 <manu> swcurran: <shows whois service example>
16:41:17 <manu> swcurran: You can have extensions that are types -- would love to see `/whois` promoted into DID Resolution spec.
16:41:37 <manu> manu: I'd support /whois in DID Resolution spec, but understand that's a separate discussion.
16:41:40 <ottomorac> ottomorac has joined #did
16:42:32 <manu> swcurran: Path and query parameters -- some parameters are processed by resolver priorit to matching... unknown ones are passed onto path'd resource -- unconsumed query parameters are passed on.
16:42:33 <JoeAndrieu> q+ to ask about getting rid of service altogether
16:42:33 <manu> q+
16:42:53 <manu> swcurran: questions/concerns?
16:42:55 <Wip> ack JoeAndrieu
16:42:56 <Zakim> JoeAndrieu, you wanted to ask about getting rid of service altogether
16:43:33 <manu> JoeAndrieu: Seems like what's happening, using service property, use path to map to service properties -- mostly I like what you've done here... can we get rid of service as a parameter? We could use prefix to do that? Service part always felt weird to me -- possible?
16:43:45 <manu> swcurran: So, remove service service-type behavior?
16:43:52 <manu> JoeAndrieu: Yes.
16:43:55 <Wip> q+ to respond to JoeAndrieu
16:43:58 <pchampin> scribe+
16:43:59 <Wip> ack manu
16:44:14 <pchampin> manu: +1 to JoeAndrieu, I would like to get rid of the service parameter
16:44:17 <Wip> q-
16:44:32 <pchampin> ... the cleaner the DID URL processing, the better for developers
16:44:48 <pchampin> s/service parameter/service query parameter if we can do that
16:45:04 <Wip> q+
16:45:11 <pchampin> q+
16:45:12 <JoeAndrieu> +1 to needing to think through getting rid of service. might be hidden dragons
16:45:20 <Wip> ack Wip
16:45:26 <manu> manu: We might need to thin kthrough removing service in this algorithm.
16:45:49 <manu> Wip: Removing service and service-type -- might not want to do that? One specific service type that you might add into possible services that we might have for path... there are other types.
16:45:50 <manu> q+
16:46:00 <manu> Wip: We don't want to only identify them by prefix, which we might not have.
16:46:00 <Wip> ack pchampin
16:46:20 <JoeAndrieu> q+ to say they can all have prefixes. this is about how to get from a DIR URL to the service.
16:46:27 <manu> pchampin: Bikeshedding point... don't like "file service", maybe subpath service, not always resolving to a file
16:46:30 <ottomorac> +1 to PAs comment
16:46:34 <Wip> ack manu
16:47:11 <pchampin> manu: to what Wip said, what I meant was "getting rid of the service parameter for this use case"
16:47:36 <pchampin> ... we need to do more analysis to be sure we don't lose anything
16:47:56 <Wip> ack JoeAndrieu
16:47:56 <Zakim> JoeAndrieu, you wanted to say they can all have prefixes. this is about how to get from a DIR URL to the service.
16:48:08 <pchampin> swcurran: you are saying that the services in the DID doc would be used
16:48:17 <pchampin> ... but the service and service-type parameters would not
16:48:21 <pchampin> manu: yes
16:48:52 <ottomorac> Manu overall you think this fits ok with what the Cheqd folks have?
16:49:13 <manu> JoeAndrieu: I think we're mostly aligned -- you said something that gave me a bit of doubt... if we overload serviceEndpoint properties to ping off of prefix, then we no longer need query parameters that are service and service type -- but we woul dlose type function... as long as you can have multiple service endpoint sw/ same prefix, you can have multiple endpoints w/ same type -- keep DID Document the same, we had used service parameter, if we move to
16:49:13 <manu> path, look slike it might be a godo way to do it... might be able to get parameter together (service and service-type), maybe we use different property?
16:49:44 <manu> JoeAndrieu: Could have `path` or something else, new property where you did matching to path to get metadata for how you dereference particular file -- don't know if we can get rid of service, but maybe?
16:49:56 <Wip> +1
16:49:57 <manu> q+
16:50:05 <ottomorac> scribe+
16:50:11 <Wip> q+
16:50:20 <manu> JoeAndrieu: Might create confusion?
16:50:27 <Wip> ack manu
16:50:42 <JoeAndrieu> +1 to ramifications
16:50:43 <pchampin> manu: the only reason I didn't go that far is that I don't know the ramifications
16:50:46 <ottomorac> Manu:  Yes but need to check the ramifications of this....
16:50:48 <pchampin> ... I agree it might cause some confusions
16:50:57 <ottomorac> Manu:  What Stephen said is my position
16:51:10 <swcurran> q+
16:51:12 <pchampin> scribe-
16:51:20 <ottomorac> Manu:  Joe you are right this might cause some confusion...
16:51:56 <ottomorac> Manu: we could encourage this new path mechanism and over time get rid of the old way with service...
16:52:04 <Wip> ack Wip
16:52:05 <JoeAndrieu> +1 to that proposal to split the innovation
16:52:10 <ottomorac> scribe-
16:52:42 <JoeAndrieu> q+ to say you query for #service
16:52:46 <ottomorac> q+
16:52:50 <manu> Wip: I don't think we can get rid of service and serviceType -- but sometimes you want to retrieve services from DID Document, like in BTCR2, we want to query DID Document, we just want to get all services -- might be same in DIDCommv2.
16:52:53 <Wip> ack swcurran
16:53:07 <pchampin> q+ to ask if what Wip is describing is "resolution"?
16:53:37 <pchampin> q-
16:53:39 <manu> swcurran: I was amazed to discover that not only a DID Resolution return a DID Document and a resource, but there is a thing that says if you set accept, you get list of services back -- service endpoints, so that's what a DID Resolution could result in -- that's why we can't get rid of service and is being used.
16:53:42 <Wip> ack JoeAndrieu
16:53:44 <Zakim> JoeAndrieu, you wanted to say you query for #service
16:53:59 <manu> q+ to get back to Stephen's proposal?
16:54:24 <manu> JoeAndrieu: I think we can get this same behavior through another mechanism
16:54:46 <manu> swcurran: The current spec allows result of array of services as return type.
16:54:49 <JoeAndrieu> q+
16:54:52 <JoeAndrieu> q-
16:54:54 <Wip> ack ottomorac
16:55:21 <manu> ottomorac: Wondering, Manu, if you know what did:cheqd is doing?
16:55:27 <manu> manu: Not me :) someone else
16:55:29 <JoeAndrieu> q+
16:55:37 <manu> swcurran: I did look, would be improved by what we're doing here.
16:56:25 <JoeAndrieu> cheqd is returning data in the metadata
16:56:26 <manu> q+
16:56:29 <Wip> ack manu
16:56:29 <Zakim> manu, you wanted to get back to Stephen's proposal? and to
16:56:59 <Wip> ack JoeAndrieu
16:57:07 <pchampin> +1, passing leftover parameters seems brittle
16:57:12 <manu> manu: We might have to pass more query parameters on than just the leftover ones
16:57:26 <pchampin> s/parameters seems/parameters only seems
16:57:30 <manu> JoeAndrieu: cheqd have to pass properties -- did document metadat holds linked resource mechanisms...
16:57:43 <manu> swcurran: if this was available ahead of time, this might have been done differently to achieve the same result.
16:57:56 <manu> swcurran: Anything else on this approach?
16:58:00 <ottomorac> Regardless great work here by swcurran, kudos for taking this on!
16:58:15 <manu> Wip: It might be best to close existing PR and resubmit a new PR.
16:58:15 <manu> swcurran: Yep
16:58:59 <manu> swcurran: Anything that is defined like versionId and versionType should be in a formal part of spec -- removed it from another place and moved to its own section, what amount to minispecs of what service parameter means, what serviceType path resource will be -- I think that is important, wonder if folks have opinion on that?
16:59:00 <manu> q+
16:59:03 <Wip> ack manu
16:59:09 <pchampin> scribe+
16:59:20 <JoeAndrieu> present+
16:59:22 <pchampin> manu: I didn't quite understand the question, we need more time to discuss it
16:59:26 <pchampin> scribe-
16:59:30 <manu> swcurran: There are a set of things that are query parameters, but they are not specified clearly -- might need to add that.
16:59:41 <manu> Wip: This is a good feature, appreciate the effort on it.
16:59:43 <ottomorac> thanks!
16:59:45 <manu> Wip: See everyone next week!
16:59:51 <manu> rrsagent, draft minutes.
16:59:51 <RRSAgent> I'm logging. I don't understand 'draft minutes.', manu.  Try /msg RRSAgent help
16:59:53 <manu> rrsagent, draft minutes
16:59:55 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-did-minutes.html manu
17:05:38 <Wip> rrsagent, make minutes
17:05:39 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-did-minutes.html Wip
17:05:52 <Wip> m2gbot, link issues with transcript
17:05:53 <m2gbot> comment created: https://github.com/w3c/did/pull/913#issuecomment-3642885660
17:05:54 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/230#issuecomment-3642885716
17:05:59 <Wip> zakim, end the meeting
17:05:59 <Zakim> As of this point the attendees have been pchampin, swcurran, Wip, KevinDean, JennieM, ivan, smccown, ottomorac, JoeAndrieu
17:06:01 <Zakim> RRSAgent, please draft minutes
17:06:02 <RRSAgent> I have made the request to generate https://www.w3.org/2025/12/11-did-minutes.html Zakim
17:06:08 <Zakim> I am happy to have been of service, Wip; please remember to excuse RRSAgent.  Goodbye
17:06:08 <Wip> rrsagent, please excuse us
17:06:08 <RRSAgent> I see no action items
17:06:09 <Zakim> Zakim has left #did