07:18:36 RRSAgent has joined #did 07:18:36 logging to https://www.w3.org/2020/03/31-did-irc 07:18:38 RRSAgent, make logs Public 07:18:39 please title this meeting ("meeting: ..."), ivan 07:18:41 Meeting: DID Working Group Telco 07:18:41 Chair: burn 07:18:41 Date: 2020-03-31 07:18:41 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2020Mar/0024.html 07:18:41 ivan has changed the topic to: Meeting Agenda 2020-03-31: https://lists.w3.org/Archives/Public/public-did-wg/2020Mar/0024.html 07:47:44 burn has joined #did 07:54:21 present+ 07:58:50 present+ 08:00:05 https://lists.w3.org/Archives/Member/member-did-wg/2020Mar/0004.html 08:00:37 brent has joined #did 08:00:55 present+ 08:01:40 present+ 08:01:41 present+ 08:02:35 present+ 08:03:36 kdenhartog has joined #did 08:03:40 present+ 08:05:25 markus_sabadello has joined #did 08:05:38 present+ 08:05:39 tplooker has joined #did 08:05:43 Topic: Agenda Review, Introductions, Re-introductions 08:05:43 scribe+ 08:05:46 present+ 08:06:11 burn: the agenda for today is talk about next topic call 08:06:22 ... had points about Formal objects but will leave for next call 08:06:37 ...review issue 218 and majority of time is on status of registries 08:06:49 ...finish up with normal status up on core issues 08:06:55 ...any requests for changes to agenda 08:07:02 Topic: Next Topic Call 08:07:29 ...reintroductions unnecessary because all parties know each other 08:07:36 ...next topic call will be in 14 hours 08:07:53 ...6pm eastern time 08:08:03 ... using current zoom link 08:08:22 ... we'll continue using this until we see other reason not to 08:08:29 phila has joined #did 08:08:32 ivan: this is officially the DID lounge 08:08:33 present+ 08:09:18 Topic: straw poll - issue 218 08:09:44 https://github.com/w3c/did-core/issues/218 08:09:47 burn: we have reduced attendance, but will be interesting to see results 08:10:29 ... manu could you describe the options of this issue to make sure no recent consensus is missed 08:10:43 manu: there's 3 options please jump in and correct if I'm wrong 08:11:14 ... we're trying to decide what we call terminology (e.g. did-url did-locator did-uri etc) 08:11:31 ... we need to call the thing where we tack on parameters something other than the uri 08:11:33 q+ 08:12:32 ivan: I raised the issue because while what we have in the document is correct the harsh reality is the term url has adopted more colloquial usage 08:12:53 ... the term did-url may become a source of confusion because of this 08:13:00 q+ to note that WHATWG have co-opted "URL" not "DID URL" :) 08:13:09 ... if we want to take seriously that dids could be used in the web I could see confusion coming up 08:13:25 ... we may want to think of renaming this to avoid this issue 08:13:32 q+ 08:13:37 q+ 08:13:41 ack ivan 08:13:45 ... on the issue I proposed a strawpoll it's not a matter of formal objection 08:13:45 ack manu 08:13:45 manu, you wanted to note that WHATWG have co-opted "URL" not "DID URL" :) 08:13:52 q+ 08:14:00 manu: +1 to strawpoll to make a decision 08:14:10 ... I looked at the WHAT-WG definition of a URL 08:14:28 ... the one main advantage we may have is that we clarify URL by prefixing with "did" 08:14:34 +1 to manu 08:14:58 ... this assists with creating the distinction and is the reason that I don't think we're necessarily in trouble with the WHAT-WG definition of the URL 08:15:29 ... I looked into if we could fit into the WHAT-WG definition as well 08:15:35 ack tplooker 08:15:49 jonathan_holt has joined #did 08:16:24 tplooker: my point was similar to manu... I think we need to decide if the prefix is going to assist with association then it's worth sticking with otherwise we should consider other names 08:16:33 ack burn 08:17:28 burn: The idea that WHAT-WG get's to define what a URL is a bit crazy. If you were in IETF they would reject that and I think we should not go there. 08:17:33 +1 to burn's point 08:17:42 ack markus_sabadello 08:18:42 q+ 08:18:48 markus_sabadello: Yeah I agree with what others have said. metions about authority components and how they affect uris and urls 08:19:14 ack phila 08:19:49 phila: I agree with a lot of people are saying. I've come to the view that did-url is the best we'll get. I wish it were otherwise but I accept the world as the way it is. 08:19:56 our DID URLs don't have a // double-slash, therefore the method-name and method-specific-id are parsed as the first segment of a path, rather than parsed as an "authority" component. (i'm not proposing to change that!) 08:20:02 ... if we are careful to always use did-url I think it's ok 08:20:10 Straw poll: DID URL or DID Locator 08:20:17 +1 to DID URL 08:20:18 +1 DID URL 08:20:20 DID URL 08:20:22 +1 DID URL 08:20:23 +1 to DID URL 08:20:23 +1 to DID URL 08:20:24 +1 to Locator 08:20:25 +1 to DID URL 08:20:27 +1 to DID URL 08:20:44 q+ 08:20:48 ack ivan 08:20:49 burn: strawpoll is fairly clear, but I will ask again on larger group call 08:21:24 ivan: combining the minutes and the comments I think we can decide to go with did-url 08:21:49 ... since I raised it I'm ok with closing the issue 08:22:03 burn: since you raised the issue, I think it's fine to close this 08:22:10 RESOLVED: close issue 218 08:22:15 ivan: and if someone objects then we can reopen the issue 08:22:27 Topic: Registry issue status check 08:22:35 phila: Would like to record that I stressed the importance of always saying 'DID URL' and never just URL 08:22:50 burn: meant to put "registries" not Registry 08:22:54 https://github.com/w3c/did-core-registries/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 08:23:34 https://github.com/w3c/did-core-registries/issues/3 08:23:42 q+ 08:23:51 ack manu 08:24:00 burn: orie is not here for this issue manu would you like to talk to this 08:24:09 manu: this is in process to fix JSON-LD links 08:24:24 ... orie has done a good job of getting these links fixed 08:24:49 ... the redirects from w3.org are not redirecting properly so that the test suite works properly 08:24:58 q+ 08:25:02 ... and these are under the control of the editors in the did-core registries 08:25:42 ack ivan 08:25:43 ... tried to add comment, but faced issues because I don't have my 2FA device 08:26:16 ivan: does this mean that v1 and v2 vocabularies are under our control from now on? 08:26:30 manu: it depends what you mean by "our" 08:26:40 q+ 08:26:45 ... we meaning between did-wg and ccg we now can update it 08:26:59 ... security stuff under ccg still, but did stuff under did-wg 08:27:44 ... DID-WG has control over the DID Context and the URL used in the DID Context are under the w3 urls 08:28:00 ... what actually matters are the actual values? 08:28:05 ack rhiaro 08:28:19 q+ rhiaro 08:28:44 ivan: on a practical level say the did work realizes there's one or two terms in the security file that must be added or changed because it's wrong 08:29:01 q+ to address Ivan's issue. 08:29:11 ... and in some way dependent on that, but that means we as a group cannot change that. It's up to the CCG? 08:29:13 manu: yes 08:29:15 ack manu 08:29:15 manu, you wanted to address Ivan's issue. 08:29:42 manu: to put a finer point on it the editors for the DID-WG are the same in the CCG security vocabulary 08:29:52 q+ 08:29:57 ... and both can make edits to both of them 08:30:03 q+ 08:30:06 present+ jonathan_holt 08:30:41 ... the likelihood that we end up with a situation where a bug occurs it's highly likely that we'd detect it 08:31:23 ... we do not have a normative dependency on the JSON-LD context that are in the CCG 08:31:50 ... because these registries are in flux, CCG is longer lived based on number so likely better place to keep it for now 08:32:07 q- 08:32:17 q- 08:32:19 ... and they're incented to keep those things up to date because they have other work items depending on it 08:32:23 I can take my question to the issue 08:32:25 ack jonathan_holt 08:32:26 burn: lets not discuss the issue if we can help it 08:32:54 jonathan_holt: the concern is with great power comes great responsibility. Who audits the security context? 08:33:03 burn: I'll allow that question 08:33:11 manu: the short answer is the W3C CCG 08:33:28 https://github.com/w3c/did-core-registries/issues/16 08:34:00 manu: still working through this one and in process 08:34:13 ... some things are checked and some not. Unsure how pedantic to be 08:34:30 https://github.com/w3c/did-core-registries/issues/7 08:34:32 ... "improving" on what other WGs have done 08:35:29 manu: I don't think there's been an update on this issue yet. We should leave it until Orie comes back 08:36:02 https://github.com/w3c/did-core-registries/issues/5 08:36:15 manu: this was assigned to jonathan_holt 08:36:28 ... we don't quite know how we'll do the equivilant at this point 08:37:14 ... one thing we can do because of the lossless guaruntee is to convert CBOR to JSON and run through JSON Schema, but now tooling has been built yet 08:37:33 jonathan_holt: I'm still working on it and that's in line with my plan 08:37:38 q? 08:37:57 https://github.com/w3c/did-core-registries/issues/17 08:38:22 manu: rhiaro made a proposal 08:38:40 rhiaro: theres a lot in this issue and my proposal doesn't cover it all, but overlaps quite a bit with it 08:39:01 ... I made a proposal about some of the namespaces in issue 28 08:39:35 manu: there's a tried and true pattern of how to do content negotiation at w3c 08:39:52 ... ivan and I are discussing what each file leads to 08:39:52 q+ 08:40:17 ... that conversation is ongoing and rhiaro is correct that we have another open question "What do we do with the registry?" 08:40:35 ... the machine and human readability is addressed by rhiaro proposal 08:40:53 ... what we don't have clarity on is how do we represent... 08:40:56 q? 08:41:23 ... we're probably going to want to publish urls from time to time and it's uncertain what the frequency of publishing will be 08:41:48 ... we could version with minor major with it bound to time (e.g. year and month) similar to ubuntu releases 08:42:10 ... if we feel that's too frequent then we could go just by year 08:42:33 ... if we use year we would start 2021 and it shouldn't be considered stable until the end of year 08:42:44 ... we need to pick something and go with it 08:42:52 burn: please include this details in the issue 08:42:57 ack ivan 08:44:04 q+ to speak to JSON Schema being "a foundation of jello" for JSON-only folks... but we can support it. 08:44:07 ivan: there's a slightly more general question: If everything is only JSON-LD then everything is fine and easy the problem is that the HTML5 is referred to for all, so if we have a redirection scheme then we should get something that's useful for all formats 08:44:16 ... that's where I'm not sure where we're heading 08:44:30 ... because JSON-LD is a bit unstable currently 08:44:43 q- 08:45:03 burn: want to keep it to updates because I want to get through all possible during this call 08:45:10 https://github.com/w3c/did-core-registries/issues/23 08:45:14 ... status of this one is it's still under discussion 08:46:07 rhiaro: it's not explicit about if there should be a URI Dave and Orie have said yes. I'm happy to make a PR if all agree 08:46:15 https://github.com/w3c/did-core-registries/issues/22 08:46:17 burn: status next steps are PR 08:46:26 rhiaro: this one is still a bit under discussion 08:46:41 https://github.com/w3c/did-core-registries/issues/26 08:46:44 ... still discussing if terms can be used in did-core 08:46:49 ... still ongoing 08:47:05 rhiaro: the next action is on CCG and I opened an issue for this 08:47:22 burn: so this is just a tracking issue 08:47:33 rhiaro: yes this is just tracking until CCG takes action on their end 08:48:16 burn: we've sometime had issues with coordination because on the other end CCG doesn't take it anywhere. Looks like this probably is not a concern this time. 08:48:23 ... this should be fine for now 08:48:25 https://github.com/w3c/did-core-registries/issues/9 08:48:51 burn: looks like it's still under discussion 08:49:18 manu: yeah it's under discussion. We're trying to figureout what goes in the registry and what doesn't and how do we reference things that are outside? 08:49:30 ... seems like rhiaro may have proposed a way through this 08:49:45 +1 what burn says 08:49:55 burn: in my mind I think of them like IANA registries. It only points to references, not to include details 08:49:57 +1 to what burn just said, agreed. 08:50:10 q? 08:50:20 https://github.com/w3c/did-core-registries/issues/19 08:50:52 manu: we want to define some stuff that sidetree uses and Mike Jones says don't do that 08:51:09 ... I think this is a perfect example of what the registry is for 08:51:24 ... this is a test of how decentralized the registry is 08:52:03 ... if it's blocked because the did-wg doesn't want it's more centralized, but if the registry can ignore the wg decisions it's a bit damaging to the consensus we've formed 08:52:13 burn: this is going to come down to a maintainer process 08:52:32 manu: and in this case I'd expect the process to produce disagreement 08:52:52 ivan: what would help this? 08:53:06 burn: sometimes further discussion will help us to decide metalevel decisions 08:53:09 q+ 08:53:18 scribe+ rhiaro 08:53:19 ack kdenhartog 08:53:41 kdenhartog: slightly related, to highlight because I raised it in did-core - to what degree do we need to be specifying these things and to what degree does it fall into the maintaner process? 08:53:53 q+ to level of detail needed. 08:53:53 ... keys coming in compressed or uncompressed formats can cause interop issues 08:53:57 ack manu 08:53:57 manu, you wanted to level of detail needed. 08:54:04 q+ to address aka security issues 08:54:12 manu: the general answer is you have to specify it precisely enough to enable interoperability 08:54:21 ... that depends on exactly what you're defining 08:54:40 ... in your case publicKeyHex will be paired if using ld security stuff 08:54:54 ... unless you have publicKeyHex and publicKeyHexCompressed 08:55:24 kdenhartog: that makes sense, i disagree a bit but let's take that offline 08:55:27 ack jonathan_holt 08:55:27 jonathan_holt, you wanted to address aka security issues 08:55:46 jonathan_holt: it will be trivial to introduce a vulnerability 08:55:55 manu: that's the nature of decentralized development 08:56:22 burn: I suspect that this issue will generate the metadiscussion that needs to be discussed specifically 08:56:31 ... and if this happens spawn the metadiscussion off 08:56:38 https://github.com/w3c/did-core-registries/issues/13 08:57:07 manu: almost completed. Last three items are questionable at this point 08:57:19 ... naming has gone off topic and rhiaro will cover it 08:57:22 ... discussion ongoing 08:57:27 https://github.com/w3c/did-core-registries/issues/28 08:57:47 rhiaro: this is my proposal on how to solve all the problems 08:57:59 ... discussion is ongoing and there's already some objections 08:58:07 ... would be nice to have some more people weigh in 08:58:21 q+ to helpers? 08:58:25 ack manu 08:58:25 manu, you wanted to helpers? 08:58:53 manu: we want to report out that we want to add rhiaro and kdenhartog to assist with triaging 08:59:28 ... both have been accepted but a note needs to be made that triaging is on behalf of group not on behalf of your org 08:59:46 ... if you see objections to label please seek assistance from editors chairs and the disagreeing parties 09:00:00 ... we have an action to document the labeling process 09:00:15 ... we don't know when we'll write that doc 09:00:31 kdenhartog: assignment goes to the author of the issue unless otherwise stated? 09:00:37 q+ 09:00:43 manu: yes 09:00:44 ack ivan 09:00:55 ivan, yes 09:01:47 zakim, end meeting 09:01:47 As of this point the attendees have been burn, rhiaro, brent, yancy, ivan, manu, kdenhartog, markus_sabadello, tplooker, phila, jonathan_holt 09:01:49 RRSAgent, please draft minutes 09:01:49 I have made the request to generate https://www.w3.org/2020/03/31-did-minutes.html Zakim 09:01:52 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 09:01:56 Zakim has left #did 09:09:24 rrsagent, bye 09:09:24 I see no action items 22:00:28 RRSAgent has joined #did 22:00:28 logging to https://www.w3.org/2020/03/31-did-irc 22:00:47 Zakim has joined #did 22:00:59 burn has changed the topic to: Topic call 22:07:09 brent has joined #did 22:07:09 present+ 22:07:18 present+ 22:07:21 Meeting: DID WG Special call 22:07:27 rrsagent, make logs public 22:07:30 rrsagent, draft minutes 22:07:30 I have made the request to generate https://www.w3.org/2020/03/31-did-minutes.html manu 22:07:33 present+ 22:07:35 drummond has joined #did 22:07:35 present+ 22:07:36 present+ 22:07:39 present+ 22:07:42 scribe: manu 22:07:55 dbuc has joined #did 22:07:59 burn: Why don't you start us off Markus. 22:08:34 markus_sabadello: I can give a summary of where we are right now. On the last call we talked about whether or not we wanted DID Parameters. 22:09:20 markus_sabadello: We talked about DID Parameters in general, parameters that influence DID Resolution process, part of the identifier itself, service endpoint selection, versioning, whether we need them or not... there is broad support for some kind of mechanism to pass parameters as part of the DID URL, part of the identifier. 22:09:27 markus_sabadello: We also have resolver options, separate from that. 22:10:11 markus_sabadello: I think people want parameters as part of the DID URL. Right now the spec has the concept of matrix parameters, in ABNF. There is the thing between DID and the path, use key value pairs for service selection... there is a proposal to remove those. 22:10:15 q? 22:10:27 markus_sabadello: The argument is: we already have query params, why do we need matrix params? Why do we need both? 22:10:52 markus_sabadello: The application that I've tried to document or explain during the face to face meeting, and after that, was around service selection service endpoint URLs, motivated by PURLs. 22:11:20 markus_sabadello: PURLs are persistent URLs, they can point to different other URLs over time, stable identifier but over time references different resources. 22:11:53 markus_sabadello: That's really why the CCG came up with matrix parameters, in order to use that, you want to be able to select the service from the DID Document w/o using path, query, and fragment, because you want to pass those to service endpoint being selected. 22:12:30 markus_sabadello: There are path, query, fragment that are user controlled, very much like how PURLs work in HTTP universe. 22:13:01 markus_sabadello: Did some historical digging and found some resources that talk about this - blog post by Phil Windley, stuff created by RWoT, email from dlongley... 22:13:52 Markus reads from an email from dlongley --- on need for PURLs and how to do stuff in DID Documents. 22:14:10 https://lists.w3.org/Archives/Public/public-credentials/2019Jun/0028.html 22:14:10 markus_sabadello: So passing this through to service endpoint. 22:14:14 https://www.windley.com/archives/2019/02/decentralized_identifiers.shtml 22:14:17 https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/topics-and-advance-readings/did-resolution-collected-diagrams.md 22:14:28 (some historical links outlining the service endpoint selection functionality) 22:15:07 markus_sabadello: More recently, removing matrix params have become stronger, some are wondering if it's necessary. Dave Longley wrote a thorough and well informed analysis on how this could be done w/o matrix parameters. 22:15:45 markus_sabadello: the proposal is to have special query parameters that achieve the same effect. You can have service parameter and path encoded as different query parameters. 22:16:05 https://github.com/w3c/did-core/issues/159#issuecomment-598286814 22:16:30 That was my understanding 22:16:49 markus_sabadello: The example in the slide deck talks about service, service_path, and version as DID Parameters controlled by DID Core spec. 22:16:52 so at the 'top-level' they are all assumed to be DID-tied params 22:16:55 markus_sabadello: ... and the registries. 22:17:00 vs prams for anything else 22:17:05 we probably want "service-path" to be more like "service-relative-ref" so people know they can include fragments, etc. 22:17:15 q+ 22:17:29 markus_sabadello: This is the proposal now, if matrix parameters are removed, this is how it would be 22:17:34 If we go the route of DID parameters being DID query params, then IMHO we definitely need a way for DID methods to define method-specific parameter (just as we have done for "matrix"-style parameters) 22:17:48 markus_sabadello: In my next comment, I try to argue why matrix params are preferable. 22:17:58 ack dbuc 22:18:36 dbuc: To make sure we're all on the same page, all the top level parameters in DID URI are DID-specific params... would general idea would be to drop them after resolution? Those parameters wouldn't appear in generated output? 22:18:41 I would call them "DID URL encoded parameters" 22:18:44 markus_sabadello: Yes, that's my understanding. 22:18:48 q+ 22:19:13 ack drummond 22:19:22 q+ to say 'Yes, there's no "pass through" unless the DID param defines that behavior, etc.' 22:20:07 drummond: I wanted to stress that from a spec standpoint, I think we just specify that query parameter strings for DIDs use this DID URL Parameter Encoding, so anything you wanted to pass on to a service or intermediary would be encoded this way, whatever the target of that parameter is, decodes it. 22:20:18 ack dlongley 22:20:18 dlongley, you wanted to say 'Yes, there's no "pass through" unless the DID param defines that behavior, etc.' 22:20:23 dbuc: Just want to make sure my base line assumptions are correct. 22:21:02 dlongley: Yes to dbuc, there is no pass through. We would define DID Parameters, which we would encode as query parameters, what those do would be in a spec somewhere, there wouldn't be passthrough in the way that there would be with matrix parameters. 22:21:03 q+ 22:21:07 Great, that is what I was assuming/hoping 22:21:07 ack markus_sabadello 22:21:44 markus_sabadello: I can summarize why I -- I know there is support for removing -- I think there are benefits to matrix params - it's shorter, easier to read. 22:22:16 q+ 22:22:18 markus_sabadello: two parameters vs. 3 parameters to express same thing.. if you want to pass query, fragment to a service, you don't have to encode... they map directly. 22:23:25 Can a URL parameter version be defined such that it combines those two different params into one? Such as: service=files|user123/pics/me/png?version=14.6#frag1 22:23:44 markus_sabadello: The second example, it transfers control of the URL components away from DID Controller to spec authors and registries. Like having HTTP spec maintainer registry of allowed paths and query strings in HTTP URLs, there is no central registry. The nice thing about matrix param approach is that the information space is left to DID Controller. In the query string case, we define operations on the DID and structure and the meaning is defined by 22:23:45 spec/WG and not left to the DID controller anymore. 22:23:51 ack dbuc 22:23:53 markus_sabadello: There is a bit of a Web Arch argument. 22:24:40 q+ 22:24:42 dbuc: Can we do something in the URL parameter that provides a domain specific language? 22:24:45 ack drummond 22:25:10 Question: why can't service and service-path be combine for URL param example --> service=files|user123/pics/me/png?version=14.6#frag1 22:25:25 q+ to say to daniel it's up to us to decide what to do -- we can have a microsyntax within the value like you suggested in IRC or we can do multiple params 22:25:44 drummond: I'm not sure if I totally understand the question -- I think the Dave Longley proposal for DID URL encoded parameters is that ... just as certain web services say URL encode to get through pipeline, we can say the same thing - you can put anything you want in there, you just need to URIEncode whatever that is. 22:26:05 so this would be valid then: service=files:user123/pics/me/png?version=14.6#frag1 22:26:20 and the colon would not be URL encoded 22:26:26 q+ 22:26:29 dlongley: The value can be whatever you want it to be provided that it's URIEncoded. 22:26:31 ack dlongley 22:26:31 dlongley, you wanted to say to daniel it's up to us to decide what to do -- we can have a microsyntax within the value like you suggested in IRC or we can do multiple params 22:26:34 because it isn't a url encoded char 22:26:35 right? 22:26:40 dlongley: You URIEncode some value, that's how it goes through. 22:26:52 q? 22:27:01 q+ 22:27:11 ack markus_sabadello 22:27:17 dlongley: There could be other delimiters in it, up to who is defining DID Parameter to say what the value is... we can do microsyntax, it's a matter of defining what that value should look like for the DID Parameter. 22:27:33 markus_sabadello: They both work 22:27:59 If we did that syntax and used a colon, I don't think the colon gets encoded, because it's a reserved char 22:28:01 I think 22:28:41 q+ 22:28:45 markus_sabadello: it's great that DID Controller still has control over parameters, but you don't have control over meaning of query parameters... that would be defined by spec, and that's where I'm a little hesitant... hand over that information space. Maybe we don't need actual path anymore... might not need path in DID URL, if we just URIEncode, not sure what a path would do. 22:28:53 "Reserved characters ; / ? : @ = & (does not include blank space)" 22:29:29 ack drummond 22:29:31 markus_sabadello: What if you have a path and query parameters... I'm worried that we'll haev complications if we have different levels of passing paths/query/fragment in DID URL. 22:30:38 drummond: If we go in direction of DID URL encoded params, important that we define parameter that can be extended by DID Methods or DID URL authors... clear way to do that, define syntax for doing that matrix params/semicolon params, it becomes part of encoding rules, we can provide full features of information space. 22:31:43 drummond: Second point, is path even valid, we have to say - is it useful? Can path be used to navigate DID Document itself. DID w/ only a fragment should identify something in DID Document. Seems to me that it would be clear that if you had a DID URL Encoded query, you should not have a non-URL encoded fragment. 22:31:46 q+ 22:31:48 ack dlongley 22:31:50 I think it should 22:32:01 https://tools.ietf.org/html/rfc3986#section-3 22:32:03 dlongley: We don't need any paths anymore in DID URL 22:32:31 dlongley: There is an example that says that example URIs and component parts ... you can see where some foo scheme is being used and URN scheme is being used. 22:33:09 q+ 22:33:23 dlongley: You can see that path follows scheme, before query fragment, URL parsers, including WHATWG parser, in the path space, it puts in URN. The method and colon delimited thing go into path, query and fragment follow... it's clean w/ existing parsers - path is colon delimited things that are DID method specific, 22:33:51 dlongley: we don't have any need for any path that uses slashes from that perspective... fits in cleanly w/ URNs and more traditional HTTPs are doing, and we have a purpose for all of those things. 22:33:52 dlongley: can you add an example really quickly to that doc? 22:34:00 ack dbuc 22:34:02 Very good point, Dave—that the official "path" with DID syntax is in fact the colon-delimited section after the scheme 22:34:50 ack markus_sabadello 22:35:01 dbuc: The service endpoints, same type of service endpoints, but three of them? Path and select using fragment? #frag1, #frag2, and #frag3... and I'd use one of them to select, is that a valid use case? 22:35:40 markus_sabadello: wrt. removing the path - also agree if we decide to go this way, query parameters, removing path would be right thing to do... that's what URNs are doing - uses query strings, doesn't use paths. 22:35:56 dlongley: I mean the doc that the example we see on the screen is in 22:36:06 q? 22:36:15 q+ 22:36:16 markus_sabadello: GS1 identifiers, also don't support paths. Personally, I think it would be sad if we gave that up. I've always liked the symmetry in HTTP URLs, domain plus path query frag... DIDs are path query frag 22:36:19 q+ to note simplifying. 22:36:19 ack drummond 22:36:40 Wasn't saying that 22:36:43 oh 22:36:53 but service entries would have IDs 22:36:59 You would encode the fragment within a parameter value (or perhaps you want to be using a different URL entirely) 22:37:02 so would the frag not be good for matching that? 22:37:15 you wouldn't use the top level frag for that. 22:37:17 drummond: wrt. Daniel's comment, if you need something more than service name, we decide how to select among multiple services, that would be more acceptable under this mechanism, have defined parameter names in this model. 22:37:19 ok 22:37:21 ack manu 22:37:21 manu, you wanted to note simplifying. 22:38:11 manu: One of the things resonating with him is that this could end out simplifying the overall DID syntax. 22:38:24 s/him/me/ 22:38:33 ...the delimiters for those components could be reserved 22:38:46 ...we could achieve two simplifications 22:38:58 ...one is eliminating semicolon syntax 22:39:03 ...the second is the path 22:39:08 q+ to channel ivan 22:39:12 ack burn 22:39:12