15:44:56 <RRSAgent> RRSAgent has joined #did
15:45:00 <RRSAgent> logging to https://www.w3.org/2025/01/30-did-irc
15:45:03 <Wip> rrsagent, draft minutes
15:45:04 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/30-did-minutes.html Wip
15:45:09 <Wip> rrsagent, make logs public
15:45:24 <Wip> Meeting: Decentralized Identifier Working Group
15:45:31 <Wip> Chair: Will Abramson
15:45:34 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Jan/0012.html
15:51:19 <Wip> present+
15:59:34 <markus_sabadello> markus_sabadello has joined #did
16:00:22 <pchampin> present+
16:01:09 <markus_sabadello> present+
16:01:43 <KevinDean> KevinDean has joined #did
16:01:47 <KevinDean> present+
16:02:08 <JoeAndrieu> JoeAndrieu has joined #did
16:02:10 <bigbluehat> bigbluehat has joined #did
16:02:31 <bigbluehat> present+
16:02:50 <ivan> present+
16:02:53 <bigbluehat> scribe+
16:03:14 <swcurran> swcurran has joined #did
16:03:31 <Wip> Topic: Agenda Review
16:03:56 <bigbluehat> Wip: because msporny can't join us, we're mostly going to focus on DID resolution
16:04:05 <Wip> q?
16:04:06 <bigbluehat> ... anything else folks want on today's agenda?
16:04:26 <smccown> smccown has joined #did
16:04:28 <Wip> Topic: APAC DIDWg call
16:04:28 <TallTed> present+
16:04:45 <bigbluehat> Wip: next week is the first Thursday of the month
16:04:48 <smccown> present+
16:05:01 <bigbluehat> ... we have been following a pattern of having APAC focused calls at a different time for that region
16:05:14 <bigbluehat> ... however, next week, I'm away next week
16:05:24 <bigbluehat> ... typically, I am also unable at this time, and neither is Dan
16:05:34 <bigbluehat> ... consequently, I'm going to have to cancel next week's call
16:05:44 <bigbluehat> ... unless someone on this call is willing to run the call
16:05:52 <bigbluehat> ... if you are interested in doing that, please reach out
16:05:59 <swcurran> present+
16:06:16 <bigbluehat> ... we may also have someone in that timezone who can run the call and msporny should be there
16:06:31 <bigbluehat> ... I'd prefer not to cancel as we've heard there's good engagement on those calls
16:07:01 <bigbluehat> ... if we can find another chair, we could potentially move the call time to be friendlier for EU and APAC together
16:07:12 <bigbluehat> ... and have a US-side chair run this call
16:07:24 <Wip> q?
16:07:24 <bigbluehat> ... just something to  consider
16:07:26 <markus_sabadello> q+
16:07:30 <Wip> ack markus_sabadello
16:07:35 <JennieM> JennieM has joined #did
16:07:40 <JennieM> present+
16:07:56 <bigbluehat> markus_sabadello: if there's a call for EU and APAC calls, that would be a possibility for me
16:08:04 <bigbluehat> ... when is next week's call?
16:08:10 <bigbluehat> Wip: it's at 2 am your time
16:08:18 <bigbluehat> ... it's currently marked as tentative
16:08:36 <bigbluehat> ... I'm not hearing any strong concerns around cancelling it
16:08:49 <bigbluehat> ... so I will likely send out a cancellation for that next Tuesday
16:09:16 <Wip> Topic: DID Resolution PR Updates
16:09:28 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3Aready-for-pr
16:09:36 <bigbluehat> Wip: I'd like to very quickly look through the things marked as "ready for PR"
16:09:50 <bigbluehat> ... if you have anything assigned to you and you're on the call, we could also talk about those
16:09:58 <bigbluehat> ... and assign the ones which are not yet assigned
16:10:08 <bigbluehat> ... let's start with the 3 that are not assigned first
16:10:09 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/109
16:10:24 <bigbluehat> Wip: first up, I have issue 109
16:10:36 <bigbluehat> ... markus_sabadello any comments?
16:10:38 <markus_sabadello> q+
16:10:40 <Wip> ack markus_sabadello
16:10:44 <bigbluehat> ... or is anyone able to take this on?
16:10:50 <bigbluehat> markus_sabadello: that's an easy one
16:11:08 <bigbluehat> ... if you'd like to get into the commit history, this is a good first issue
16:11:30 <bigbluehat> swcurran: I'll take it
16:11:39 <bigbluehat> Wip: k. I'll assign it to you or maybe markus_sabadello can?
16:11:47 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/61
16:11:51 <bigbluehat> ... the next one that's ready is 61
16:11:57 <markus_sabadello> q+
16:12:01 <bigbluehat> ... service endpoint construction inconsistency
16:12:01 <Wip> ack markus_sabadello
16:12:07 <bigbluehat> markus_sabadello: this one is more complicated
16:12:19 <bigbluehat> ... it has to do with the service parameter
16:12:24 <bigbluehat> ... and a relative ref parameter
16:12:40 <bigbluehat> ... they can be used together to point at a service endpoint plus the relative reference
16:13:01 <bigbluehat> ... someone will have to go through the algorithm and fix the references
16:13:27 <bigbluehat> ... and if no one wants to, I can assign it to myself
16:13:40 <bigbluehat> ... but it'd be great to have more contributors
16:13:43 <Wip> q?
16:14:09 <bigbluehat> Wip: I agree with markus_sabadello, these issues would be great opportunities to get involved
16:14:15 <bigbluehat> ... we appreciate help
16:14:32 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/53
16:14:48 <bigbluehat> Wip: issue 53 - disallow remote context retrieval
16:14:54 <bigbluehat> ... this is suggesting a normative statemen
16:15:02 <bigbluehat> s/statemen/statement
16:15:08 <markus_sabadello> q+
16:15:13 <Wip> ack markus_sabadello
16:15:16 <bigbluehat> ... this is about nor making remote requests for contexts in a production environment
16:15:42 <bigbluehat> markus_sabadello: this often comes up with any JSON-LD context, that they should be cached to avoid man-in-the-middle attacks
16:16:00 <bigbluehat> ... there is information in the VC specification that talks about needing to cache contexts
16:16:07 <bigbluehat> ... so we could add something similar here
16:16:21 <bigbluehat> ... it could potentially go in the security considerations section
16:16:43 <bigbluehat> Wip: something like production DID resolvers MUST cache contexts?
16:16:59 <bigbluehat> ... pretty straightforward, and security considerations seems like a reasonable location
16:17:03 <bigbluehat> ... any takers?
16:17:33 <bigbluehat> ... I'll take it
16:17:44 <JoeAndrieu> q+
16:17:48 <bigbluehat> Wip: I wanted to open the door to JoeAndrieu and swcurran
16:17:54 <Wip> ack JoeAndrieu
16:18:03 <bigbluehat> s/swcurran/smccown
16:18:13 <Wip> Topic: DID Resolution Enhancements
16:18:16 <bigbluehat> smccown: thanks for the reminder. I'd forgotten
16:18:19 <bigbluehat> JoeAndrieu: likewise
16:18:29 <bigbluehat> Wip: we had a bunch of good discussion last week
16:18:32 <Wip> https://github.com/w3c/did-resolution/issues?q=is%3Aissue%20state%3Aopen%20label%3Aenhancement%20%20sort%3Aupdated-asc
16:18:34 <bigbluehat> ... and there are about 7 of these left
16:18:42 <bigbluehat> ... it's in recently updated order
16:18:55 <bigbluehat> ... the aim of this is to decide as a group if these are extensions
16:19:13 <bigbluehat> ... and if so, who's going to take on the task of doing the work over there
16:19:30 <bigbluehat> ... or are these core to the DID specification and we should spend time bringing them into the core specification
16:19:34 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/38
16:20:12 <bigbluehat> Wip: should we say that conformant resolvers MUST be public?
16:20:17 <bigbluehat> JoeAndrieu: I can speak to this real quick
16:20:45 <bigbluehat> ... there's a concern that if you cannot get to the DID document itself, then whomever is preventing that access becomes the new gate-keeping authority
16:21:16 <bigbluehat> ... there's a notion that if you can't get to the document, then you don't have the same guarantees that we were trying to create here
16:21:37 <Wip> q+
16:21:43 <markus_sabadello> q+
16:21:45 <Wip> ack Wip
16:21:46 <bigbluehat> ... structurally, we sort of have to allow that you may not have the data--whether or not it is part of an authentication scheme
16:21:59 <bigbluehat> ... these were things we saw in 2019...but not sure it's still a problem now
16:22:08 <bigbluehat> Wip: I don't think we need to say they are public
16:22:18 <swcurran> q+
16:22:32 <bigbluehat> ... if it's a service you're calling, perhaps there's a way to run your own resolver?
16:22:39 <Wip> ack markus_sabadello
16:23:32 <bigbluehat> markus_sabadello: do you need to authenticate in order to get the DID document?
16:23:45 <bigbluehat> ... historically, in this community, the assumption has been that it is publicly avai
16:23:50 <bigbluehat> s/avai/available
16:24:03 <bigbluehat> ... because if that were not the case, then there is some amount of centralization
16:24:13 <bigbluehat> ... but this does come up from time to time
16:24:21 <bigbluehat> ... issue 79 is related
16:24:30 <bigbluehat> ... Christopher Alan opened that one
16:24:38 <JoeAndrieu> q+
16:24:44 <bigbluehat> ... it relates to DIDs within an enterprise or other organization
16:24:48 <Wip> ack swcurran
16:25:04 <bigbluehat> swcurran: maybe public is a problematic word here?
16:25:22 <JoeAndrieu> +1 "public" is a horrible term
16:25:25 <bigbluehat> ... did:peer for one is not public, but it does provide it to another peer without authentication
16:25:34 <JoeAndrieu> https://blog.joeandrieu.com/2011/04/10/constellations-of-privacy/
16:25:35 <Wip> ack JoeAndrieu
16:25:39 <bigbluehat> ... but it's only shared with the other party that is supposed to be able to resolve it
16:26:04 <bigbluehat> JoeAndrieu: one clarification
16:26:11 <bigbluehat> ... it is not a requirement that local resolution be possible
16:26:29 <bigbluehat> ... some methods do have that as an option, but others do no
16:26:32 <bigbluehat> s/no/not
16:26:40 <markus_sabadello> q+
16:26:44 <Wip> ack markus_sabadello
16:26:51 <bigbluehat> Wip: should we continue to discuss this one?
16:27:03 <bigbluehat> markus_sabadello: we should probably get Christopher's opinion
16:27:20 <bigbluehat> ... or maybe have a special topic call? or dedicate 30 minutes on this topic?
16:27:26 <bigbluehat> Wip: that's a great idea
16:27:35 <bigbluehat> ... I'll try to find a good chunk of a call on this topic
16:27:39 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/7
16:27:56 <bigbluehat> Wip: this is about supporting DIDs on service endpoints
16:28:06 <bigbluehat> ... DIDs can be used as service endpoints currently
16:28:18 <bigbluehat> ... endpoints are URLS, so they can be set to a DID
16:28:33 <bigbluehat> ... do we need a parameter in the resolution spec that supports redirection?
16:28:37 <markus_sabadello> q+
16:28:40 <Wip> ack markus_sabadello
16:28:46 <bigbluehat> ... so that you can get to the final destination for that service?
16:28:55 <bigbluehat> markus_sabadello: I remeber that the idea is really useful
16:29:13 <bigbluehat> ... maybe using a parameter resolver would find the final service endpoint
16:29:22 <bigbluehat> ... I don't think anyone has actually explored this, however
16:29:28 <bigbluehat> ... it sounds interesting and useful
16:29:32 <bigbluehat> ... but no one has used it
16:29:43 <bigbluehat> ... so I'm not sure it needs to be in the core specification
16:29:55 <bigbluehat> Wip: so, maybe the redirection piece is an extension?
16:30:22 <bigbluehat> ... should we be changing any of the specs to show a service endpoint that is a DID?
16:30:27 <bigbluehat> ... that might be an action here
16:30:37 <swcurran> q+
16:30:40 <bigbluehat> markus_sabadello: but if we do an example, we also need to explain what it means and what is possible
16:30:40 <Wip> ack swcurran
16:31:00 <bigbluehat> swcurran: my two cents would be to close it and say you can do it, nothing says you can't, but we don't need an example
16:31:13 <bigbluehat> Wip: good perspective
16:31:17 <bigbluehat> ... let's move on then
16:31:24 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/85
16:31:46 <bigbluehat> Wip: this is about, do we want a parameter on services to find them by type
16:31:59 <markus_sabadello> q+
16:32:01 <Wip> ack markus_sabadello
16:32:14 <bigbluehat> markus_sabadello: it feels like a really useful feature
16:32:27 <bigbluehat> ... it's very close to the rest of the data model and resolution
16:32:40 <bigbluehat> ... we already have a way of referencing a service by it's identifier
16:32:41 <Wip> q+
16:32:47 <bigbluehat> ... so adding type seems logical
16:32:48 <Wip> ack Wip
16:32:52 <bigbluehat> Wip: thanks, markus_sabadello
16:33:00 <bigbluehat> ... I think it is a useful thing
16:33:05 <JoeAndrieu> q+ to say isn't this dereferencing
16:33:09 <bigbluehat> ... but where does that lie? is that for the resolver?
16:33:13 <Wip> ack JoeAndrieu
16:33:13 <Zakim> JoeAndrieu, you wanted to say isn't this dereferencing
16:33:16 <bigbluehat> ... or the client post resolution?
16:33:26 <bigbluehat> JoeAndrieu: my comment is very much in that direction
16:33:35 <bigbluehat> ... this is more about dereferencing than resolution
16:33:45 <markus_sabadello> q+
16:33:48 <Wip> ack markus_sabadello
16:33:51 <bigbluehat> ... because when I do resolution, is the expectation that I'd only get part of the document back?
16:33:57 <bigbluehat> markus_sabadello: agreed with JoeAndrieu
16:34:04 <bigbluehat> ... resolution returns the DID document
16:34:14 <bigbluehat> ... so this would happen after that and be about dereferencing
16:34:29 <bigbluehat> ... there's another section that talks about different architectural components
16:35:17 <bigbluehat> Wip: anyone up for championing this issue?
16:35:32 <bigbluehat> ... the work would about how to define the types
16:35:37 <bigbluehat> ... and then how to dereference them
16:35:50 <bigbluehat> markus_sabadello: you can assign it to me
16:35:58 <bigbluehat> Wip: go for it markus_sabadello, thanks
16:36:05 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/90
16:36:33 <bigbluehat> Wip: can one dereference a DID document to a specific verification method
16:36:44 <bigbluehat> ... do we want this to be standard across all the specifications?
16:36:50 <bigbluehat> ... we talked about this before
16:37:09 <markus_sabadello> q+
16:37:11 <bigbluehat> ... and manu mentioned it was already in the CID specification
16:37:12 <Wip> ack markus_sabadello
16:37:26 <bigbluehat> markus_sabadello: I think it's useful and be in the specification
16:37:41 <bigbluehat> ... we can reference the algorithm in the controlled identifier document specification
16:37:58 <bigbluehat> ... another thing manu pointed out is whether it should be a parameter
16:38:08 <bigbluehat> ... which would put it into the URL
16:38:09 <ivan> Manu may have referred to this: https://www.w3.org/TR/cid-1.0/#retrieve-verification-method
16:38:13 <bigbluehat> ... or should it be an option
16:38:24 <bigbluehat> ... in that way it is separate from the URL itself
16:38:32 <bigbluehat> ... and this case it may be better as an option
16:38:40 <bigbluehat> Wip: what do others think?
16:39:25 <bigbluehat> ... my question is why not make it a parameter?
16:39:44 <bigbluehat> ... not hearing much interest in this one
16:39:54 <bigbluehat> ... I did open it, but let's leave it for now
16:40:00 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/66
16:40:20 <bigbluehat> Wip: this is related to parameters as well
16:40:28 <bigbluehat> ... things like version and time
16:40:40 <bigbluehat> ... we might add this to extensions
16:41:02 <markus_sabadello> q+
16:41:06 <Wip> ack markus_sabadello
16:41:06 <bigbluehat> ... but there are questions about option use across all methods
16:41:14 <bigbluehat> markus_sabadello: I don't think this should be an extension
16:41:26 <bigbluehat> ... this is already in use by a number of did methods
16:41:46 <bigbluehat> ... there are use cases where you have `?version_id=` already
16:42:14 <bigbluehat> ... there is already some text around version parameters and examples in the dereferencing algorithm section
16:42:37 <bigbluehat> ... we just need to add a few things about what a dereferencer is supposed to do
16:42:51 <bigbluehat> Wip: I agree, but we don't list these properties in the did metadata section
16:43:02 <bigbluehat> ... because they're listed in a different section
16:43:10 <Wip> https://w3c.github.io/did-extensions/resolution/#parameters
16:43:14 <bigbluehat> ... maybe I misread this
16:43:30 <bigbluehat> ... some of those parameters are in the core spec, but we also list them in the extensions
16:43:42 <bigbluehat> ... but in did resolution we list some, which are not in the extensions list
16:43:45 <Wip> https://w3c.github.io/did-extensions/resolution/#did-resolution-metadata
16:43:49 <bigbluehat> markus_sabadello: yeah, I think you're right
16:44:01 <bigbluehat> ... we have some for URLs, but not for resolution
16:44:09 <bigbluehat> Wip: what I proposed was maybe not quite right
16:44:20 <bigbluehat> ... I was proposing that they be equivalent spaces
16:44:34 <bigbluehat> ... but some of these are only applicable for dereferencing
16:44:41 <bigbluehat> markus_sabadello: and the spec already says that
16:45:06 <bigbluehat> ... but you could also just resolve the DID and pass the resolution options then
16:45:16 <bigbluehat> Wip: maybe that's the change?
16:45:24 <bigbluehat> ... copying the version parameters across
16:45:38 <bigbluehat> ... I'm happy to take on that change to DID extensions
16:45:52 <bigbluehat> ... but markus_sabadello it seemed like there was more to explore here? and maybe we need other issues?
16:45:56 <bigbluehat> markus_sabadello: yes
16:46:30 <bigbluehat> Wip: I'll take the DID extensions bit on, but then we should come back to the TODOs in the specification
16:46:35 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/59
16:46:36 <bigbluehat> ... k. we have 2 more
16:46:57 <bigbluehat> Wip: I believe this issue is around asking that one only wants certain things back
16:47:04 <bigbluehat> ... do you want all or some of the metadata, etc.
16:47:05 <markus_sabadello> q+
16:47:11 <Wip> ack markus_sabadello
16:47:28 <bigbluehat> markus_sabadello: this is about getting a result
16:47:36 <bigbluehat> ... do you want the document and the metadata or just the document?
16:47:44 <bigbluehat> ... to some extent this is possible already
16:47:54 <bigbluehat> ... you can do this with Accept headers and content negotiation
16:48:09 <bigbluehat> ... you could get just the DID document or also include the metadata
16:48:22 <bigbluehat> ... I had a conversation earlier around linked resources
16:48:30 <bigbluehat> ... situations where you can reference images, etc.
16:48:43 <bigbluehat> ... is there a way to just return the content? or just the metadata? or both?
16:48:50 <bigbluehat> ... and what would be the mechanisms for doing that?
16:49:02 <JoeAndrieu> q+ to say this is dereferencing, not resolution
16:49:06 <bigbluehat> ... the way it is right now with media types seems straightforward
16:49:18 <bigbluehat> ... I asked a coworker to post about this if it was still needed
16:49:23 <Wip> ack JoeAndrieu
16:49:23 <Zakim> JoeAndrieu, you wanted to say this is dereferencing, not resolution
16:49:24 <bigbluehat> ... so maybe we wait for that comment
16:49:29 <bigbluehat> Wip: and we can mark it pending closed
16:49:44 <bigbluehat> JoeAndrieu: it seems to me that resolution would always be the whole document
16:49:56 <bigbluehat> ... and in dereferencing you could use a subset
16:50:09 <bigbluehat> Wip: I think this is slightly different because of the metadata
16:50:26 <bigbluehat> JoeAndrieu: yes, but you never get back a subset of the did document
16:50:36 <bigbluehat> Wip: right. I don't think that is what this issue is asking for
16:50:48 <bigbluehat> ... either way JoeAndrieu you sound aligned with this pending closed plan
16:50:57 <bigbluehat> JoeAndrieu: yeah. I was imagining this was something else
16:51:11 <bigbluehat> Wip: markus_sabadello maybe you can talk to the other person about providing more detail?
16:51:13 <bigbluehat> markus_sabadello: yes
16:51:14 <Wip> subtopic: https://github.com/w3c/did-resolution/issues/5
16:51:26 <bigbluehat> Wip: this is about how do we handle deactivated dids
16:51:29 <markus_sabadello> q+
16:51:34 <Wip> ack markus_sabadello
16:51:46 <bigbluehat> markus_sabadello: we discussed this a couple weeks ago
16:51:54 <bigbluehat> ... there's been a few more thoughts since then
16:52:17 <bigbluehat> ... if a DID is deactivated and then you try to resolve it, what happens
16:52:37 <bigbluehat> ... currently, you just get info that it was deactivated, but you do not get the DID document
16:52:54 <bigbluehat> ... but there's been discussion about returning the document if explicitly asked
16:53:01 <bigbluehat> ... but some DID methods do not support that
16:53:14 <bigbluehat> ... if the document is deactivated, it's the same as if it never existed
16:53:29 <bigbluehat> ... so we need to review what we say about this currently
16:53:36 <bigbluehat> ... and decide if anything needs changing
16:53:37 <JoeAndrieu> q+
16:53:40 <Wip> ack JoeAndrieu
16:53:50 <bigbluehat> JoeAndrieu: I'm confused by what we think we're allowed to say
16:54:03 <bigbluehat> ... DID core makes a clear distinction between revoked and not revoked
16:54:11 <bigbluehat> ... I don't think we get to say you don't have to do that
16:54:12 <markus_sabadello> q+
16:54:16 <Wip> ack markus_sabadello
16:54:41 <bigbluehat> Wip: part of the discussion is that if the resolver comes across a deactivated did, what should they respond with?
16:54:50 <bigbluehat> ... just the metadata? or the document?
16:55:00 <bigbluehat> markus_sabadello: current spec says quite clearly what should happen
16:55:06 <bigbluehat> ... and it is not up to the methods
16:55:19 <bigbluehat> ... the core spec says you only get the metadata back with `deactivated: true`
16:55:32 <bigbluehat> ... if you use an HTTPS binding, then it gets a 406 error
16:55:53 <JoeAndrieu> q+ to talk about the did document when deactivated
16:55:59 <bigbluehat> ... maybe there is a point to providing more information about this scenario
16:56:00 <Wip> ack JoeAndrieu
16:56:00 <Zakim> JoeAndrieu, you wanted to talk about the did document when deactivated
16:56:08 <bigbluehat> ... but I don't believe it is up to the methods
16:56:31 <bigbluehat> JoeAndrieu: we have had a conversation around whether there is a thing called a DID document once it's deactivated
16:56:40 <bigbluehat> ... you could potentially ask for an earlier time state
16:57:02 <bigbluehat> ... but if you request a deactivated DID, the result is that it should not be there
16:57:11 <bigbluehat> ... I don't think methods can ignore that
16:57:27 <bigbluehat> Wip: maybe this is just about an extension?
16:57:35 <bigbluehat> ... so, let's move to comments in the issue
16:57:44 <bigbluehat> ... k. I think that's a wap
16:58:01 <bigbluehat> ... next week, probably not going to have a call
16:58:06 <bigbluehat> ... I'll let you know on Tuesday
16:58:10 <bigbluehat> ... talk soon
16:58:20 <bigbluehat> ... thanks, bigbluehat for scribing.
16:58:57 <pchampin> JoeAndrieu, https://www.w3.org/TR/did-1.0/#dfn-deactivated makes me think that there *can* be a DID document for a deactivated DID...
17:00:50 <pchampin> RRSAgent, make minutes
17:00:51 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/30-did-minutes.html pchampin
17:01:01 <bigbluehat> pchampin: doesn't look like that says anything about the document itself, only the metadata
17:02:34 <pchampin> s/pchampin: doesn't/<bigbluehat> pchampin, doesn't
17:02:50 <pchampin> present+ JoeAndrieu
17:02:52 <pchampin> RRSAgent, make minutes
17:02:53 <RRSAgent> I have made the request to generate https://www.w3.org/2025/01/30-did-minutes.html pchampin