14:51:46 RRSAgent has joined #did 14:51:50 logging to https://www.w3.org/2025/08/07-did-irc 14:51:57 rrsagent, draft minutes 14:51:58 I have made the request to generate https://www.w3.org/2025/08/07-did-minutes.html ottomorac 14:52:05 rrsagent, make logs public 14:52:14 Meeting: Decentralized Identifier Working Group 14:52:21 Chair: ottomorac 14:52:32 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2025Aug/0001.html 15:00:06 Wip has joined #did 15:00:36 presnt+ 15:00:39 KevinDean has joined #did 15:00:47 present+ 15:01:09 present+ 15:01:29 JoeAndrieu has joined #did 15:01:34 markus_sabadello has joined #did 15:03:21 bigbluehat has joined #did 15:03:34 scribe+ 15:04:29 markus_sabadello has joined #did 15:04:32 present+ 15:04:37 present+ 15:04:38 present+ 15:05:36 Topic: Debrief Special Topic Call for DID Resolution Test Suite on 6-Aug 15:05:40 https://github.com/w3c/did-resolution/issues/92 15:05:43 scribe+ 15:06:40 Wip: Yes the special topic call went well, Ben and Parth will be setting up the infrastructure, the plan is to keep meeting every 2 weeks on Wednesdays during the special topic call... 15:07:13 Wip: Starting with tests are going to check the correctness of did resolution... we expect the tests to be generic... 15:08:05 present+ 15:08:20 Wip: Also we decided that for these calls since they will be technical in nature and part of the objectives was to have knowledge transfer from DigitalBazaar team to the rest of the team.... 15:08:22 q+ 15:08:35 JennieM has joined #did 15:08:39 present+ 15:08:40 Wip: Then we will use the infra from the CCG meaning the Google Meet and Transcription 15:08:45 ack Manu 15:09:01 manu: the only thing I need to do is to create a meeting in the CCG infra account for this 15:09:17 ... Then include the chairs as people that can convene that meeting, and configure the minutes generation to trigger 15:09:33 ... Then it will be setup automatically and will run automatically as well as sending the minutes out to the ccg 15:09:34 q+ 15:09:39 ack Wip 15:10:14 Wip: Sounds good. Please just provide me with the link and the details so that I can update our regular agenda.... 15:10:29 Manu: Yes will do that... 15:10:33 manu: To send the minutes out to the DID Wg, it might be a bit more tricky to post to the mailing list 15:10:35 q+ 15:10:41 ... it is possible, but a bit more work 15:10:59 TallTed has joined #did 15:11:01 q+ to suggest we can just manually reference it in the meeting for the special topic call 15:11:09 ack pchampin 15:11:09 manu: This is possible 15:11:35 pchampin: The infra is currently sending emails to the CG mailing list. Dont see why this would be different for the working group mailing list 15:11:51 manu: Yea but you can't post unless you are a member to catch spam etc 15:12:11 pchampin: I may need to allow the first email to go through. This is possible 15:12:25 ack Wip 15:12:25 Wip, you wanted to suggest we can just manually reference it in the meeting for the special topic call 15:13:13 manu: Anyone can also forward it. Not concerned about it 15:13:22 Topic: Horizontal Review Update 15:13:47 manu: There is no update on the horizontal review from my side 15:13:53 ... this is typical 15:13:57 q+ 15:14:02 ack Wip 15:14:05 present+ 15:14:41 q+ 15:14:44 Wip: Yes we have this on the Agenda just as a reminder... I am bit unclear as to how the break down of the work is. Perhaps Markus can clarify the scope of the work 15:14:48 ack Manu 15:14:50 markus_sabadello: I dont remember can someone remind 15:15:08 manu: Last time we discussed this, the TAG had changed the process meaning we dont require an explainer anymore 15:15:28 ... Instead we can request a horizontal review from the TAG and point to the parts of the spec that answers these questions 15:15:39 ... if we dont have those sections yet in the spec, then we need to write them 15:15:41 q+ 15:15:52 ... That would be it. It should be a lighter lift 15:15:58 I have made the request to generate https://www.w3.org/2025/08/07-did-minutes.html TallTed 15:16:24 ... Someone needs to look at the list and map it to the section and raise new issues against the spec where they are missing 15:16:41 previous meeting: https://www.w3.org/2025/08/06-did-minutes.html 15:16:43 next meeting: https://www.w3.org/2025/08/14-did-minutes.html 15:16:50 ack Wip 15:17:05 s/presnt+// 15:17:13 q+ 15:17:30 q- 15:17:35 q+ 15:17:42 Wip: Yes I will create an issue after this call with the work that Manu just described that needs to be done. Also the other item is the Privacy review.... 15:17:45 ack Manu 15:17:54 present+ pchampin 15:18:02 manu: Yep, that is exactly right. Someone needs to go through the questionaire and try to answer the questions 15:18:11 I have made the request to generate https://www.w3.org/2025/08/07-did-minutes.html TallTed 15:18:17 ... The privacy questionaire should be completable without issue 15:18:26 ... You typically want to start with the TAG review 15:18:40 ... Other reviews ask about the TAG answers 15:18:41 q+ 15:19:09 ack markus_sabadello 15:19:46 markus_sabadello: we should create two issues one for the TAG and one for the PING review, then we can link the the relevant questionairre 15:19:48 q+ 15:19:52 q+ 15:20:46 ottomorac: I thought we already had an issue for this open 15:20:52 q+ to ask about security review changes 15:20:53 Wip: No this is for accessibility and internationalization 15:21:00 ack Manu 15:21:14 Suggestion is to follow this general issue template for the horizontal reviews: https://github.com/w3c/did/issues/885 15:21:16 manu: We have three issues, one horizontal review and two specific self reviews 15:21:37 ... markus_sabadello for the links I am linking to DID core issue #885, this shows you how the answers look like 15:21:50 ... We just need people to actively work on these to move them forward 15:21:51 q- 15:21:58 ack JoeAndrieu 15:21:58 JoeAndrieu, you wanted to ask about security review changes 15:22:16 JoeAndrieu: I just wanted to raise that the security review may be asking for something different than what we have prepared in the past 15:22:40 ... Simone's goal is to establish threat modelling as the way we write up security review 15:22:50 ... I don't think this is ready yet, but it might be coming down the pipe 15:23:08 Topic: Is percent encoding the fragment (#) really conformant with the URI RFC? #898 15:23:10 ottomorac: moving on 15:23:12 https://github.com/w3c/did/issues/898 15:23:27 This is related to example 6 in the DID core spec, link: https://www.w3.org/TR/did-1.1/#example-a-resource-external-to-a-did-document Which is using percent encoding for “%23” instead of the number sign.The poster questions whether this example is inconsistent with the RFC3986 for URIs. 15:23:27 There is discussion by Markus and Dave Longley about the steps that could be taken to de-reference the example that is provided in the spec and how to handle percent encoded fragments. 15:23:49 q+ 15:24:15 ack markus_sabadello 15:24:26 markus_sabadello: I think from a URI syntax perspective, both are valid 15:24:38 ... A fragment in the URI is okay, and so is an encoded fragement 15:25:01 ... in this specific case, this is about example 6 in the specification. In the section about the DID fragment. This is a URI fragment, not encoded 15:25:09 RSS, make minutes 15:25:16 q+ 15:25:21 ... I think a change needs to be made here in example 6. To have a fragment not an encoded fragment 15:25:36 ... This has changed, from 1.0 to 1.1. I think this was a mistake, we should change it b ack 15:25:37 s/RSS, make minutes/ 15:25:40 ack manu 15:25:41 RRSAgent, make minutes 15:25:42 I have made the request to generate https://www.w3.org/2025/08/07-did-minutes.html pchampin 15:25:53 manu: looking at the example now ... 15:26:09 I did read the thread, markus_sabadello is right. There are two different interpretations of the URL 15:26:16 ... I am a bit concerned about moving it back 15:26:27 Here's the direct link: https://www.w3.org/TR/did/upcoming/#example-a-resource-external-to-a-did-document 15:26:27 ... In example 6, I will paste in 15:26:38 specific text we're talking about: did:example:123?service=agent&relativeRef=/credentials%23degree 15:26:55 Previously it was: did:example:123?service=agent&relativeRef=/credentials#degree 15:27:06 q+ 15:27:17 s|with the URI RFC? #898|with the URI RFC? https://github.com/w3c/did/issues/898 15:27:21 ... This is not clear to me if the fragment identifier in this example is meant to talk as a fragment in the final document. As this is relativeRef 15:27:44 ... Example 6, the fragment identifier is pointing to something other than a DID document. As a result, I think it does need to be percent encoded 15:27:51 ... However, I see that this is confusing in this section 15:28:04 ... We need to figure out what this means from a did resolution section 15:28:10 ... I dont want to put this back 15:28:19 @manu can you put the two options in chat? I don't know what you mean when you say "put it back" 15:28:26 ... If we put this back, then it is a pointer to the DID document 15:29:03 manu: If you put a fragment identifier on that DID URL in exampl6. then that fragment is pointing to the DID document 15:29:14 ... One problem is there are two interpretations of this example 15:29:23 ... It is not clear about what should happen in this case 15:29:36 ... It depends on how you are going to process this thing 15:29:48 q+ to say I think it is actually clear. not percent encoded means it is NOT part of the relative ref property 15:29:49 ack markus_sabadello 15:29:53 ... Different impls will do different things 15:30:05 markus_sabadello: What makes this complex is exactly the use of the relativeRef here 15:30:15 ... Dave and I made comments to this effect 15:30:41 ... If it is percent encoded, then the fragment is part of the relative ref value. If it is not precent encoded, then it is part of the DID document 15:30:57 ... Both variations might even dereference to the same thing 15:31:09 ... However, the dereferencing algorithm is different 15:31:34 q+ 15:31:46 ... First we dereference the DID Url with the service and relativeRef parameter. Then we dereference the fragment on the result 15:32:21 ack JoeAndrieu 15:32:21 JoeAndrieu, you wanted to say I think it is actually clear. not percent encoded means it is NOT part of the relative ref property 15:32:26 ... If we percent encode, then it is part of the relativeRef value. I still think this is the same result. But handled differently. The difference is that the percent encoded fragment is not a DID fragment 15:32:54 JoeAndrieu: I endorse markus_sabadello here. I think we need to move it. Because this section is about the DID fragment 15:33:07 ... There is an option to say you can do either. And one interpretation is that these are equivalent 15:33:20 ... The intention of this example is that that fragment is part of the relativeRef URL 15:33:56 q+ 15:33:56 ... Modelling this that the relativeRef property includes the DID fragment is what we should encourage 15:34:03 ack manu 15:34:15 ... This is the clear way that you specify that the fragment is into the doc that is relativeRef. Not the DID document 15:34:32 manu: plus one to what JoeAndrieu said. ANd agree with markus_sabadello. We need to move this out of this section 15:34:50 ... I think this is legitimate. I just don't know how other developers would interpret this 15:35:00 ... Concerned about misimplementations and corner cases here 15:35:09 ... Esp with regards to WHATWG 15:35:29 ... I think markus_sabadello interpretation is correct per RFC3986. But might not be in regards to the WHATWG 15:35:44 ... We would need to test against other systems to confirm what markus_sabadello has said 15:36:23 ... Agree with Joe's second point. If we allow both we will have to explain it in depth. And people will still get it wrong. 15:36:56 ... If you are going to do this relativeRef stuf, and include a fragement to the referenced resource. Then that frag should be encoded in the realtiveRef. 15:37:14 ... The only downside, is that the URLs that we would like to be nice URLs end up with some ugly syntax 15:37:24 ... +1 lets move it out of this section at a bare minumum 15:37:36 ... second, lets add a section that walks through all that we have just discussed 15:38:02 ... three, we might want a section that documents that these are semantically equivalent. But we would have to check with WHATWG to see if this is actually the case 15:38:06 ack markus_sabadello 15:38:25 markus_sabadello: If we say that the fragment has to be percent encodedf to be part of the relativeRef value 15:38:39 q+ to say I think they are allowed. just not recommended 15:38:44 ... It raises the question if real DID fragments are allowed on this relativeRef 15:38:58 ... In regards to what is deployed on the web today. I agree this is useful to check 15:39:52 ... In my mind, these things behave similar to http. E.g. 302 redirect. If you dereference a http url with a fragment and a server redirects you to another URL, then the original fragment is preserved 15:39:59 ... That is what I am trying to accomplish here 15:40:02 q+ to note "fragment semantics" 15:40:05 ... We can look at this close 15:40:12 s/close/closer 15:40:18 ack JoeAndrieu 15:40:18 JoeAndrieu, you wanted to say I think they are allowed. just not recommended 15:40:31 JoeAndrieu: I think I am aligned with markus_sabadello 15:40:50 ... I think we can't actually prevent people from saying this is a DID URL and I am going to put a fragment on it 15:41:01 ... This is going to parse, but it may not parse in all parssers 15:41:16 ... We want to encourage the use where this is clear 15:41:37 ... This can get confusing. It is about communicating this and providing an easy route 15:41:41 ack manu 15:41:41 manu, you wanted to note "fragment semantics" 15:41:57 manu: Adding more complexity to this... 15:41:57 Servers never see fragment IDs that follow unencoded `#`. Servers only see fragment IDs that follow `%23`. 15:42:12 ... every media type can define their own fragment semantics 15:42:18 https://datatracker.ietf.org/doc/html/rfc5147#section-1.3 15:42:29 ... e.g. this is the text plain fragment semantics 15:42:46 ... This is to say that application/did can define our own semantics for fragments 15:42:51 ... This can be a foot gun 15:43:08 ... people expect fragments to work like http urls 15:43:19 ... I agree we cant stop people from doing this 15:43:27 ... But we can nudge people 15:43:30 q+ 15:43:48 .. bigbluehat added a great example`did:example:123?service=agent&relativeRef=/credentials#degree#in-the-did` 15:44:00 ... The relativeRefher is what makes this complicated 15:44:09 s/relativeRefher/relativeRef/ 15:44:12 q+ 15:44:31 ... We probably need a section that talks specifically about fragment semantics 15:44:40 s/did:example:123?service=agent&relativeRef=/credentials#degree#in-the-did/did:example:123?service=agent&relativeRef=/credentials%23degree#in-the-did 15:44:58 ... Specifically highlighting the equivalence that markus_sabadello has mentioned 15:45:32 ... I think we can say semantically, the interpretation of a percent encoded fragment and a DID fragment point to the same thing 15:45:45 ack bigbluehat 15:45:47 bigbluehat 15:45:56 bigbluehat -- that s/ is going to fail because too many / in it 15:46:05 bigbluehat: in a URI you only get one hash symbol 15:47:30 ... To sum it up, percent encoding properly sets the value of relativeRef to the whole value 15:48:03 ... The URL parsing stuff is literally just breaking the string at the first hash value. Everything to the right goes in the search params 15:48:07 q+ to note that we're talking about DID URL fragments, not DID fragments... and for DID URL fragments, there are two passes on resolution, IIRC. 15:48:21 ... Such that if you stick a hash anywher, anything to the right is the fragment identifier 15:48:51 ... If you want the value of relativeRef= some value. You must percent encode that, otherwise you are not going to pass that into the response of the relativeRef 15:49:01 ... The parsing will assume it is part of the DID document otherwise 15:49:09 ... This is true in URLs too 15:49:12 ack TallTed 15:49:49 +1 to what Ted is saying 15:49:59 We should do progressive examples 15:50:02 TallTed: part of the difficulty is that too many pieces are made part of the URL string. Ideally we start with the simple case and add complexity one bit at a time 15:50:06 q+ to note we don't define relativeRef :) 15:50:27 ... This is complex. Most people dont understand this. Some percentEncode. Others dont. People make mistakes 15:50:39 ... Even experts get this wrong 15:51:22 ... We should not have this ultra complex example early in the doc 15:51:32 ... Two complex discussions at once. If not three 15:51:44 ... relativeRef, fragments and fragment encoding 15:52:02 ... Clients should never send anything beyond that first hash to the server 15:52:03 q+ 15:52:18 ... A server that receives a string with an unencoded hash, should chop it off 15:52:23 ... many impls get this wrong 15:52:43 ottomorac: To summarise, lets separate the examples out 15:52:45 ack manu 15:52:45 manu, you wanted to note that we're talking about DID URL fragments, not DID fragments... and for DID URL fragments, there are two passes on resolution, IIRC. and to note we don't 15:52:48 ... define relativeRef :) 15:53:02 q+ 15:53:09 manu: again, reading the spec. We dont define relativeRef at all. We just assume this is defined elsewhere 15:53:23 ... Unless we define what relative ref is an how it works 15:53:23 q+ 15:53:41 ... Maybe this example and the discussion of it needs to move to did resolution 15:54:02 manu: what you were talking to bigbluehat presumes a single pass over the URL. Wheras I think this might be a two pass process 15:54:10 q+ to say relativeref *was* described in the spec, but if I recall correctly, it was at risk and was removed due to lack of implementations 15:54:16 ... First pass will parse the URL and pull stuff out. Then it will construct a new URL using relativeRef 15:54:24 ... I think that is what markus_sabadello was speaking to 15:55:36 ...There are many interpretations, and its complex. WOndering where this belongs. Dont want to confuse people more than we need to 15:55:56 q+ to agree relativeRef should be defined somewhere (extension) before we use it in an example 15:56:01 ack bigbluehat 15:56:18 zakim close queue 15:56:21 bigbluehat: I propose some action steps. DID core defines relativeRef pretty well. It says you should percent encode 15:56:30 ... I think example 6 needs to be changed. 15:56:47 zakim, close the queue 15:56:47 ok, ottomorac, the speaker queue is closed 15:56:49 q+ to disagree that relativeRef is defined in the spec -- relative DID URLs are defined. 15:57:16 q? 15:57:29 ... The value of relativeRef is refernced as coming from 3986 15:57:35 https://www.w3.org/TR/did-1.0/#did-parameters 15:57:45 ... I would add a different example. We need some different examples 15:58:08 ack markus_sabadello 15:58:11 q- 15:58:12 ... The difference here is that we don't have a server exchange happening here. There are two steps going on, not sure if we are distringuising clearly 15:58:32 markus_sabadello: manu is correct that we dont define how to process relativeRef much 15:58:33 relativeRef A relative URI reference according to RFC3986 Section 4.2 that identifies a resource at a service endpoint, which is selected from a DID document by using the service parameter. If present, the associated value MUST be an ASCII string and MUST use percent-encoding for certain characters as specified in RFC3986 Section 2.1. 15:58:49 ... In did resolution there are algorithms for how to handle relativeRef and other parts of the DID URL 15:59:01 ... Based on language in the specs, I still think both versions are valid 15:59:06 yes, relativeRef is defined in DID Resolution -- not DID Core -- we need to solve this in DID Resolution: https://w3c.github.io/did-resolution/#did-parameters 15:59:17 ... Thats what I think the algs in DID resolution reflect right now 15:59:24 ... This might be mistaken. Please review them 15:59:29 q? 15:59:38 ack JoeAndrieu 15:59:38 JoeAndrieu, you wanted to agree relativeRef should be defined somewhere (extension) before we use it in an example 15:59:41 brent has joined #did 16:00:01 JoeAndrieu: We do define a parameter definition of relativeRef in DID core 16:00:12 manu: Not in 1.1 that got moved to DID resolution 16:00:35 ottomorac: thanks all 16:01:16 scribe- 16:01:19 present+ 16:01:24 rrsagent, make minutes 16:01:25 I have made the request to generate https://www.w3.org/2025/08/07-did-minutes.html ottomorac 16:02:06 m2gbot, link issues with transcript 16:02:07 comment created: https://github.com/w3c/did-resolution/issues/92#issuecomment-3164836193 16:02:08 comment created: https://github.com/w3c/did/issues/898#issuecomment-3164836234 16:02:24 zakim, end the meeting 16:02:24 As of this point the attendees have been Wip, KevinDean, markus_sabadello, manu, ottomorac, JoeAndrieu, JennieM, TallTed, pchampin 16:02:26 RRSAgent, please draft minutes 16:02:27 I have made the request to generate https://www.w3.org/2025/08/07-did-minutes.html Zakim 16:02:41 I am happy to have been of service, ottomorac; please remember to excuse RRSAgent. Goodbye 16:02:41 Zakim has left #did 16:02:43 RRSAgent, please excuse us 16:02:43 I see no action items