15:52:20 <RRSAgent> RRSAgent has joined #did
15:52:24 <RRSAgent> logging to https://www.w3.org/2026/01/08-did-irc
15:52:42 <ottomorac> ottomorac has changed the topic to: DID WG Agenda 2026-01-08 https://lists.w3.org/Archives/Public/public-did-wg/2026Jan/0002.html
15:52:53 <ottomorac> rrsagent, make logs public
15:52:59 <ottomorac> Meeting: Decentralized Identifier Working Group
15:53:03 <ottomorac> Chair: ottomorac
15:53:09 <ottomorac> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2026Jan/0002.html
15:53:09 <agendabot> clear agenda
15:53:09 <agendabot> agenda+ Agenda Review, Introductions (5 min)
15:53:09 <agendabot> agenda+ DID URL Derefencing and Fragments: The role of a DID Resolver (5 min)
15:53:09 <agendabot> agenda+ TAG DID Resolution Issues \[2\] (10 min)
15:53:09 <agendabot> agenda+ DID Resolution PR Processing \[3\] (20 min)
15:53:12 <agendabot> agenda+ DID Resolution Issues \[4\] (10 min)
15:53:48 <ottomorac> previous meeting: https://www.w3.org/2025/12/18-did-minutes.html
15:54:28 <ottomorac> next meeting: https://www.w3.org/2026/01/15-did-minutes.html
16:00:15 <dmitriz> dmitriz has joined #did
16:00:25 <Wip> Wip has joined #did
16:01:13 <ottomorac> present+
16:01:35 <Wip> present+
16:02:36 <swcurran> swcurran has joined #did
16:02:42 <swcurran> present+
16:04:16 <bigbluehat> bigbluehat has joined #did
16:04:22 <manu> present+
16:04:37 <bigbluehat> present+
16:04:37 <bigbluehat> scribe: bigbluehat
16:04:57 <ottomorac> zakim, next item
16:04:58 <Zakim> agendum 1 -- Agenda Review, Introductions (5 min) -- taken up [from agendabot]
16:05:16 <bigbluehat> ottomorac: today we have one issue we want to pick up again
16:05:26 <bigbluehat> ... mainly wanting to hear from Marcus
16:05:34 <bigbluehat> ... we also have some issues related to the TAG review
16:05:36 <KevinDean> KevinDean has joined #did
16:05:45 <KevinDean> present+
16:05:51 <bigbluehat> ... we've also got some PR processing on DID resolution
16:05:59 <bigbluehat> ... and if time, there are some other issues we can look at
16:06:10 <bigbluehat> ... given we haven't met in awhile, does anyone have other items?
16:06:23 <bigbluehat> ... k. onward
16:06:23 <ottomorac> zakim, next item
16:06:23 <Zakim> agendum 2 -- DID URL Derefencing and Fragments: The role of a DID Resolver (5 min) -- taken up [from agendabot]
16:06:35 <ottomorac> https://github.com/w3c/did-resolution/issues/259
16:06:39 <dmitriz> present+
16:06:42 <ottomorac> Previous discussion about where DID Resolution ends, but also talk about dereferencing that a client could do.
16:06:57 <bigbluehat> ottomorac: there was a previous discussion where Steven was mentioning where DID Resolution ends
16:07:01 <swcurran> q+
16:07:07 <bigbluehat> ... and what dereferencing would mean for a client
16:07:19 <smccown> smccown has joined #did
16:07:23 <bigbluehat> ... we also had a pending item around whether Marcus could give us some insights
16:07:27 <ottomorac> ack swcurran
16:07:37 <bigbluehat> ... but he'd need to be added as an invited expert...and we'll need PA for that
16:07:46 <bigbluehat> swcurran: I think it comes down to a couple things
16:07:56 <bigbluehat> ... a) fragments is post-dereferencing
16:08:01 <JennieM> JennieM has joined #did
16:08:04 <JennieM> present+
16:08:11 <bigbluehat> ... there's a good bit in the spec about that, but it should likely be kept out of it
16:08:31 <bigbluehat> ... other than to say, the client will use it to find the relevant DID doc
16:08:44 <bigbluehat> ... b) I'd been making the assumption that once a path was found that it would be resolved
16:08:49 <bigbluehat> ... which it actually may not...
16:09:04 <bigbluehat> ... once I got into it, I found you could return an array of service endpionts
16:09:15 <bigbluehat> ... that the endpoints would be treated as an API definition
16:09:24 <bigbluehat> ... and you could use what you needed from that array
16:09:39 <bigbluehat> ... but with the path, we're talking about referencing something more specific
16:09:56 <bigbluehat> ... and singular, and I assumed it would return the resource not only it's path
16:10:03 <bigbluehat> ... but I think we only need to return the path
16:10:26 <bigbluehat> ... Marcus' remaining objective seems to be around when the query parameters are applied
16:10:27 <manu> q+
16:10:37 <ottomorac> ack manu
16:10:46 <bigbluehat> ... on the initial request? or on the subsequent resource path
16:10:56 <bigbluehat> manu: I agree that's where we are
16:10:57 <JoeAndrieu> JoeAndrieu has joined #did
16:11:07 <JoeAndrieu> present+
16:11:12 <bigbluehat> ... I think we mainly need to see some PRs
16:11:12 <smccown> present+
16:11:34 <manu> q+
16:11:38 <bigbluehat> swcurran: I'd assume that a DID resolver would "know" which query params would apply to the resolution process
16:11:39 <ottomorac> last comment from Markus is this:  https://github.com/w3c/did-resolution/pull/260#issuecomment-3682932057
16:11:47 <ottomorac> (in case people are wandering)
16:11:52 <bigbluehat> ... and that could leave other query params to be applied to the resulting path
16:12:07 <bigbluehat> ... but Marcus stated that (very reasonably) would be very confusing
16:12:32 <bigbluehat> ... because you could get anything passed in as a query param and how do you know when and where to apply it?
16:12:53 <bigbluehat> ... his suggestion was to encode ones intended for the DID into another parameter
16:13:02 <bigbluehat> ... to make it clear which ones apply at which step
16:13:13 <ottomorac> ack manu
16:13:15 <bigbluehat> ... and make it explicit which ones apply post-resolution
16:13:28 <bigbluehat> manu: no objection if we go that route
16:13:37 <JoeAndrieu> q+ to say I think the resolver does know, if it handles the method. So the resolver gets everything. As @manu said.
16:13:42 <bigbluehat> ... an alternative might be that the resolver just uses what it knows and leaves the rest
16:13:52 <bigbluehat> ... but I agree there's no way to know which will be used where
16:14:01 <bigbluehat> ... the upside is that we can avoid the weird encoding thing
16:14:41 <bigbluehat> ... the hard thing is that it's hard to know where and when the query params would be applied
16:14:44 <bigbluehat> q+
16:15:17 <bigbluehat> ... whereas with the encoded approach the resolvers could be more explicit about what they accept
16:15:21 <ottomorac> ack JoeAndrieu
16:15:21 <Zakim> JoeAndrieu, you wanted to say I think the resolver does know, if it handles the method. So the resolver gets everything. As @manu said.
16:15:26 <bigbluehat> ... vs. never knowing what will be used when/where
16:15:47 <bigbluehat> JoeAndrieu: so...I see it differently
16:15:59 <bigbluehat> ... my understanding is that the parameters stay with it throughout
16:16:11 <bigbluehat> ... and that they continue to cascade down to other requests
16:16:17 <bigbluehat> ... it's true the caller may not know
16:16:18 <manu> q+
16:16:34 <ottomorac> scribe+
16:16:39 <ottomorac> ack bigbluehat
16:16:41 <pchampin> present+
16:17:00 <ottomorac> bigbluehat:   CMS and Login flows often do this type of parameter double encoding
16:17:28 <ottomorac> bigbluehat:  a "destination" or "intention" parameter is added in these types of flows
16:17:46 <ottomorac> bigbluehat: it doesn't look pretty but its clear about how it works
16:18:01 <ottomorac> bigbluehat: we need to be clear about parameter naming to avoid issues
16:18:15 <ottomorac> q?
16:18:19 <ottomorac> ack manu
16:18:23 <ottomorac> scribe -
16:18:45 <bigbluehat> manu: I'm coming around to Marcus's approach which I thing bigbluehat just said he supports
16:18:46 <JoeAndrieu> q+ to oppose encoding everything
16:18:51 <bigbluehat> ... the double encoded parameter
16:18:59 <bigbluehat> ... JoeAndrieu you touched on my concern at the end of what you said
16:19:14 <bigbluehat> ... I'm concerned about a resolver silently passing things down that it doesn't know
16:19:30 <bigbluehat> ... and would prefer the resolver complaining up front if/when it doesn't know what the parameter means
16:19:34 <swcurran> q+
16:19:40 <ottomorac> ack JoeAndrieu
16:19:40 <Zakim> JoeAndrieu, you wanted to oppose encoding everything
16:19:43 <bigbluehat> ... coupled with the encoded parameter passing, I think we have a nice clean approach
16:19:51 <bigbluehat> JoeAndrieu: so...this is a radically breaking change
16:19:57 <bigbluehat> ... and I think it's a bad idea
16:20:04 <bigbluehat> ... right now we have resolution params
16:20:09 <manu> q+
16:20:18 <ottomorac> ack swcurran
16:20:27 <bigbluehat> ... and I'm not seeing a security concern strong enough to break how we do things now
16:20:45 <bigbluehat> swcurran: so, one thing might be to only do that encoding approach when a path is provided
16:21:04 <bigbluehat> ... another would be that the resolver would return the path + whatever params remain
16:21:20 <bigbluehat> ... so the resolver handles what it knows and puts the rest on the path
16:21:29 <bigbluehat> q+
16:21:32 <ottomorac> ack manu
16:21:49 <bigbluehat> ... I don't think we'd want it to be rejected on params it didn't know
16:22:01 <bigbluehat> manu: we don't yet have a rec, so I think breaking changes are OK at this point
16:22:24 <bigbluehat> ... it is a security concern to not throw an error if it's just going to silently ignore params
16:22:38 <bigbluehat> ... do we have other implementations besides the universal resolver?
16:22:45 <JoeAndrieu> q+ to say if there are features that MUST be supported, then they must be supported. Everything else is a extensibility point. and there are implementations
16:22:50 <bigbluehat> ... we have other implementations, but not ones that use this feature
16:22:58 <ottomorac> scribe+
16:23:02 <ottomorac> ack bigbluehat
16:23:15 <Wip> q+
16:23:40 <TallTed> TallTed has joined #did
16:23:49 <ottomorac> bigbluehat: if these are query parameters that go along with the path, would we just not encode them with the path?
16:23:50 <swcurran> q+
16:24:05 <ottomorac> ack JoeAndrieu
16:24:05 <Zakim> JoeAndrieu, you wanted to say if there are features that MUST be supported, then they must be supported. Everything else is a extensibility point. and there are implementations
16:24:16 <bigbluehat> JoeAndrieu: yeah, I think this would have ramifications on DID Core and stuff in the wild
16:24:23 <bigbluehat> ... unless that feature is required
16:24:24 <ottomorac> scribe -
16:24:32 <bigbluehat> ... if it's not, then it's a point of extensibility
16:24:35 <manu> q+
16:24:46 <bigbluehat> ... or if it's part of some extension about dereferencing
16:25:03 <bigbluehat> ... like version ID could be required...I don't think it is right now
16:25:06 <ottomorac> ack Wip
16:25:20 <bigbluehat> ... and I think there are issues if your resolver is being forced to make decisions about things it doesn't yet know about
16:25:44 <bigbluehat> Wip: I do see the issues around version ID when the used in situations where the resolver doesn't know
16:25:54 <bigbluehat> ... the conversation is great, but I am concerned about the time
16:26:02 <bigbluehat> ... maybe a special call on this one?
16:26:11 <bigbluehat> ... because we're on a bit of a time crunch for the group in general
16:26:24 <ottomorac> ack swcurran
16:26:27 <bigbluehat> ... ottomorac not sure what you want to do, but I'd suggest we move on and arrange a special topic call for this one
16:26:46 <bigbluehat> ottomorac: swcurran and manu can have the last word, and then can arrange a special call
16:27:05 <bigbluehat> swcurran: the reason they're split is that there are two different resolution steps
16:27:27 <bigbluehat> ... so, maybe we encode the resource ones and not the resolution ones
16:27:38 <bigbluehat> ... and that should avoid concerns that JoeAndrieu raised
16:27:40 <ottomorac> ack manu
16:28:06 <swcurran> q+
16:28:08 <bigbluehat> manu: all of this is optional per the spec--I just checked
16:28:23 <bigbluehat> .... I'll leave it that I think it's a security issue and am really concerned about this
16:28:40 <ottomorac> ack swcurran
16:28:47 <bigbluehat> ... I won't stand in the way, but I think it's risky when versions are or are not checked for
16:29:08 <bigbluehat> swcurran: what I was trying to do, was to define requirements be defined
16:29:11 <bigbluehat> manu: they're not right now
16:29:19 <bigbluehat> swcurran: yeah, the proposal is that we define them to fix that
16:29:31 <bigbluehat> ... and then we allow a space for arbitrary parameters
16:29:33 <manu> q+
16:29:39 <bigbluehat> ... I don't think we can say we don't have them
16:29:48 <ottomorac> ack manu
16:29:53 <bigbluehat> ... HTTP allows this, you can pass in whatever but the server decides
16:30:09 <bigbluehat> manu: I'll note I'll work through this more, but I'll likely oppose it
16:30:17 <bigbluehat> ... swcurran is suggesting we add requirements
16:30:22 <bigbluehat> ... JoeAndrieu's opposing it
16:30:30 <bigbluehat> ... so there seems to be miscommunication
16:30:39 <bigbluehat> ottomorac: swcurran can you bring a suggestion?
16:30:46 <smccown> IMO, all versions should be checked.  If versions operate slightly differently, then Manu is correct that unforeseen security problems could arise.
16:30:49 <bigbluehat> swcurran: happy to, but I think manu is talking about something else
16:30:51 <bigbluehat> manu: agreed
16:31:06 <bigbluehat> swcurran: yeah...I think there are a few different conversations here
16:31:14 <bigbluehat> ... I'll write up what I'm proposing on that PR
16:31:15 <ottomorac> zakim, next item
16:31:15 <Zakim> agendum 3 -- TAG DID Resolution Issues \[2\] (10 min) -- taken up [from agendabot]
16:31:25 <ottomorac> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3A%22ready%20for%20pr%22%20label%3Atag-needs-resolution
16:31:36 <bigbluehat> ottomorac: we have a few items that have been assigned
16:31:53 <JennieM> q+
16:32:03 <ottomorac> ack JennieM
16:32:11 <bigbluehat> JennieM: I'll get a PR in for mine today
16:32:15 <bigbluehat> ottomorac: there's one for me also
16:32:26 <bigbluehat> ... which is relating to exporting terms which I'll resolve soon
16:32:32 <Wip> q+
16:32:33 <ottomorac> https://github.com/w3c/did-resolution/issues/226
16:32:37 <ottomorac> ack Wip
16:32:39 <bigbluehat> ... JoeAndrieu if you could help us out with 228, that'd be great
16:32:58 <bigbluehat> Wip: I think the reason we have this on the agenda is to confirm things are happening
16:33:05 <bigbluehat> ... if you can't do them, please let us know
16:33:15 <bigbluehat> ... we mainly just want to get them resolved so we can move onto the next stage
16:33:21 <bigbluehat> ... these are the last remaining issues
16:33:39 <bigbluehat> ottomorac: any concern from folks? feel free to raise it now
16:33:51 <ottomorac> zakim, next item
16:33:51 <Zakim> agendum 4 -- DID Resolution PR Processing \[3\] (20 min) -- taken up [from agendabot]
16:33:55 <bigbluehat> ottomorac: k. moving on
16:34:06 <bigbluehat> ... we have several PRs waiting to be merged
16:34:14 <ottomorac> PRs to be merged:
16:34:14 <ottomorac>  https://github.com/w3c/did-resolution/pull/264
16:34:14 <ottomorac> https://github.com/w3c/did-resolution/pull/265
16:34:14 <ottomorac> https://github.com/w3c/did-resolution/pull/243
16:34:21 <bigbluehat> ... unless anyone opposes, this is what we plan to merge
16:34:22 <KevinDean> KevinDean has joined #did
16:34:29 <bigbluehat> ... unless there are any oppositions
16:34:40 <bigbluehat> ... they'll be merged soon
16:34:52 <bigbluehat> ... there are some others we'd like to deep dive into a bit more
16:35:07 <manu> q+
16:35:11 <ottomorac> ack manu
16:35:16 <bigbluehat> manu: I think 262 is also ready to go
16:35:32 <bigbluehat> ... and Wip I think you're correct on 268 about trailing spaces
16:35:52 <Wip> q+
16:35:57 <ottomorac> ack Wip
16:35:57 <Wip> ack Wip
16:36:13 <bigbluehat> Wip: maybe that is true, but I did have a look at that history
16:36:23 <bigbluehat> ... and tried to find the commits that put them back in
16:36:36 <bigbluehat> manu: I'm confused as well because that should have taken those out
16:36:41 <bigbluehat> ... but the file diff still has them
16:36:51 <bigbluehat> q+
16:37:08 <bigbluehat> ... it's tangling merges up a good bit
16:37:11 <ottomorac> ack bigbluehat
16:37:13 <bigbluehat> ottomorac: I'll check my settings
16:37:19 <ottomorac> scribe+
16:37:30 <ottomorac> I posted a link to the editor config that you could use
16:38:00 <ottomorac> so that you don't have to deal with that on the local editor
16:38:03 <ottomorac> q?
16:38:09 <ottomorac> scribe -
16:38:15 <ottomorac> sutopic: https://github.com/w3c/did-resolution/pull/248
16:38:31 <ottomorac> Define generic datetime format for DID resolution and use throughout spec #248
16:38:34 <bigbluehat> ottomorac: defining a generic date/time format for did resolution
16:38:49 <bigbluehat> Wip: I'd appreciate some review on this
16:38:57 <bigbluehat> ... I have referenced the VCDM
16:39:05 <bigbluehat> ... and this is an I18N issues
16:39:16 <bigbluehat> s/I18N issues/I18N issue
16:39:22 <manu> q+
16:39:27 <ottomorac> ack Manu
16:39:27 <bigbluehat> ... but this is a pretty significant addition, so I'd like some review
16:39:29 <TallTed> i/wanting to hear from Marcus/<TallTed> present+
16:39:33 <bigbluehat> manu: this looks good at a high level
16:39:37 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/08-did-minutes.html TallTed
16:39:59 <bigbluehat> ... I'm concerned about sub-second stuff
16:40:10 <bigbluehat> ... the VCDM has normalization stuff
16:40:27 <bigbluehat> manu: mainly I was concerned we were changing stuff from VCDM
16:40:34 <bigbluehat> Wip: maybe you can take a look, but I don't think we are
16:40:39 <bigbluehat> ottomorac: reviews appreciated
16:40:41 <TallTed> s/<TallTed> present+/present+ TallTed
16:40:49 <ottomorac> subtopic: https://github.com/w3c/did-resolution/pull/255
16:40:51 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/08-did-minutes.html TallTed
16:40:57 <bigbluehat> ottomorac: this one also from Wip
16:41:07 <bigbluehat> ... adds an intro section to the privacy and security section
16:41:14 <Wip> q+
16:41:20 <ottomorac> ack Wip
16:41:22 <bigbluehat> ... and dmitriz reacted to it, but one more review here would be helpful
16:41:32 <bigbluehat> Wip: I'd really like to see more PR reviews happening
16:41:43 <bigbluehat> ... I really don't want to merge PRs without reviews
16:41:53 <bigbluehat> ... thanks dmitriz for approving this
16:42:07 <bigbluehat> ... but from just one person, is that sufficient? it just happened yesterday
16:42:08 <manu> q+
16:42:12 <ottomorac> ack manu
16:42:33 <bigbluehat> manu: I think the purely editorial stuff can be merged right away by editors--per process
16:42:43 <bigbluehat> ... substantive changes need 2+ positive reviews
16:42:49 <bigbluehat> ... and we just have to nag folks...
16:43:00 <bigbluehat> ... and ideally, the person who raised the PRs should push for review
16:43:16 <bigbluehat> ... mainly, I think we've lost track of who's in charge of the spec now with Marcus gone
16:43:20 <bigbluehat> ... maybe the Chairs should?
16:43:26 <bigbluehat> ... dmitriz are you lead editor on the spec now?
16:43:38 <bigbluehat> dmitriz: correct, but I'm unclear on the politeness
16:43:46 <bigbluehat> manu: 2 reviews after 7 days for normative
16:43:55 <bigbluehat> ... if they're editorial, it's completely up to you
16:44:07 <bigbluehat> ... for the case where we don't have 2 reviews after 7 days, then we have to push on calls
16:44:18 <bigbluehat> ... I'll also know that CODE_OWNERS is incorrect
16:44:25 <bigbluehat> ... it's pinging the wrong people
16:44:44 <bigbluehat> ... I'm happy to fix all that stuff, but I can't currently because I don't have permissions
16:44:45 <pchampin> q+
16:44:59 <ottomorac> ack pchampin
16:45:01 <bigbluehat> ... like adding `.editorconfig`, fixing CODE_OWNERS, etc.
16:45:04 <bigbluehat> Wip: happy to add you
16:45:09 <bigbluehat> pchampin: I should likely be the one doing that
16:45:19 <bigbluehat> ... so, just to summarize...
16:45:31 <bigbluehat> ... updating CODE_OWNERS to match reality
16:45:36 <bigbluehat> ... anything else?
16:45:44 <bigbluehat> manu: I could fix the trailing whitespace
16:46:05 <TallTed> s/CODE_OWNERS/CODEOWNERS/g
16:46:05 <TallTed> see https://github.com/w3c/did-resolution/blob/gh-pages/CODEOWNERS
16:46:12 <bigbluehat> ... write privileges would do the trick
16:46:13 <bigbluehat> ottomorac: I agree
16:46:14 <ottomorac> q?
16:46:16 <bigbluehat> Wip: I agree
16:46:21 <ottomorac> subtopic: https://github.com/w3c/did-resolution/pull/257
16:47:05 <JoeAndrieu> q+
16:47:08 <bigbluehat> ottomorac: any comments?
16:47:12 <ottomorac> ack JoeAndrieu
16:47:25 <bigbluehat> JoeAndrieu: the direction we were trying to go was to model how HTTP headers work
16:47:42 <bigbluehat> ... and we mention that anything must be able to be translated into the DID media type
16:47:43 <Wip> q+
16:47:48 <bigbluehat> ... so, my first scan was incorrect
16:47:55 <bigbluehat> ... so, this actually looks fine
16:47:57 <ottomorac> ack Wip
16:48:08 <bigbluehat> Wip: just to JoeAndrieu , I think there's a separate PR about HTTP semantics
16:48:22 <bigbluehat> JoeAndrieu: yeah, it was the MUST...but it's at a different layer than that text
16:48:45 <ottomorac> subtopic: https://github.com/w3c/did-resolution/pull/215
16:48:53 <bigbluehat> ottomorac: for this one, I'm a bit confused
16:49:14 <bigbluehat> ... this person also opened a PR
16:49:20 <bigbluehat> ... per Marcus' request
16:49:31 <bigbluehat> ... but then I think we lost it with Marcus exiting the grou
16:49:35 <bigbluehat> s/grou/group
16:49:41 <bigbluehat> ... manu approved it. dmitriz approved it
16:49:59 <bigbluehat> dmitriz: ...there's an IPR flag
16:50:05 <bigbluehat> ... that seems to be the blocker
16:50:06 <Wip> q+
16:50:14 <ottomorac> ack Wip
16:50:18 <bigbluehat> ottomorac: so the person needs to sign something?
16:50:33 <bigbluehat> pchampin: if it's a non-substantial contribution, the PR can be marked in the bot UI as non-substantial
16:50:34 <manu> q+
16:50:42 <bigbluehat> ... if it is substantial, then this person needs to sign something
16:51:07 <bigbluehat> ... chairs should have that privilege, or I can do it
16:51:12 <ottomorac> ack manu
16:51:13 <bigbluehat> ... but I'd defer to the group
16:51:18 <bigbluehat> Wip: they seem non-substantial
16:51:26 <bigbluehat> manu: yes, they're non-substantive
16:51:42 <bigbluehat> ... they're also in full agreement with the suggestions of the group
16:51:55 <bigbluehat> Wip: now to figure out how to do it. :)
16:51:59 <manu> q+
16:52:01 <bigbluehat> ottomorac: k. 9 minutes left
16:52:11 <bigbluehat> ... Wip any particular issue left?
16:52:22 <bigbluehat> ... we've discussed most of the others
16:52:29 <bigbluehat> ... and most have a PR or are ready for PR
16:52:39 <ottomorac> ack manu
16:52:42 <bigbluehat> ... the message at this point, is please be reviewing PRs!
16:52:47 <bigbluehat> manu: this is a question for PA
16:53:16 <bigbluehat> ... the DID 1.1 spec was published as a CR, but I'm still not seeing it on the website
16:53:23 <bigbluehat> ... does the CR displace the TR?
16:53:31 <bigbluehat> ... or does that only happen when we go to rec?
16:53:50 <bigbluehat> pchampin: I'm sorry I didn't check, so I don't know exactly where we should be
16:53:57 <bigbluehat> ... CR does update TR
16:54:03 <bigbluehat> ... I can look into that
16:54:13 <bigbluehat> ... it's still marked as a Working Draft
16:54:21 <bigbluehat> manu: it looks like it stopped updating in September
16:54:33 <bigbluehat> ... but we need to get the 1.1 URL reflecting that it's at CR
16:54:41 <bigbluehat> pchampin: it's likely just me missing some buttons at some point
16:54:45 <Wip> q+
16:54:46 <bigbluehat> ... but I'll get to it soon!
16:54:48 <bigbluehat> manu: thanks
16:55:04 <bigbluehat> pchampin: manu when was it that there was a resolution
16:55:11 <bigbluehat> manu: it was right before or right after TPAC
16:55:12 <ottomorac> ack Wip
16:55:21 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/265
16:55:21 <bigbluehat> Wip: I wanted to go back to the PRs, actually
16:55:30 <bigbluehat> Wip: this one needs a review
16:55:33 <bigbluehat> ... it's about errors
16:55:36 <bigbluehat> ... I've removed a bunch
16:55:50 <bigbluehat> ... but how do we handle where errors defined in the spec weren't used anywhere
16:55:56 <bigbluehat> ... I've added sections to use them
16:56:00 <bigbluehat> ... but I do need reviews
16:56:10 <bigbluehat> ... and we can discuss it if/as needed on a future call
16:56:19 <bigbluehat> ... it is a relatively substantial change
16:56:40 <bigbluehat> ottomorac: yeah, reviews are really the main thing
16:56:56 <bigbluehat> ... if there are no other concerns, we'll see you next week!
16:57:00 <bigbluehat> ... thanks all
16:58:05 <ottomorac> rrsagent, make minutes
16:58:06 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/08-did-minutes.html ottomorac
16:58:46 <ottomorac> m2gbot, link issues with transcript
16:58:47 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/259#issuecomment-3724786902
16:58:48 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/255#issuecomment-3724787067
16:58:49 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/257#issuecomment-3724787231
16:58:50 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/215#issuecomment-3724787415
16:58:51 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/265#issuecomment-3724787547
16:59:24 <ottomorac> zakim, please excuse us
16:59:24 <Zakim> leaving.  As of this point the attendees have been ottomorac, Wip, swcurran, manu, bigbluehat, KevinDean, dmitriz, JennieM, JoeAndrieu, smccown, pchampin
16:59:24 <Zakim> Zakim has left #did
17:00:02 <ottomorac> rrsagent, make minutes
17:00:03 <RRSAgent> I have made the request to generate https://www.w3.org/2026/01/08-did-minutes.html ottomorac
17:03:55 <ottomorac> RRSAgent, please excuse us
17:03:55 <RRSAgent> I see no action items