14:56:49 <RRSAgent> RRSAgent has joined #did
14:56:53 <RRSAgent> logging to https://www.w3.org/2026/03/12-did-irc
14:56:59 <ottomorac> rrsagent, make logs public
14:57:09 <ottomorac> Meeting: Decentralized Identifier Working Group
14:57:13 <ottomorac> Chair: ottomorac
14:57:17 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Mar/0011.html
14:57:17 <agendabot> clear agenda
14:57:17 <agendabot> agenda+ Agenda Review, Introductions (5 min)
14:57:17 <agendabot> agenda+ DID Path PR \[1\] (10 min)
14:57:17 <agendabot> agenda+ DID Core PR: Add DID Resolution error conditions to vocabulary \[2\] (5 min)
14:57:17 <agendabot> agenda+ DID Resolution PR Processing \[3\] (7 min)
14:57:20 <agendabot> agenda+ DID Resolution Issue Processing \[4\] (15 min)
14:57:23 <agendabot> agenda+ DID Resolution Threat Modelling Update \[5\] (15 min)
14:57:43 <ottomorac> previous meeting: https://www.w3.org/2026/03/05-did-minutes.html
14:57:48 <ottomorac> next meeting: https://www.w3.org/2026/03/19-did-minutes.html
15:01:25 <JoeAndrieu> JoeAndrieu has joined #did
15:01:44 <KevinDean> KevinDean has joined #did
15:02:02 <Wip> Wip has joined #did
15:02:06 <Wip> present+
15:02:16 <manu> present+
15:02:51 <JoeAndrieu> present+
15:04:02 <KevinDean> https://w3c.github.io/scribe2/scribedoc.html
15:05:53 <bumblefudge> bumblefudge has joined #did
15:05:54 <bumblefudge> scribe+
15:06:05 <swcurran> swcurran has joined #did
15:06:10 <swcurran> present+
15:06:45 <bumblefudge> otto: agenda recap
15:06:53 <bumblefudge> otto: (agenda recap)
15:07:07 <ottomorac> zakim, next item
15:07:07 <Zakim> agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot]
15:07:14 <ottomorac> https://github.com/w3c/did-resolution/pull/260
15:08:13 <bumblefudge> otto: PR twists and turns - joe, explain your recent turn to dissatisfaction
15:08:56 <bumblefudge> joe: i previously questioned the backwards-compatibility with the older URL implementation, e.g. did:cheqd DID-linked resources and did:cosmos
15:09:14 <swcurran> q+
15:09:24 <bumblefudge> ... i don't want to merge this until we have more hardened backwards compat, and i worry we are privileging one approach over others
15:09:40 <bumblefudge> ... as opposed to leaving this in the realm of opt-in extensions
15:10:29 <bumblefudge> ... good convo yesterday with will: we talked through a corner case where an existing DID with one kind of path/endpoint "adds" a new one in the new model and it breaks that DID or older ways it could be consumed
15:10:40 <ottomorac> ack swcurran
15:11:08 <bumblefudge> swcurran: i take issue with the idea of this prejudicing or favoring one way over others
15:11:21 <manu> q+
15:11:34 <bumblefudge> ...: on the contrary, the whole point is to regularize this and make interop possible rather than just extensions that can't have cross-method meaning or usage
15:12:08 <ottomorac> ack manu
15:12:13 <bumblefudge> ...: i am still catching up on more recent comments, but i definitely want to satisfy the goal of backwards compatibility and minimal breakage of existing deployments and extensions
15:13:17 <swcurran> q+
15:13:22 <bumblefudge> manu: i see both sides here. the wg consensus was not to favor specific approaches and to maximize back-compat. i can't follow the disagreements over the specifics of the algorithm, but i do remember the wg saying people would object until they felt backwards compat was complete enough
15:13:41 <bumblefudge> ... breaking cheqd would be a failure mode and i would expect objections if there is clear breakage
15:14:07 <ottomorac> q+
15:14:49 <bumblefudge> ... i think some form of path service in this general shape we could invite people to align around, and market-based alignment would happen naturally over time
15:15:19 <bumblefudge> ... and extensions or other approaches will still be supported on a more method-by-method basis in any future we can avoid breaking them
15:15:40 <ottomorac> ack swcurran
15:15:48 <bumblefudge> ... i thought the consensus was to move this into did-wide mechanism, NOT leave it in extension-land
15:16:07 <JoeAndrieu> q+ to say it does conflict
15:16:19 <bumblefudge> swcurran: action item for me, i'll take a closer look at cheqd did-linked resources to understand better what the concerns are there
15:16:46 <ottomorac> ack ottomorac
15:17:02 <bumblefudge> ...i assumed peacekeeper was being thorough when he said he thought backwards compat was fine here, i guess i will dig deeper to figure out what we're still disagreeing over
15:17:04 <ottomorac> Alex Tweeddale:
15:17:04 <ottomorac> I do think it breaks DID-Linked Resources, but a simple update will align DLRs with this new spec.
15:17:04 <ottomorac> My understanding is that if cheqd DIDs included a service of type = pathService and endpoint including: /resources/
15:17:04 <ottomorac> Then it should be compatible?
15:18:01 <ottomorac> ack JoeAndrieu
15:18:01 <Zakim> JoeAndrieu, you wanted to say it does conflict
15:18:28 <bumblefudge> joe: wow, +1 to alex, if cheqd sees the fix as manageable on their side, it's great news
15:18:53 <ottomorac> q?
15:19:38 <bumblefudge> ... i'm worried about the case where legacy and new model are both present and they conflict, some kind of built-in conflict resolution or heirarchy makes it more programmatic to avoid breakage in the design of the new model #150
15:19:43 <ottomorac> zakim, next item
15:19:43 <Zakim> agendum 2 -- DID Path PR \[1\] (10 min) -- taken up [from agendabot]
15:19:52 <ottomorac> https://github.com/w3c/did/pull/923
15:19:53 <bumblefudge> joe: was trying to think through this
15:20:38 <ottomorac> q?
15:20:42 <manu> q+
15:20:46 <ottomorac> ack manu
15:21:06 <bumblefudge> otto: manu have you checked this out yet? looks approved already
15:21:19 <bumblefudge> manu: i haven't run the linter/checker but if that passes looks right semantically
15:21:24 <ottomorac> q?
15:21:24 <bumblefudge> ... yeah looks good
15:21:32 <ottomorac> zakim, next item
15:21:32 <Zakim> agendum 3 -- DID Core PR: Add DID Resolution error conditions to vocabulary \[2\] (5 min) -- taken up [from agendabot]
15:21:45 <ottomorac> zakim, next item
15:21:45 <Zakim> agendum 3 was just opened, ottomorac
15:21:46 <bumblefudge> zaky boy, get it together
15:22:12 <manu> zakim, next item
15:22:12 <Zakim> agendum 3 was just opened, manu
15:22:12 <pchampin> zakim, open agendum 4
15:22:12 <Zakim> agendum 4 -- DID Resolution PR Processing \[3\] (7 min) -- taken up [from agendabot]
15:22:12 <JennieM> JennieM has joined #did
15:22:18 <JennieM> present+
15:22:48 <bigbluehat> bigbluehat has joined #did
15:23:01 <ottomorac> subtopic: https://github.com/w3c/did-resolution/pull/299
15:23:09 <bigbluehat> present+
15:23:14 <ottomorac> Include extensions in the expand urls algorithm
15:23:14 <ivan> present+
15:23:32 <bumblefudge> otto: will, wanna introduce?
15:24:07 <manu> q+
15:24:16 <ottomorac> ack manu
15:24:37 <bumblefudge> will: Addresses TAG review comments, but also mentioned in one of joe's issues; previously, known/core did properties were the only things checked, but this updates it to cover additional props and more reliably expand DIDs
15:24:46 <bumblefudge> manu: looks good
15:24:50 <ottomorac> subtopic: https://github.com/w3c/did-resolution/pull/301
15:26:00 <bumblefudge> s/expand DIDs/expand all URLs/
15:27:16 <manu> q+
15:27:59 <bumblefudge> swcurran: relativeRef seemed dangerous to me
15:28:07 <ottomorac> ack manu
15:28:32 <JoeAndrieu> q+ to mention issue 925 at did-core https://github.com/w3c/did/issues/925
15:28:45 <bumblefudge> manu: at a high level, looks good, nit, lowercase shoulds and mays might bite us later
15:28:55 <bumblefudge> ...as opposed to MAY or can
15:29:11 <bumblefudge> swcurran: whoops missed that
15:29:47 <swcurran> q+
15:29:54 <bumblefudge> manu: TBH, i think this patch was very thorough and was just about as convincing as i can imagine
15:30:12 <bumblefudge> ... a lot of the complexity is unavoidable and upstream because inherent to URL normalization and syntax
15:30:13 <pchampin> q+
15:30:20 <ottomorac> ack JoeAndrieu
15:30:20 <Zakim> JoeAndrieu, you wanted to mention issue 925 at did-core https://github.com/w3c/did/issues/925
15:30:50 <manu> q+ to note relativeRef as SHOULD NOT use is something I could get behind
15:31:16 <bumblefudge> joe: ok but there's a real vacuum here, "query" isn't defined enough
15:31:20 <pchampin> q-
15:31:32 <ottomorac> ack swcurran
15:31:40 <bumblefudge> ... in did-core there is an admonition against duplicate query params, but that seems impossible here given this language, so that ambiguity might bite us later
15:32:04 <bumblefudge> swcurran: i was focusing on exactly that, but i'm not sure where to stick the fix
15:32:34 <bumblefudge> ... i was being pretty careful to consistently stick to what is possible in a did, i would welcome a separate PR (or maybe a fix on did-core) to squash this ambiguity
15:32:41 <bumblefudge> ... could this PR land and new issue and PR address it?
15:32:48 <ottomorac> q?
15:32:52 <ottomorac> ack manu
15:32:52 <Zakim> manu, you wanted to note relativeRef as SHOULD NOT use is something I could get behind
15:33:05 <bumblefudge> bumblefudge: +1 to swcurran requesting follow-on PR for issues created by this PR instead of holding up this PR
15:33:52 <bumblefudge> manu: if not for backcompat, i would have loved to just deprecate relRef for the same reasons, but pathService, if it is defined here in this spec, could include a non-normative hint to use this instead and explain why
15:34:00 <ottomorac> q?
15:34:03 <pchampin> q+
15:34:20 <swcurran> Does anyone use relativeRef?  It's so tricky.
15:34:24 <ottomorac> ack pchampin
15:34:49 <manu> q+
15:34:53 <JoeAndrieu> q+ to clarify
15:34:56 <ottomorac> ack manu
15:35:01 <bumblefudge> pchampin: i wonder if advising against relRef is too harsh (or prejudiced against existing impls); couldn't a relRef include a hash or hashlink or SRI or?
15:35:43 <ottomorac> ack JoeAndrieu
15:35:43 <Zakim> JoeAndrieu, you wanted to clarify
15:35:44 <bumblefudge> manu: well, maybe but the semantics are slippery, what relationship is assumed or projected between the hash and the referent, what assumptions of the dereferencing or immutability
15:35:56 <bumblefudge> ... i would love to hear from someone who uses it and loves it and feels safe using it
15:36:33 <bumblefudge> joe: pchampin, you might be referring to a different usage of the relRef in URLs, this is a DID-specific semantic, which might be another reason to deprecate or at least rename our overloading of the term
15:36:39 <ottomorac> q?
15:36:44 <bumblefudge> bumblefudge +1, hate overloading
15:36:50 <ottomorac> zakim, next item
15:36:50 <Zakim> agendum 3 -- DID Core PR: Add DID Resolution error conditions to vocabulary \[2\] (5 min) -- taken up [from agendabot]
15:37:19 <ottomorac> zakim, open topic 5
15:37:19 <Zakim> I don't understand 'open topic 5', ottomorac
15:37:28 <ottomorac> zakim, open agendum 5
15:37:28 <Zakim> agendum 5 -- DID Resolution Issue Processing \[4\] (15 min) -- taken up [from agendabot]
15:37:36 <ottomorac> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22Simplify%20for%20Interop%20%26%20Consistency%22
15:37:57 <JoeAndrieu> q+
15:38:09 <bumblefudge> otto: i was wondering what this issue flag "simplify for interop and consistency" means?
15:38:12 <ottomorac> ack JoeAndrieu
15:38:19 <bumblefudge> ... are you imagining one PR to address all four of these?
15:39:02 <ottomorac> subtopic: https://github.com/w3c/did-resolution/issues/302
15:39:10 <ottomorac> Reconsider expandRelativeURLs as part of dereferencing instead of resolution #302
15:39:11 <bumblefudge> joe: to explain, all four of these came out from swcurran's pr, but were kind of offtopic so i wanted to address them later, mostly around deferencing/resolution mixups in various points of the spec and swcurran's new lang
15:40:04 <bumblefudge> joe: in summary, i think there is a slippage here whereby the resolver is changing the did doc
15:40:11 <Wip> q+
15:40:24 <ottomorac> ack Wip
15:40:27 <bumblefudge> ... the actual did doc is what gets dereferenced, if the resolver wants to change anything it should change what gets resolved
15:41:08 <bumblefudge> will: also there is a separate issue tied up in this to detangle how extensions work across resolution and dereferencing
15:41:29 <bumblefudge> ... worried about parallelizing these, might this get squashed or conflictive if you're doing PRs on same sections?
15:41:35 <bumblefudge> joe: i am not to worried
15:41:40 <bumblefudge> ...about parallelizing
15:42:00 <bumblefudge> manu: sorry this is a lot to read and assess, as well as judge if parallelizable
15:42:14 <ottomorac> q?
15:42:20 <bumblefudge> ... i could have sworn this came up before and we said we would add a section or algorithms but never got around to it
15:42:34 <bumblefudge> ...not clear to me what next steps are
15:42:42 <manu> q+
15:42:54 <ottomorac> ack manu
15:43:14 <bumblefudge> joe: actually we already have sections for the resol/deref, i just want further clarity of the separation of concerns and the implicit contract between method implementation/VDR and resolver
15:43:23 <bumblefudge> manu: +1, that clarification would be good somewhere
15:43:26 <ottomorac> subtopic: https://github.com/w3c/did-resolution/issues/303
15:43:34 <ottomorac> Reconsider accept as parameter for dereferencing rather than resolution #303
15:43:50 <bumblefudge> joe: similar dynamic here
15:44:18 <Wip> q+
15:44:24 <ottomorac> ack Wip
15:44:43 <bumblefudge> ... i think parameter got put in the wrong place, accept header gives the resolver wider birth to reformulate and return a translation
15:44:53 <bumblefudge> will: i think this is from the two mediatype days
15:45:08 <bumblefudge> ... and when resolvers were expected to do content-negotiation
15:45:21 <bumblefudge> ... but more generally, +1, i agree to move this, it's cleaner the proposed way
15:45:42 <bumblefudge> otto: i am not sure it's productive to go through these 1 by 1 now, these issues are new and need time to percolate
15:45:46 <bumblefudge> ...and get reviewed async
15:46:21 <ottomorac> subtopic: https://github.com/w3c/did-resolution/issues/304
15:46:28 <ottomorac> Be clearer about the service array as part of dereferencing instead of resolution #304
15:47:14 <bumblefudge> otto: seeing some reactions from peacekeeper, but markus' question is good
15:47:36 <bumblefudge> joe: can address: i think threat modeling exposed a corner case with dereferencing a DID URL historically
15:48:08 <bumblefudge> ... namely, you need to dereference a DID URL, but if there are query params, you also need to resolve the DID URL (i.e. apply params to the dereferenced DID URL)
15:48:16 <swcurran> q+
15:48:27 <bumblefudge> ... as that applies to services array, i think we can also just move this over
15:48:45 <ottomorac> ack swcurran
15:48:47 <bumblefudge> otto: yeah swcurran's PR really made all this salient for me
15:49:27 <bumblefudge> swcurran: i think you have general agreement so proceed to PR and it would be faster to just discuss draft PRs rather than abstractions
15:49:30 <ottomorac> q?
15:49:34 <bumblefudge> joe: will do action item for me
15:49:43 <bumblefudge> ... although i wanted confirmation that the mental model worked for me
15:49:48 <bumblefudge> q+
15:49:56 <ottomorac> ack bumblefudge
15:49:59 <ottomorac> scribe+
15:50:20 <ottomorac>  bumblefudge: Does this overlad de-referencing and resolving?
15:51:09 <swcurran> q+
15:51:10 <bumblefudge> bumblefudge: sorry nothing productive to ask, just worried other terms might overload general URL deref/resol
15:51:20 <bumblefudge> otto: last call for minor issues and checkins?
15:51:31 <ottomorac> ack swcurran
15:51:39 <bumblefudge> will: basically, if anyone sees a complication or counterargument before joe writes PRs, drop them in the issue
15:51:56 <bumblefudge> swcurran: if floor is open, can i close the pathUrl PR and start a new PR?
15:52:15 <bumblefudge> manu: yeah totally, just backlink as "superceding"
15:52:52 <bumblefudge> swcurran: minor issue, the CSS issue i got into last week with echidnea, numbered algorithms and bullets are getting garbled as deep deep numbers, i will try to open a separate PR for that
15:53:05 <ottomorac> subtopic: https://github.com/w3c/did-resolution/issues/293
15:53:09 <bumblefudge> ... but if anyone has helpful echidnea insights i would appreciate the pointers
15:53:21 <ottomorac> Tracking of resolutions and dereferences by downstream entities from the resolver #293
15:53:47 <bumblefudge> will: 293: i promised a general privacy review issue across all the specs at once, please drop any inputs or ideas in there that might help me with that review
15:54:26 <bumblefudge> ... i have also pinged the reviewer to propose a 3-feature PR
15:55:01 <bumblefudge> ... point 2 points out that priv cons specs can refer to each other to avoid duplication and drift
15:55:07 <manu> q+
15:55:09 <ottomorac> q?
15:55:12 <ottomorac> ack manu
15:55:15 <bumblefudge> ...but it's a bit unwieldly to follow three links to know how to use one of the specs
15:55:39 <bumblefudge> ... if reviewer is happy with wontfix on #2 i will just PR 1 and 3
15:55:47 <bumblefudge> otto: sounds a bit like a circular reference, tho...
15:56:16 <JoeAndrieu> q+ how do we address obfuscation of the DID itself?
15:56:32 <ottomorac> q?
15:56:47 <bumblefudge> manu: and on pt 3, there might be a quick fix just specifying a "trusted cache" rather than a "cache", or just dropping that section altogether if the reviewer still dissatisfied
15:57:12 <Wip> q+
15:57:13 <bumblefudge> joe: fundamentally, i think they are asking for something offbase
15:57:36 <bumblefudge> ... obfuscating which callers are getting which dids seems to misunderstand the privacy goals imho
15:57:39 <ottomorac> ack Wip
15:57:46 <bumblefudge> ... we can obscure which DOCUMENTS they got back but callers and DIDs aren't worth obscuring
15:58:19 <bumblefudge> will: i think the reviewer was asking specifically about HTTP/IP obfuscation/tracking, which we can maybe explain better in PR or in spec text
15:58:34 <bumblefudge> .. with trusted cache reference for ex
15:58:43 <bumblefudge> scribe -
15:59:19 <pchampin> RRSAgent, make minutes
15:59:21 <RRSAgent> I have made the request to generate https://www.w3.org/2026/03/12-did-minutes.html pchampin
16:13:39 <ottomorac> zakim, please excuse us
16:13:39 <Zakim> leaving.  As of this point the attendees have been Wip, manu, JoeAndrieu, swcurran, JennieM, bigbluehat, ivan
16:13:39 <Zakim> Zakim has left #did
16:13:57 <ottomorac> RRSAgent, please excuse us
16:13:57 <RRSAgent> I see no action items