14:52:25 <RRSAgent> RRSAgent has joined #did
14:52:30 <RRSAgent> logging to https://www.w3.org/2025/07/10-did-irc
14:52:50 <ottomorac> rrsagent, draft minutes
14:52:52 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/10-did-minutes.html ottomorac
14:52:56 <ottomorac> rrsagent, make logs public
14:53:02 <ottomorac> Meeting: Decentralized Identifier Working Group
14:53:13 <ottomorac> Chair: ottomorac
14:53:30 <ottomorac> Agenda: https://www.w3.org/2025/07/10-did-minutes.html
14:58:15 <denkeni> denkeni has joined #did
14:59:26 <dmitriz> dmitriz has joined #did
15:00:43 <JoeAndrieu> JoeAndrieu has joined #did
15:01:17 <Wip> Wip has joined #did
15:01:37 <markus_sabadello> markus_sabadello has joined #did
15:02:12 <KevinDean> KevinDean has joined #did
15:02:16 <KevinDean> present+
15:02:30 <ottomorac> present+
15:02:31 <denkeni> present+
15:04:47 <dmitriz> present+
15:04:49 <dmitriz> scribe+
15:05:31 <manu> q+
15:05:42 <ottomorac> ack manu
15:05:42 <dmitriz> ottomorac: couple of topics today, we'll mention the special topic call yesterday, issue processing, did resolution
15:05:54 <dmitriz> manu: one thing on the review of DID Resolution. miraculously, the TAG has changed the review process based on our input
15:06:00 <dmitriz> ... on not having to write explainers for things
15:06:16 <dmitriz> ... I think it'll be good for us to try and use the new process for DID Resolution, but wanted to check with the group if others agree
15:06:19 <dmitriz> ottomorac: sounds good
15:06:32 <ottomorac> Topic: DID Methods WG Charter - Special Topic Call Debrief
15:06:39 <ottomorac> https://www.w3.org/2025/07/09-did-minutes.html
15:06:45 <brent> brent has joined #did
15:07:14 <smccown> smccown has joined #did
15:07:17 <manu> q+
15:07:18 <dmitriz> ... does anyone want to comment on the call?
15:07:19 <ottomorac> ack manu
15:07:41 <dmitriz> manu: one of the other interesting things that happened - we're explicitly not putting blockchain out of scope
15:07:43 <dmitriz> ... we're saying, if whatever you're calling blockchain is compatible with Web Architecture, that's fine
15:07:56 <dmitriz> ... that opens up the charter a bit. we'll just have to see what the AC feels about that, if anything
15:07:59 <ottomorac> q_
15:08:01 <ottomorac> q?
15:08:07 <ottomorac> Topic: GDC Conference Debrief
15:08:09 <JennieM> JennieM has joined #did
15:08:13 <Wip> q+
15:08:13 <JennieM> present+
15:08:21 <ottomorac> ack Wip
15:08:22 <smccown> present+
15:08:40 <dmitriz> Wip: one of the sessions I attended is - how sovereign states can support FOSS tech better
15:08:49 <dmitriz> ... particularly in the EU, they have several Sovereign Tech Funds
15:09:17 <dmitriz> ... maybe we can reach out to them to these funds, see if they're interested in helping us with some of the work we have to do?
15:09:43 <ottomorac> q?
15:09:47 <manu> q+ to ask if anything DID-specific was discussed?
15:09:59 <markus_sabadello> q+
15:09:59 <ottomorac> ack manu
15:09:59 <Zakim> manu, you wanted to ask if anything DID-specific was discussed?
15:10:08 <dmitriz> manu: did anyone go to any sessions where DIDs were mentioned at all?
15:10:09 <bengo> bengo has joined #did
15:10:33 <dmitriz> ... last year, some of the conversation in EU was "we're not going to use DIDs since there's no standardized DID methods"
15:10:39 <dmitriz> ... that got some pushback from EBSI, others in the EU
15:10:52 <dmitriz> ... based on that, we've been having this DID Methods WG chartering discussion
15:10:58 <dmitriz> ... to standardize some of the DID methods
15:11:06 <ottomorac> q?
15:11:09 <dmitriz> ... so, just checkign if anyone heard much discussion on DIDs at GDC
15:11:12 <ottomorac> ack markus_sabadello
15:11:53 <dmitriz> markus_sabadello: I was also there, I did have my own sessions (so did have a presentation on DIDs)
15:12:03 <dmitriz> ... kept it quite generic / intro level to explain DIDs and how they work
15:12:09 <dmitriz> ... and current state in the community
15:12:30 <dmitriz> ... so that was one. there were also several other sessions
15:12:40 <dmitriz> ... much of the topics were focused on wallets / governments
15:13:10 <dmitriz> ... some members of the community mentioned standardizing DIDs for the EU
15:13:17 <dmitriz> q+
15:13:41 <dmitriz> ... Kim from DIF was there, mentioned DID standardization efforts
15:13:51 <dmitriz> ... one session I thought was exciting was from some orgs from South Korea, representatives from the Korean gov't and startups
15:13:58 <dmitriz> ... they mentioned DIDs in a positive way
15:14:35 <dmitriz> ... specifically how it helped them reach interop between COVID credentials between Korea and Singapore
15:14:54 <dmitriz> ... so, same data model as DIDs and VCs, said the abstraction helped them achieve interop, etc
15:15:04 <ottomorac> ack dimitriz
15:15:06 <ottomorac> scribe+
15:16:03 <brent> q+
15:16:13 <ottomorac> Dimitriz: Yes, MIT was one of the organizers of the conference.  I was not there, but we do implicitly work on DIDs and were present there
15:16:19 <ottomorac> scribe-
15:16:23 <ottomorac> ack brent
15:16:31 <dmitriz> brent: other sessions where DIDs came up were the Trade session
15:16:45 <ottomorac> q?
15:16:48 <dmitriz> ... and DIDs were a core component. (also folks from SE Asia)
15:16:52 <ottomorac> ack dimitriz
15:16:54 <dmitriz> ottomorac: I heard similar, re SE Asia
15:17:01 <ottomorac> ack dmitriz
15:17:38 <bengo> There was a presentation on "China-Singapore-Hong Kong Cross-border Decentralized Identity and Credential Trials and Use Cases" that seemed to use solana but i don't remember if it used DIDs.
15:17:41 <dmitriz> manu: ok, DID Resolution. I ended up merging some of the PRs,
15:17:47 <dmitriz> ... so that leaves us 2 issues that are new
15:17:54 <ottomorac> Topic: DID Resolution Updated TAG Process
15:18:38 <dmitriz> manu: ok, TAG asked us to write a new Explainer for DIDs.
15:18:56 <JoeAndrieu> https://g.identity.com/sol-did/
15:19:04 <manu> Explainers: https://github.com/w3ctag/explainer-explainer/issues/19
15:19:11 <dmitriz> ... I did that using AI, to see if that can speed that up, and some folks on the TAG pushed back to say they're not sure if they're comfortable with that
15:19:11 <TallTed> TallTed has joined #did
15:19:29 <dmitriz> ... I pointed out that Explainers are an anti-pattern. that the spec itself should be explainable enough
15:19:42 <dmitriz> ... there was a long conversation that happened, the last 2-3 months
15:20:09 <dmitriz> ... but! it resulted in the TAG significantly changing their review process. Explainers no longer required, as long as the spec is understandable (contains the contents they're looking for)
15:20:18 <dmitriz> ... Jeffrey Yaskin put in a lot of work into it
15:20:31 <dmitriz> ... the goal here was to make the spec defend/explain itself, instead of a separate explainer doc
15:20:45 <dmitriz> ... so, for now, we can just link to the sessions in our DID spec that explains stuff, rather than separate doc
15:20:53 <dmitriz> ... for DID Core 1.1, they already did the review and were fine with it
15:21:06 <dmitriz> ... basically, I think we're ok with DID Core, passed the TAG horizontal review
15:21:12 <dmitriz> ... DID Resolution did not go through the review
15:21:42 <dmitriz> ... so question for us is -- do we want to write an Explainer? Because there's an opportunity here to not, to just point to sections in the DID Res spec
15:21:44 <dmitriz> ... to address the open issue about the did resolution explainer
15:21:55 <dmitriz> ... I suggest that we run the new process, because long term it reduces editor work load
15:22:00 <dmitriz> ... but it's up to the editors and chairs
15:22:03 <markus_sabadello> q+
15:22:12 <ottomorac> ack markus_sabadello
15:22:17 <TallTed> present+
15:22:25 <dmitriz> markus_sabadello: I think that makes a lot of sense, to use the new approach
15:22:33 <manu> q+
15:22:45 <dmitriz> ... I wonder if it makes sense to try and have everything that's supposed to be in the Explainer in one section (like Introduction). or spread across multiple?
15:23:12 <ottomorac> ack manu
15:23:26 <dmitriz> manu: I think 80% of it can go into the intro. when we did the analysis on what an Explainer does,
15:23:30 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/10-did-minutes.html TallTed
15:23:42 <dmitriz> ... it turns out 80% of the content should go into Introduction
15:23:47 <dmitriz> ... things like - what does the spec do, why did you create it, what kind of problems does it address
15:24:02 <dmitriz> ... there is one part of it that doesn't really, which is - what are the alternate technologies you considered? that could go into the Appendix
15:24:20 <dmitriz> ... the question of What kind of user-facing problems does the spec address? we could just point to the DID Use Cases doc
15:24:37 <dmitriz> ... so we could try that, see if they complain
15:24:52 <markus_sabadello> q+
15:24:58 <dmitriz> ottomorac: ok, I don't think we have any relevant PRs...
15:25:06 <dmitriz> markus_sabadello: one more thing about horizontal review process
15:25:17 <dmitriz> ... the other things we have to do have not changed, right? i18n, accessibility, etc?
15:25:20 <dmitriz> manu: correct
15:25:42 <dmitriz> ... we may want to let them know we're following the new TAG process for explainers, point to the issue
15:25:43 <dmitriz> ... in lieu of the explainer link. that's the only modification we need there
15:25:54 <ottomorac> Topic: DID Resolution Issue Processing
15:26:07 <dmitriz> ottomorac: ok, switching over to DID Res issue processing
15:26:14 <ottomorac> subtopic: Is the openAPI spec (eventually) normative or informative? #118
15:26:19 <ottomorac> https://github.com/w3c/did-resolution/issues/118
15:26:33 <dmitriz> ... 118 - is OpenAPI spec going to be normative or informative
15:26:43 <dmitriz> ... Open question as to whether the reference to OpenAPI spec is normative or informative.There was also a question about whether we can use .OAS files for the example.
15:27:03 <bengo> dmitriz there is also https://solana.id/ shilling..... $SOLID
15:27:05 <TallTed> previous meeting: https://www.w3.org/2025/07/03-did-minutes.html
15:27:05 <TallTed> next meeting: https://www.w3.org/2025/07/17-did-minutes.html
15:27:20 <bengo> (RT != endorsement)
15:27:30 <manu> q+
15:27:30 <ottomorac> q?
15:27:37 <ottomorac> ack markus_sabadello
15:27:42 <ottomorac> ack manu
15:27:49 <markus_sabadello> q+
15:28:02 <ottomorac> ack markus_sabello
15:28:07 <dmitriz> markus_sabadello: I don't really know the answer to that, re OpenAPI,
15:28:10 <dmitriz> ... maybe informative?
15:28:22 <dmitriz> ... because we're actually defining HTTP binding for DID Res in the spec itself?
15:28:28 <dmitriz> ... so OpenAPI is just a useful additional construct
15:28:32 <dmitriz> ... so, not normative
15:28:41 <manu> q+
15:28:58 <Wip> ack markus_sabadello
15:29:05 <dmitriz> ottomorac: there's also comment from Ivan - what happens when there's a conflict between spec text and OpenAPI definition?
15:29:07 <ottomorac> ack manu
15:29:21 <dmitriz> manu: two thoughts - one is, we've been dealing with the same issue in the VC API spec for 3+ years
15:29:27 <manu> https://github.com/digitalbazaar/respec-oas/
15:29:42 <dmitriz> ... it led us to create a plug-in for Respec called Respec-OAS
15:29:42 <dmitriz> ... what this does is ensure the alignment between spec text and OAS file
15:29:49 <dmitriz> ... so, it takes the OAS file as input, prints it out using RFC language
15:30:05 <dmitriz> ... it's a bit wordy and verbose, and may not be the approach here. but just noting there's that tool
15:30:17 <dmitriz> ... we're actively using/maintaining it tho
15:30:34 <dmitriz> ... comment two - if we don't more tightly bind the two, then the OAS file should be non-normative
15:31:01 <dmitriz> ... so as not to lead to spec mis-implementation etc
15:31:05 <bengo> Ideally the normative text is in plain language, and I'm not sure OAS is
15:31:17 <dmitriz> ... so, either unify the two via the tool, or make OAS non-normative.
15:31:17 <bengo> (great tool for devs, not for readers)
15:31:25 <manu> q+
15:31:30 <ottomorac> ack manu
15:31:46 <dmitriz> manu: re bengo's comment -- that is exactly what the plugin tries to do, convert the OAS language into normative plain text
15:31:56 <dmitriz> bengo: yeah, was just agreeing with you
15:32:04 <markus_sabadello> q+
15:32:10 <dmitriz> ottomorac: markus, do you need some time to think on it?
15:32:11 <ottomorac> ack markus_sabadello
15:32:19 <dmitriz> markus_sabadello: my preference would be to keep it informative for now
15:32:25 <dmitriz> ... rather than setting up the plugin for the time being
15:32:32 <dmitriz> ... since it's a very simple one endpoint API
15:32:35 <manu> agree that it's a simple API and probably don't need the overhead of respec-oas.
15:32:49 <bengo> manu if the spec loads the OAS then the 'plain language' can still be normative even if the OAS is not. only it's conversion to plain language needs to be normative imho.
15:33:03 <dmitriz> ... so, we just define spec text as normative, reference the OA as informative.
15:33:37 <manu> bengo, hmm, ok I think I understand what you mean -- and is what happens today w/ respec-oas (the OAS is never normative)
15:33:43 <dmitriz> ottomorac: ok, so the resolution is -- move the OAS file to a DIF repo, and reference it as informative
15:33:53 <bengo> manu i love that, thanks for making respec-oas
15:33:58 <ottomorac> subtopic: Model accept as the HTTP accept header #116
15:34:04 <ottomorac> https://github.com/w3c/did-resolution/issues/116
15:34:25 <dmitriz> ... The was a suggestion from Ivan to model the &ldquo;accept&rdquo; properties (both of DID and for DID URL) after the HTTP Accept header syntax. The suggestion was positively received by Markus. What would be the next steps here?
15:34:43 <markus_sabadello> q+
15:34:53 <ottomorac> ack markus_sabadello
15:35:06 <dmitriz> markus_sabadello: background was - when you invoke a resolver, you can pass the Accept header
15:35:42 <dmitriz> ... maybe the significance of this has changed a bit after we moved away from Abstract Data Model. but still has the same overall function as in HTTP
15:35:48 <dmitriz> ... even if at the moment we allow only a single mime type
15:36:05 <dmitriz> ... but in DID URL Dereferencing, we might have many different media types
15:36:39 <manu> q+ to agree, model after HTTP Accept.
15:36:48 <ottomorac> ack manu
15:36:48 <Zakim> manu, you wanted to agree, model after HTTP Accept.
15:36:58 <dmitriz> manu: +1 to what Markus said, and what Ivan was suggesting
15:37:08 <dmitriz> ... lets not reinvent the wheel and just model it after the HTTP accept header
15:37:28 <dmitriz> ottomorac: ok, consensus is to model it after HTTP Header, change the DID resolution algorithm.
15:37:42 <dmitriz> ... do we just label the issue as Ready for PR?
15:37:42 <dmitriz> markus_sabadello: yes
15:37:53 <ottomorac> subtopic: Proposal: Define DDO as "DID Descriptor Object" that can bootstrap into EDO "Entity Descriptor Object" #45
15:38:09 <ottomorac> https://github.com/w3c/did-resolution/issues/45
15:38:14 <ottomorac> There was a suggestion by Will that we incorporate at least of the 2 suggestions from Chris Allen about intermediate did documents and how did methods define interim pieces that eventually form DID documents.
15:38:32 <Wip> q+
15:38:39 <ottomorac> ack Wip
15:38:55 <dmitriz> WIp: there are some changes we can make, I'm not sure where they fit
15:39:08 <manu> q+
15:39:25 <ottomorac> ack manu
15:39:42 <dmitriz> ... there's a couple of PRs that are similar. my querstion to the group -- based on having merged this PR in DID Core, is that sufficient, or do we also want to add something to the Resolver spec?
15:39:42 <dmitriz> manu: I don't think we want to use the terms DDO and EDO anymore
15:39:58 <dmitriz> ... because of exactly what Will said -- we can just call them Intermediate DID Docs, and Resolved DID Docs
15:40:03 <markus_sabadello> q+
15:40:06 <dmitriz> ... the major concern is - we don't want to add more specialized DID terms
15:40:11 <dmitriz> ... ideally, we want to minimize those
15:40:28 <bengo> q+
15:40:34 <ottomorac> ack markus_sabadello
15:41:12 <dmitriz> markus_sabadello: agreed, we definitely don't want to introduce terms DDO and EDO. the question is - do we want to mention anything about Intermediate DID Docs, during resolution process?
15:41:24 <dmitriz> ... but as Will also mentioned, there was an issue merged today in DID Core, which talks about that a bit
15:41:36 <ottomorac> https://github.com/w3c/did/pull/894
15:41:41 <dmitriz> ... https://github.com/w3c/did/pull/894
15:42:02 <dmitriz> ... also the Read operation is defined by the DID Method, and that does whatever, in regards to the Intermediate DID doc
15:42:07 <dmitriz> ... so, we probably don't need to change spec
15:42:08 <Wip> +1 I think I agree
15:42:10 <ottomorac> ack bengo
15:42:30 <Wip> I am advocating we do nothing :)
15:42:30 <dmitriz> bengo: I'm noticing that nobody's advocating for this except Wip, who is +1 on this currently
15:42:40 <dmitriz> ... and my instinct is -- I don't see a reason to recommend against it, but maybe Wip does
15:42:44 <Wip> q+
15:42:50 <ottomorac> ack Wip
15:42:54 <dmitriz> Wip: yeah, to be clear, I'm not actually advocating we do anything
15:43:13 <bengo> I'd probably be -1 on adding that language without understanding a rationale.
15:43:38 <bengo> let's close the issue
15:43:41 <dmitriz> ... we already say DID Resolvers must return conforming DID Docs, not intermediate ones, so, no change needed
15:43:47 <manu> +1 to what Will is saying... I'm hearing that the folks providing an opinion are aligned.
15:44:03 <dmitriz> markus_sabadello: ok, I'll add these comments to the issue and we'll mark it pending closed
15:44:16 <ottomorac> subtopic: Restricted access/Authentication/Authorization #38
15:44:24 <ottomorac> https://github.com/w3c/did-resolution/issues/38
15:44:29 <ottomorac> Related to concern raised by JoeA,  that if you cannot get to the DID document itself, then whomever is preventing that access becomes the new gate-keeping authority. The agreement from the last discussion was we should probably get Christopher Allen&rsquo;s  opinion or maybe have a special topic call about this subject.
15:45:15 <dmitriz> ottomorac: it's been some time since we discussed it, so -- is that still the sentiment here, or do we take another route?
15:45:16 <manu> q+
15:45:20 <ottomorac> ack manu
15:45:41 <dmitriz> manu: looking back to what Joe said initially, I think he's just saying - the current language doesn't make it clear if Authn is out of scope, or allowed
15:45:50 <markus_sabadello> q+
15:45:56 <dmitriz> ... I think it is allowed. so, we can address the issue 'authn to the DID Res API is allowed, but is out of scope'
15:46:08 <Wip> q+
15:46:11 <JoeAndrieu> q+ to say discouraging would be good
15:46:13 <ottomorac> ack markus_sabadello
15:46:39 <dmitriz> markus_sabadello: I agree. this topic comes up rarely. usually we consider DID Resolution to be public
15:46:40 <bengo> an interop profile can be made about how the resolver (if http) can use WWW-Authenticate header to indicate supported authz schemes in a HATEOAS way.
15:46:55 <dmitriz> ... so, we can point out that it's allowed, but extensions can use auth* mechanisms
15:47:09 <ottomorac> ack Wip
15:47:38 <manu> q+ to note we can't stop bad ideas :)
15:47:41 <dmitriz> Wip: I agree it should be allowed. I just wanted to flag, is there anything about a DID Method that needs to do to be conformant? Such as, require at least one publically accessible resolver endpoint for it
15:47:45 <ottomorac> ack JoeAndrieu
15:47:45 <Zakim> JoeAndrieu, you wanted to say discouraging would be good
15:48:10 <dmitriz> JoeAndrieu: I'm pretty opposed to that. requiring any DID Method to stand up a resolvable service would centralize us, etc
15:48:17 <dmitriz> ... I think auth should be allowed, but discouraged
15:48:19 <dmitriz> q+
15:48:30 <bengo> q+
15:48:30 <dmitriz> ... so, if you can introduce a gatekeeper, then.. it'll gate keep
15:48:41 <ottomorac> ack manu
15:48:41 <Zakim> manu, you wanted to note we can't stop bad ideas :)
15:48:50 <dmitriz> manu: +1 to both things Joe said
15:48:54 <smccown> +1 to Joe's comments about not introducing new gatekeepers
15:49:16 <dmitriz> ... we should also tell people that they should have a public endpoint, even if we don't require it
15:49:22 <smccown> q+
15:49:28 <dmitriz> ... but we shouldn't add normative statements about bad ideas in the spec. (even to discourage them)
15:49:39 <markus_sabadello> q+
15:50:12 <JoeAndrieu> s/should have a public endpoint/should not need a public endpoint/
15:50:57 <dmitriz> ... nothing we write can prevent bad ideas, so let's just have language that promotes good ones
15:51:04 <ottomorac> scribe+
15:51:06 <ottomorac> ack dmitriz
15:51:34 <ottomorac> Dmitriz: So I want to clarify this to authentication on the resolver?
15:52:02 <ottomorac> Dmitriz:  we want to encourage folks to use local resolvers, and use the public ones only as a last resort right?
15:52:37 <bengo> https://letsencrypt.org/2025/07/01/issuing-our-first-ip-address-certificate/
15:52:48 <ottomorac> Dmitriz: Just want to clarify that most authorization / access would require local and we should require a public endpoint
15:52:59 <ottomorac> scribe-
15:53:07 <ottomorac> ack bengo
15:53:11 <dmitriz> bengo: I heard Joe mention a concern about something leading to a reliance on DNS
15:53:41 <dmitriz> ... and just wanted to point out that LetsEncrypt now hands out TLS certs to just IP addresses (without DNS)
15:53:41 <dmitriz> ... so, I don't think reliance on DNS is main danger ehre
15:53:41 <ottomorac> ack smccown
15:54:16 <manu> q+ to note OHTTP statements in DID Resolution?
15:54:19 <dmitriz> smccown: thank you, great comments. I wanted to point out that there are privacy implications. adding new gatekeepers gives them a new bird's eye view on who's asking for what
15:54:42 <Wip> q+
15:55:05 <dmitriz> ... I agree that we shouldn't include bad ideas / negative concerns in the spec. but we can emphasize local lookups / local resolvers, as opposed to a public resolver (which can collect usage data etc)
15:55:11 <ottomorac> ack markus_sabadello
15:55:13 <Wip> smccown I tried to capture some of  that in this PR. Be great to get your reveiw - https://github.com/w3c/did-resolution/pull/157
15:55:17 <Wip> q-
15:55:41 <dmitriz> markus_sabadello: regarding to what Steve just said about usage data / birds eye view. The one open PR that we have in DID Res right now is about that
15:55:56 <dmitriz> ... Wip wrote some language about privacy considerations, talk about the risks. so, the PR could use more reviews
15:56:08 <Wip> All good :)
15:57:38 <bengo> Wip I added a +1 to your PR
15:57:41 <dmitriz> ... so, we don't want to add normative language about auth required for the DID Method itself. but auth for resolvers is separate - we could mention those in the specs
15:57:46 <ottomorac> ack manu
15:57:46 <Zakim> manu, you wanted to note OHTTP statements in DID Resolution?
15:58:04 <JoeAndrieu> btw, +1 to Dmitri's argument.
15:58:21 <manu> https://www.w3.org/TR/vc-data-model-2.0/#device-tracking-and-fingerprinting
15:58:38 <bengo> It would be pretty great to nod to OHTTP with a MAY at least
15:58:50 <ottomorac> zakim, close the queue
15:58:52 <Zakim> ok, ottomorac, the speaker queue is closed
15:58:52 <bengo> (or no text)
15:59:16 <bengo> https://datatracker.ietf.org/doc/rfc9458/
15:59:21 <bengo> ^ OHTTP
15:59:51 <manu> present+
15:59:59 <markus_sabadello> present+
16:00:42 <ottomorac> rrsagent, make minutes
16:00:44 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/10-did-minutes.html ottomorac
16:02:27 <ottomorac> m2gbot, link issues with transcript
16:02:28 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/118#issuecomment-3058057729
16:02:29 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/116#issuecomment-3058057783
16:02:30 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/45#issuecomment-3058057819
16:02:31 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/38#issuecomment-3058057857
16:03:58 <ottomorac> zakim, end the meeting
16:03:58 <Zakim> As of this point the attendees have been KevinDean, ottomorac, denkeni, dmitriz, JennieM, smccown, TallTed, manu, markus_sabadello
16:04:00 <Zakim> RRSAgent, please draft minutes
16:04:01 <RRSAgent> I have made the request to generate https://www.w3.org/2025/07/10-did-minutes.html Zakim
16:04:07 <Zakim> I am happy to have been of service, ottomorac; please remember to excuse RRSAgent.  Goodbye
16:04:08 <Zakim> Zakim has left #did
16:04:43 <ottomorac> RRSAgent, please excuse us
16:04:43 <RRSAgent> I see no action items