14:49:53 <RRSAgent> RRSAgent has joined #did
14:49:57 <RRSAgent> logging to https://www.w3.org/2025/08/14-did-irc
14:49:59 <Wip> rrsagent, draft minutes
14:50:00 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/14-did-minutes.html Wip
14:50:04 <Wip> rrsagent, make logs public
14:50:14 <Wip> Meeting: Decentralized Identifier Working Group
14:50:17 <Wip> Chair: Wip
14:50:22 <Wip> Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Aug/0001.html
14:53:01 <ottomorac> ottomorac has joined #did
14:57:38 <TallTed> TallTed has joined #did
14:59:33 <KevinDean> KevinDean has joined #did
14:59:37 <Wip> present+
14:59:56 <KevinDean> present+
15:00:04 <ottomorac> present+
15:00:44 <TallTed> present+
15:01:05 <bigbluehat> present+
15:01:28 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/14-did-minutes.html TallTed
15:01:34 <pchampin> present+
15:01:37 <JoeAndrieu> JoeAndrieu has joined #did
15:02:16 <brentz> brentz has joined #did
15:03:14 <TallTed> previous meeting: https://www.w3.org/2025/08/07-did-minutes.html
15:03:16 <TallTed> next meeting: https://www.w3.org/2025/08/20-did-minutes.html
15:03:49 <ottomorac> scribe+
15:04:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/14-did-minutes.html TallTed
15:04:35 <markus_sabadello> markus_sabadello has joined #did
15:04:48 <Wip> Topic: DID Method Charter Discussion
15:04:53 <ottomorac> Wip: Welcome to the call today we will be mostly focused on DID Resolution..... but first lets talk about the DID Methods WG charter...
15:05:29 <Wip> q+
15:05:32 <pchampin> q+
15:05:43 <Wip> ack Wip
15:05:43 <ottomorac> Manu: The last time we checked, the charter was ready to be sent out... wondering what is the status, and if we are ready to send this to members for voting?  Just mindful TPAC is coming up...
15:06:06 <Wip> ack pchampin
15:06:12 <ottomorac> Wip:  I thought we were going to have day in TPAC for this?
15:06:22 <manu> q+ to say "green light!" :)
15:06:31 <Wip> Can see the current meetings here: https://github.com/w3c/tpac2025-meetings/issues?q=is%3Aissue%20state%3Aopen%20did
15:06:59 <ottomorac> pchampin:  I was waiting on the green light from you all,  we do need a horizontal review on the charter, I am happy to help facilitate that...
15:07:28 <Wip> ack manu
15:07:28 <Zakim> manu, you wanted to say "green light!" :)
15:07:36 <ottomorac> pchampin: I think the idea is to try to have a meeting on this for TPAC, depending on if we get any objections or not
15:07:51 <ottomorac> Manu: Yes green light, let's move forward.
15:07:52 <JoeAndrieu> q+
15:08:01 <Wip> ack JoeAndrieu
15:08:22 <ottomorac> JoeAndrieu: I do expect to formally object....
15:08:29 <manu> q+
15:08:39 <Wip> ack manu
15:10:09 <manu> q+
15:10:11 <ottomorac> Manu: I understand Joe, I was hoping this could be avoided, but ok let's move forward with the process. We can have the council review and during TPAC we can decide how to handle it.
15:10:21 <Wip> ack manu
15:10:47 <ottomorac> swcurran: Can we move this to IETF or some other way to expedite it?
15:11:00 <ottomorac> Manu: Unfortunately no, we have to go through the process....
15:11:11 <bigbluehat> q+ to ask Joe what his alternative proposal is
15:11:22 <Wip> ack bigbluehat
15:11:22 <Zakim> bigbluehat, you wanted to ask Joe what his alternative proposal is
15:11:50 <swcurran> swcurran has joined #did
15:11:56 <JoeAndrieu> q+
15:12:01 <ottomorac> bigbluehat: I want to hear a brief summary from Joe about what the objection is and what the suggested alternative would be....
15:12:12 <Wip> ack JoeAndrieu
15:12:37 <ottomorac> JoeAndrieu:  I have 2 positions, first one we should not have a single wg....
15:12:59 <ottomorac> JoeAndrieu:  Also did:web and its derivates should take over the CID spec...
15:13:17 <Wip> Topic: DID Resolution PRs
15:13:17 <TallTed> s/derivates/derivatives/
15:13:23 <Wip> https://github.com/w3c/did-resolution/pulls
15:13:38 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/171
15:13:40 <ottomorac> Wip: ok now to review the PRs...
15:14:00 <ottomorac> Wip: I think this one is good to go, want to give folks one final chance to review...
15:14:07 <markus_sabadello> q+
15:14:10 <Wip> ack markus_sabadello
15:14:28 <ottomorac> markus_sabadello: yes I think this can be merged....
15:14:39 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/175
15:14:41 <ottomorac> Wip: yes would appreciate reviews...
15:14:59 <markus_sabadello> q+
15:15:02 <Wip> ack markus_sabadello
15:15:06 <ottomorac> Wip:  This one is for the API definition
15:15:31 <ottomorac> s/API definition/Open API Definition/
15:16:07 <ottomorac> markus_sabadello:  Yes this adds a few more details to the OpenAPI definition, especially metadata fields such as "created", "updated", and resolution options such as "versionId", "versionTime".
15:16:39 <ottomorac> markus_sabadello: And this is a non-normative change...
15:16:42 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/14-did-minutes.html TallTed
15:16:55 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/176
15:17:18 <ottomorac> Wip: This one changes the RFC referenced in the spec...
15:17:30 <swcurran> present+
15:18:04 <ottomorac> markus_sabadello: Yes it is the reference to the RFC for the HTTP semantics, so just updating those references.... the issue was originally opened by a W3C bot that detects obsolete RFCS...
15:18:06 <Wip> subtopic: https://github.com/w3c/did-resolution/pull/178
15:18:29 <ottomorac> Wip:  This one improves the method architectures...
15:18:49 <ottomorac> markus_sabadello: Yes would like to discuss this one together with 179...
15:19:05 <ottomorac> markus_sabadello: This tackles the did method architectures discussion...
15:19:35 <ottomorac> markus_sabadello: We are addressing some of the open issues regarding how to trust did resolution...
15:20:11 <Wip> Wip has joined #did
15:20:22 <ottomorac> markus_sabadello:  I hope the changes reflect a move in the right direction...  it is important to note that these PRs add a proof property if the metadata and resolution sections...
15:20:54 <ottomorac> markus_sabadello: so that these proofs can be verified by resolver...
15:20:54 <Wip> q?
15:21:02 <JoeAndrieu> q+
15:21:07 <ottomorac> Wip: would be great to get some reviews on this one...
15:21:22 <Wip> ack JoeAndrieu
15:21:49 <ottomorac> JoeAndrieu: I had not seen a new type of class on line 175...
15:21:57 <manu> q+
15:21:59 <markus_sabadello> q+
15:21:59 <Wip> ack markus_sabadello
15:22:12 <ottomorac> JoeAndrieu: I think its not clear if these are normative or not, "advisements"
15:22:53 <ottomorac> Manu: typically "advisements" are strongly worded suggestions...
15:23:35 <ottomorac> Manu: however this looks more like something that should be a note and not an "advisement"...
15:23:39 <Wip> ack markus_sabadello
15:23:45 <Wip> ack manu
15:24:18 <ottomorac> markus_sabadello: Thanks for clarifying, I did think about just making it a note.... however I felt they should a little more weight....
15:24:39 <manu> q+
15:24:46 <Wip> ack manu
15:24:53 <ottomorac> markus_sabadello:  I am fine with making it a note if required...
15:25:26 <ottomorac> Manu: Also wondering if these should be a security consideration since it talks about how to handle did resolution results...
15:25:44 <ottomorac> Manu: since the validation of the proofs is a security concern...
15:26:08 <ottomorac> Wip: Yes I agree...
15:26:30 <ottomorac> markus_sabadello: Yes that sounds good, yes I did think that some of the contents should be part of the security considerations..
15:26:38 <ottomorac> markus_sabadello: I will try to split this up...
15:26:58 <Wip> Topic: Support numbers in metadata structure
15:27:11 <Wip> https://github.com/w3c/did-resolution/issues/166
15:27:21 <manu> q+
15:27:24 <Wip> ack manu
15:27:54 <ottomorac> Manu: Yes we discussed this in one of the data integrity calls, our decision was to recommend to this group that we allow numbers....
15:28:34 <Wip> q+
15:28:39 <KevinDean> KevinDean has joined #did
15:28:42 <ottomorac> Manu: And then in the Data Integrity spec we would add a security consideration to manage the floating point consideration and how to manage certain types of numbers...
15:30:06 <ottomorac> Manu:  Secondly, I would like to potentially throw errors, JSON-LD silently handles errors... but this might be handled with a "safe mode" for JSON-LD such that errors are thrown for some types of numbers....
15:30:43 <Wip> ack Wip
15:30:46 <ottomorac> Manu: this should manage how certain numbers are serialized, devs need to be careful with this...
15:30:50 <swcurran> q+
15:31:11 <ottomorac> Wip: Yes we need to be clear on what aspects of this affect the DID resolution spec...
15:31:14 <manu> q+
15:31:16 <Wip> ack swcurran
15:32:03 <ottomorac> swcurran: One thing that I did not hear, was that the advise on how to stringfy these complex numbers...
15:32:16 <Wip> ack manu
15:33:03 <swcurran> q+
15:33:12 <ottomorac> manu: yes agree, we could also have that as an option, however this changes the input data in a way that the developer may not expect....
15:33:57 <swcurran> q-
15:34:05 <ottomorac> manu: This may cause certain issues, and we need to clarify those. This should be discussed in the verifiable credential wg...
15:34:17 <manu> q+
15:34:26 <Wip> ack manu
15:34:36 <ottomorac> Wip: ok seems like we have a direction but then how do we forward?
15:34:43 <swcurran> q+
15:34:58 <Wip> ack swcurran
15:35:01 <ottomorac> manu:  the change in the did resolution spec should be small and just point to the Data Integrity spec....
15:35:23 <ottomorac> swcurran: Yes but the did resolution spec should be changed to add support for numbers...
15:35:55 <ottomorac> swcurran: This might make developers cranky...
15:36:10 <ottomorac> Wip: Ok so sounds like a PR, any takers?
15:36:20 <ottomorac> swcurran: I will give this a try
15:36:36 <Wip> Topic: HTTP Post method binding
15:36:49 <manu> q+
15:36:53 <Wip> https://github.com/w3c/did-resolution/issues/161
15:36:57 <markus_sabadello> q+
15:37:03 <Wip> ack manu
15:37:06 <manu> q+
15:37:06 <Wip> ack markus_sabadello
15:38:30 <ottomorac> markus_sabadello:  Yes to summarize, and the moment we have a GET binding option, but this has challenges related to the lenght (if you use a lot of resolution options), and secondly the resolution options could also be nested, resulting in complex params that are not clear how to manage...
15:38:40 <Wip> ack manu
15:38:44 <ottomorac> markus_sabadello: So the idea was to use an option for POST
15:39:54 <ottomorac> manu:  Yes this is complex one, we could also indicated how to manage the nested stuff by adding some base64 encoding.... or we just keep it simple and limit how many options can be added in the GET call....
15:40:42 <ottomorac> manu:  The third option would be just to keep it very simple and limit it to just the did parameter with no additional options and force the usage of POST for everything else....
15:41:17 <bigbluehat> q+
15:41:21 <Wip> ack bigbluehat
15:41:22 <ottomorac> manu: I would think that for simplicity that perhaps drop GET and support POST only...
15:41:46 <manu> q+ to note that's not resolution, that's dereferencing.
15:42:31 <ottomorac> bigbluehat: I think the strongest use case for GET would be HTML and SVG resources referenced in a did
15:42:34 <Wip> ack manu
15:42:34 <Zakim> manu, you wanted to note that's not resolution, that's dereferencing.
15:42:53 <manu> This would be a useful thing to be able to do in time: <img src="did:foo:/bar/baz.png">
15:43:06 <manu> This would be a useful thing to be able to do in time: <img src="did:foo:123456/bar/baz.png">
15:43:39 <TallTed> s|This would be a useful thing to be able to do in time: <img src="did:foo:/bar/baz.png">||
15:43:48 <ottomorac> manu: this is an example of pointing to an image with a did that can jump to other resources...
15:44:18 <markus_sabadello> q+
15:44:28 <bigbluehat> q+ to ask about caching
15:44:32 <Wip> ack markus_sabadello
15:44:35 <ottomorac> manu: however I don't think we need GET for this particular feature...
15:44:49 <manu> q+
15:44:59 <manu> q+ to note that we might not want them to work that way.
15:45:00 <Wip> ack manu
15:45:01 <Zakim> manu, you wanted to note that we might not want them to work that way.
15:45:02 <ottomorac> markus_sabadello:  Is this related to the service and relative reference?
15:45:39 <manu> This would be a useful thing to be able to do in time: <img src="did:foo:123456:/bar/baz.png">
15:46:10 <manu> is equivalent to this: <img src="did:foo:123456?service=agent&relativeRef=/bar/baz.png">
15:46:17 <ottomorac> manu: Yes, me and Markus have talked about this... this syntax would be effectively a relative ref...
15:47:00 <Wip> ack bigbluehat
15:47:00 <Zakim> bigbluehat, you wanted to ask about caching
15:47:06 <ottomorac> manu: I think both would be the same.... and I think ben this should also work for caching hopefully...
15:47:37 <manu> q+
15:48:08 <ottomorac> bigbluehat: I think also about how the https resolvers would manage this...
15:48:51 <Wip> ack manu
15:49:12 <ottomorac> manu:  I was presumming that a DID resolver client would do the caching internally...
15:50:10 <ottomorac> Wip: Yes this has been a good discusion.. not hearing any opposition to removing GET and supporting POST only...
15:50:14 <manu> q+
15:50:20 <Wip> ack manu
15:50:31 <markus_sabadello> q+
15:50:41 <ottomorac> manu: Question do the group, can we just do POST to keep it simple?
15:50:42 <Wip> ack markus_sabadello
15:51:08 <swcurran> +1
15:51:12 <bigbluehat> q+
15:51:16 <Wip> ack bigbluehat
15:51:17 <ottomorac> markus_sabadello: the problem is that some production deployments currently use GET and it would break a few things
15:51:32 <ottomorac> bigbluehat: I think we should support both...
15:51:41 <manu> q+ to note that just because you do optional features, doesn't mean you're non-conformant.
15:51:56 <manu> q+ to note that bigbluehat's reason is convincing to me to have both.
15:52:13 <Wip> ack manu
15:52:14 <Zakim> manu, you wanted to note that just because you do optional features, doesn't mean you're non-conformant. and to note that bigbluehat's reason is convincing to me to have both.
15:52:38 <Wip> q+
15:52:45 <Wip> ack Wip
15:52:47 <ottomorac> manu: Yes I think that is a compelling reason, but there is complexity. However also  just because you do optional features, doesn't mean you're non-conformant
15:52:54 <Wip> q+
15:52:54 <bigbluehat> q+
15:53:08 <ottomorac> manu:  The question is one which one would be mandatory to implement?
15:53:15 <Wip> ack Wip
15:53:18 <Wip> ack bigbluehat
15:53:25 <manu> yep, they need to do both :( -- which means that all those other resolvers are going to be non-conformant.
15:53:57 <ottomorac> bigbluehat: I think the poster of the issue was originally focused on the long GET strings....
15:54:48 <ottomorac> bigbluehat: we need to think about this carefully...
15:55:18 <ottomorac> bigbluehat: the code requirements may not be extreme if the URLS are "neighbourly"
15:55:55 <ottomorac> Wip: seems like we do have some direction... but then who can take on this work to define it?
15:56:18 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/14-did-minutes.html TallTed
15:56:54 <ottomorac> Wip: Ok we can leave it here for now...
15:57:20 <manu> present+
15:57:37 <pchampin> btw, regrets for next week from me
15:57:53 <Wip> rrsagent, make minutes
15:57:55 <RRSAgent> I have made the request to generate https://www.w3.org/2025/08/14-did-minutes.html Wip
15:58:12 <Wip> m2gbot, link issues with transcript
15:58:13 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/171#issuecomment-3188976800
15:58:14 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/175#issuecomment-3188976856
15:58:15 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/176#issuecomment-3188976911
15:58:16 <m2gbot> comment created: https://github.com/w3c/did-resolution/pull/178#issuecomment-3188976979
15:58:17 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/166#issuecomment-3188977025
15:58:19 <m2gbot> comment created: https://github.com/w3c/did-resolution/issues/161#issuecomment-3188977089
15:59:30 <ottomorac> ottomorac has left #did
16:32:33 <TallTed> ACTION: ora to put a note in RDF-new that "abstract syntax" is now "abstract data model"
16:33:28 <TallTed> we probably will need a consistency check across the other documents
16:33:46 <TallTed> damn! how did I change channels?
16:35:18 <TallTed> s/ACTION: ora to put a note in RDF-new that "abstract syntax" is now "abstract data model"//
16:35:24 <TallTed> s/we probably will need a consistency check across the other documents//
16:35:31 <TallTed> s/damn! how did I change channels?//
18:08:04 <Zakim> Zakim has left #did
18:17:26 <TallTed> RRSAgent, bye
18:17:26 <RRSAgent> I see 1 open action item saved in https://www.w3.org/2025/08/14-did-actions.rdf :
18:17:26 <RRSAgent> ACTION: ora to put a note in RDF-new that "abstract syntax" is now "abstract data model" [1]
18:17:26 <RRSAgent>   recorded in https://www.w3.org/2025/08/14-did-irc#T16-32-33