[2020-02-13T21:13:20.758Z] present+ [2020-02-13T21:13:20.758Z] Scribe: kdenhartog [2020-02-13T21:13:20.758Z] Agenda: https://docs.google.com/document/d/1qYBaXQMUoB86Alquu7WBtWOxsS8SMhp1fioYKEGCabE/ [2020-02-13T21:14:37.058Z] present+ [2020-02-13T21:15:00.670Z] present+ [2020-02-13T21:16:46.537Z] markus_sabadello: There's a close overlap between did-core and did resolution [2020-02-13T21:18:16.907Z] ... trying to figure out how the overlap can be done and this was discussed at the did WG F2F meeting [2020-02-13T21:18:58.402Z] ... the main conclusion from that discussion was that the did-core spec should talk more about resolution and should include did resolution as a topic to some extent [2020-02-13T21:19:33.101Z] ... It [did-core spec] should include the contract of did resolution [2020-02-13T21:20:23.262Z] ... DID resolution would continue to exist, but would be more about the resolution implementation details where dereferencing process would fall in line with did resolution spec [2020-02-13T21:21:29.333Z] Justin: There's a few places where this contract interface would be used. One is did and did urls. The second is dids and derefencing in did documents [2020-02-13T21:22:25.387Z] ... There's a lot of defined decisions in implementations today, but the spec would define these things so new implementations could also be defined [2020-02-13T21:23:07.229Z] ... this is in line with how did methods can specify the CRUD operations, but don't specify how that should be done. A similar pattern will be followed with did resolution [2020-02-13T21:23:11.098Z] present+ [2020-02-13T21:24:54.253Z] tplooker: Dereferencing is more of a client side functionality and having resolvers calling other resolvers could start to break these contracts [2020-02-13T21:25:07.095Z] markus_sabadello: these topics are related to the first contract [2020-02-13T21:26:04.409Z] ... I don't think it's accurate to say dereferencing is always a local operation [2020-02-13T21:27:02.077Z] tplooker: Yeah you're probably right. I don't think I was being clear in what I meant by dereferencing. [2020-02-13T21:27:54.739Z] markus_sabadello: we need to work on this disctinction more in the did resolution spec. We have some discussion about this in the spec regarding dereferencing the primary resource vs dereferencing the secondary resource [2020-02-13T21:28:42.488Z] ... this probably still requires more work because we don't discuss a did dereferencer yet [2020-02-13T21:29:36.276Z] tplooker: what happens when a resolver is passed a did-url? would I be returned something other than a did document [2020-02-13T21:29:53.019Z] present_ [2020-02-13T21:29:59.682Z] present+ [2020-02-13T21:30:01.914Z] Justin: that's the exact thing that the contract needs to further define [2020-02-13T21:30:36.772Z] present+ [2020-02-13T21:31:21.356Z] dmitriz: in regards to the did:web method, can there be more than one did:web per domain? The reason I bring this up is because if two did:urls have separate paths do they count as the same resource? [2020-02-13T21:32:17.259Z] markus_sabadello: Ivan would probably have some strong opinions about this. He's been wanting us to be more specific about some of these things and we can't override basic web architecture. [2020-02-13T21:32:36.696Z] ... my answer would be if you have different urls then you have different identifiers [2020-02-13T21:33:18.961Z] ... I believe there's nothing in web architecture that have multiple identifiers reference the same resource [2020-02-13T21:34:00.579Z] ... I dont think that would be defined by these specifications, but this could be specified by method specs with matrix params [2020-02-13T21:38:37.803Z] kdenhartog: this relates to the thinking I had around reference chaining in did documents [2020-02-13T21:38:54.251Z] dmitriz: yeah that's a property of json-ld so it should be possible [2020-02-13T21:39:16.575Z] kdenhartog: I wasn't sure if that holds true with JSON syntaxes though [2020-02-13T21:46:21.149Z] continued discussion between markus_sabadello dmitriz and tplooker regarding derefencing (scribe missed some of it) [2020-02-13T21:46:58.897Z] tplooker: I think it depends on what level of autonomy we leave to the did methods and implementors [2020-02-13T21:48:14.179Z] markus_sabadello: is the authority the did or the entire url [2020-02-13T21:48:32.108Z] dmitriz: I think that's correct [2020-02-13T21:48:47.067Z] markus_sabadello: I think that's invalid regarding language around did-core spec [2020-02-13T21:49:35.560Z] dmitriz: can the id be the full did-url? [2020-02-13T21:50:44.455Z] johnnycrunch: Joe would likely argue that it's not self sovereign [2020-02-13T21:50:56.172Z] dmitriz: the keys could be used [2020-02-13T21:51:15.000Z] johnnycrunch: then this gets into what sam has been talking about self certifying identifier [2020-02-13T21:51:39.746Z] dmitriz: controlling path states who controls keys [2020-02-13T21:52:36.987Z] only control of that resource is needed [2020-02-13T21:53:31.266Z] johnnycrunch: then you have the problem of the dns admin to remove control from controller of the resource [2020-02-13T21:54:09.615Z] dmitriz: not necessarily, the admin can delete access to the resource, but not take control of the identifier because they don't have the private key [2020-02-13T21:55:28.431Z] ... using hashlinks can help prevent dns spoofing [2020-02-13T21:56:00.762Z] leonardr: hashlinks is an expired spec [2020-02-13T21:56:12.073Z] dmitriz: so is did:web at this point [2020-02-13T21:56:43.741Z] Justin: I'm not saying they're not mature and being developed. I'm saying their not IETF spec just because they can be found in the datatracker [2020-02-13T21:57:25.143Z] so just for completeness/for the record, the current Hashlink spec is /not/ expired - https://tools.ietf.org/html/draft-sporny-hashlink-04 [2020-02-13T21:57:38.513Z] but like Justin points out, is not an official working group item. (just like did:web or the DID Resolution spec) [2020-02-13T21:57:49.981Z] Justin: once it's moved into a WG it's considered an IETF document [2020-02-13T21:59:34.869Z] dmitriz: we don't specify the semantics of paths outside methods [2020-02-13T21:59:53.997Z] dmitriz: I suspect that will change depending on the matrix params [2020-02-13T22:00:14.869Z] markus_sabadello: that's a possibility, but not my preference [2020-02-13T22:00:39.149Z] dmitriz: as far as did:web method, if the subject can't be a full url, then that's fine [2020-02-13T22:01:01.871Z] dmitriz: I'd propose that we encode the authority path into the query param [2020-02-13T22:01:14.620Z] dmitriz: I am curious about how the group rules [2020-02-13T22:01:29.311Z] markus_sabadello: I want to get back to the original question about the contract [2020-02-13T22:01:49.603Z] ... and what was discussed at the F2F meeting [2020-02-13T22:01:50.140Z] er, sorry, correction: I propose that we encode the path part of the did:web URL into the authority (ie, percent-encode it) [2020-02-13T22:02:44.263Z] markus_sabadello: there's now a PR regarding the contract in the did-core spec [2020-02-13T22:03:06.965Z] markus_sabadello: we'll want to see what we want to pull over from the did resolution spec or if we want to rewrite the contract [2020-02-13T22:04:05.808Z] ... I suspect that some of the aspects of the did resolution spec could be pulled over [2020-02-13T22:04:15.697Z] ... this is something that we should try to figure out in the next few weeks [2020-02-13T22:04:32.835Z] ... Justin if your sense is that we can reuse some of the did resolution spec would that make sense? [2020-02-13T22:04:59.763Z] Justin: I really don't know. Some can move over, but it's going to be an excercise to figure out where lines be drawn between the two [2020-02-13T22:05:25.581Z] markus_sabadello: I wanted to make sure everyone was aware and that more resolution content will end up in the did-core spec [2020-02-13T22:06:42.661Z] johnnycrunch: I don't see any discussion regarding mime-type in did-core spec [2020-02-13T22:07:09.248Z] markus_sabadello: the core representations will be defining the mime-types [2020-02-13T22:07:45.625Z] dmitriz: what was the consensus on the mime-type discussion for json-ld? [2020-02-13T22:08:18.299Z] markus_sabadello: there's a thread still going on it. I think latest thinking is application/did+ld+json [2020-02-13T22:09:17.767Z] ... this isn't a final decision though [2020-02-13T22:09:43.100Z] ... another discusiong was to use something like a profile => application/ld+json;profile=...