14:35:21 RRSAgent has joined #did 14:35:21 logging to https://www.w3.org/2020/08/18-did-irc 14:35:23 RRSAgent, make logs Public 14:35:25 please title this meeting ("meeting: ..."), ivan 14:35:42 Meeting: DID WG Telco 14:35:42 Chair: burn 14:35:42 Date: 2020-08-18 14:35:42 Agenda: https://www.w3.org/mid/000000000000b0c25505acd6f038@google.com 14:35:42 ivan has changed the topic to: Meeting Agenda 2020-08-18: https://www.w3.org/mid/000000000000b0c25505acd6f038@google.com 14:35:43 Regrets+ dezell 14:53:51 burn has joined #did 14:56:25 present+ 15:00:06 present+ 15:00:21 selfissued has joined #did 15:00:26 agropper has joined #did 15:01:14 chriswinc has joined #did 15:01:15 JamesQU has joined #did 15:01:18 present+ 15:01:21 present+ 15:01:22 present+ 15:01:29 drummond has joined #did 15:01:38 present+ 15:01:41 present+ 15:01:49 justin_r has joined #did 15:02:01 present+ justin 15:02:01 present+ 15:02:05 jonathan_holt has joined #did 15:02:10 present+ jonathan_holt 15:02:23 dlongley has joined #did 15:02:31 present+ dlongley 15:02:35 scribe+ rhiaro 15:02:36 present+ drummond 15:02:44 Topic: Agenda Review, Introductions, Re-introductions 15:02:57 burn: we have a variety of things on the agenda for today 15:03:03 present+ 15:03:07 ... we're going to talk about security and privacy, the DID explainer - both important parts of horizontal review 15:03:12 ... and a quick check on opinions about service endpoints 15:03:17 ... anything else that needs to be included? 15:03:28 ... Anyone joining us for the first time? 15:03:36 ... Someone who would like to reintroduce themselves? 15:03:54 ... Eg. if you have never reintroduced yourself you are a good candidte 15:04:06 scribe+ 15:04:25 burn: Finding someone to reintroduce themselves... Mike Jones, would you like to reintroduce yourself? 15:05:11 selfissued: Hi my name is Mike Jones with Microsoft, I've worked on JOSE, WebAuthn, FIDO2, and many other standards in the space, including DIDs. I like to keep things simple and ensure that standards stay simple and easy to build. 15:05:12 Topic: Next Topic Call 15:05:29 burn: Next topic call is on relational link types, scheduled for today. 15:05:34 dmitriz has joined #did 15:05:41 brent: Yes, this afternoon, 6pm ET 15:05:49 burn: Happening 7 hours from now. 15:05:56 Topic: TPAC FF2F 15:06:28 present+ identitywoman 15:07:00 burn: We had already confirmed that it'll be week of Oct 19th, so we're going to do 4 sequential days... 19th, 20th, 21st, and 22nd - alternating between 10am-1:30pm slot and noon to 3:30pm slot. 15:07:15 present+ 15:07:30 burn: We had two different time slots from before - one day one time slot, next day the next - we'll sent it out via email. 15:07:37 present+ 15:07:47 burn: Just to be aware, the AC meeting is on Oct 20th, one of those days - before our meeting that day. 15:07:51 q+ 15:07:51 q+ 15:07:56 ack man 15:07:59 ack manu 15:08:11 manu: we've had a request from another WG, WoT, to have a joint meeting at tpac 15:08:19 ... I forwarded this to brent and ivan 15:08:50 burn: Yes, saw the email... weird calling it TPAC and joint meeting times - groups are encouraged to schedule for themselves when they meet... we can separately arrange joint meeting at any time. Will look at that and provide a suggestion. 15:08:57 burn: This is time for our group to meet on our topics. 15:09:28 brent: That meeting may happen the week before at times that are mutally acceptable. 15:09:34 ack ivan 15:09:59 ivan: For those of you that subscribe to my calendar, once we have agreed, we will have them - regular meeting on 20th... will send that out. 15:10:26 burn: Days will correspond mon-thu, unless you're in NZ, then tue-fri. 15:10:35 kaliya: IIW is Oct 20th-22nd. 15:10:54 Yup, that's a problem. 15:11:08 burn: oh, good point. 15:11:28 ivan: gee willikers, that is a concern. 15:11:42 burn: We will look into that. 15:11:47 Topic: Security and Privacy questionnaire 15:11:53 JoeAndrieu has joined #did 15:11:55 Orie has joined #did 15:11:55 https://github.com/w3c/did-core/issues/291 15:12:01 present+ 15:12:22 identitywoman has joined #did 15:12:26 burn: Can anyone report out on security/privacy document? 15:12:42 jonathan_holt: We're waiting for feedback... we can't answer potential vulnerabilities until we get some feedback. 15:12:46 present+ pam 15:12:46 present+ 15:12:51 q? 15:12:53 jonathan_holt: It would be helpful to hear from you what your thoughts are. 15:13:00 I could, but I need a meeting password 15:13:41 https://docs.google.com/document/d/13qLCZcks3OAb2V7GHcrSs8s9drA5OaqEPYPI1knmodc/edit#heading=h.mc2736ve71dk 15:14:06 jonathan_holt: We had a discussion about service endpoints, that was a big gap in what's going to happen w/ service endpoints. 15:14:12 burn: RIght, it's an almost segue. 15:14:16 Topic: DID Explainer 15:14:29 https://github.com/w3c/did-wg/blob/master/did-explainer.md 15:14:42 burn: Brent and I worked on the explainer - a document that the W3C Technical Architecutre Group requests that groups write. 15:14:55 burn: This is not just for us, it's for everyone, but it's usually focused on the W3C TAG. 15:15:32 burn: We have written it with that in mind, available for anyone that would like to make comments on it. We are looking at a short review period, in next week, so we can send off to W3C TAG. 15:15:42 q+ 15:15:55 burn: We are very close to CR a few months away, which is good, but that's close in standards terms. 15:16:06 ack ivan 15:16:10 burn: We're looking for feedback, minor suggestions/feedback would be good, anything we've missed? 15:16:21 ivan: I put comments in issue that referred to this document. 15:16:25 burn: We will look there, thank you. 15:16:34 TOPIC: service endpoints - POV share 15:17:02 burn: Before we start this, what the Chairs and Editors want is to ask for points of view on whether they like service endpoints or they do not like that. 15:17:06 present+ 15:17:20 burn: We are not trying to argue/discuss what we should be doing - we want individual opinions. We only have 10 minutes. 15:17:26 1+ to provide a quick position. 15:17:29 q+ to provide a quick position. 15:17:38 s/1+ to provide a quick position.// 15:17:38 q+ 15:17:40 ack manu 15:17:40 -> comments on the explainer https://github.com/w3c/did-core/issues/94#issuecomment-674808861 15:17:40 manu, you wanted to provide a quick position. 15:17:41 q+ 15:17:54 manu: I would like to keep a restricted form of service endpoints in the spec 15:18:07 ... I believe we have not discussed the security implications, the scary security implications, and we should do that 15:18:11 ... keep it in, heavily restricted 15:18:14 ack drummond 15:18:17 question to manu: restricted how? 15:18:57 drummond: I agree with manu, I've read threads discussing this, feel like when people bring up security/privacy - we need service endpoints for public entities, advertise point at which their DID enabled endpoints for comms are available... if there is no other use case, that one is important from Evernym's standpoint. 15:18:57 ack dlongley 15:19:00 q+ 15:19:19 ack JoeAndrieu 15:19:20 dlongley: I think it's useful to have data model for service endpoints, don't think they need to be in DID Documents, even in Drummond's use case, makes sense to put them somewhere else. 15:19:22 q+ 15:19:33 q+ 15:19:50 ack Orie 15:19:53 JoeAndrieu: Echo of Dave's point - we can build directory services w/o going to DID Layer, we can't have DIDs w/o what we have in the spec - we need to be more responsible wrt. privacy/security and service endpoints. 15:20:32 ack jonathan_holt 15:20:35 Orie: Agree with Joe, data model with them needs to be in spec, guidance on whether they are present in VDR should be provided, depending on nature on VDR it may be acceptable to have them in DID Document, but we need more guidance on when you should do it and when you shouldn't. Need more guidance in spec on that. 15:20:51 jonathan_holt: What is a wallet, what is a DID Document, what is an Agent? I'm all about minimum viable Agentization. 15:21:09 q? 15:21:09 jonathan_holt: I see a lot of what we're trying to do could be done via VCs instead of DID Docs. 15:21:20 pam has joined #did 15:21:20 q+ 15:21:22 ack manu 15:21:33 present+ 15:21:36 manu: it'll naturally come about when we talk to the stuff Jonathan and Joe and Orie mentioned 15:21:48 ... it is how much should you put in a DID document on a specific type of verifiable data registry 15:21:59 ... there are options for you should never put anything on there except maybe a pseudonymous vc endpoint 15:22:15 ... the other end, like with did web, put whatever you want to cos there are no GDPR concerns if you're running it off your own domain 15:22:23 q+ 15:22:29 ... we're going to end up having a set of suggested restrictions based on the qualities of the verifiable data registry, the DID method effectively 15:22:38 ack pam 15:23:00 q+ 15:23:14 pam: I'm ok with things going either way, concerned about complexity of performance here - we need to examine how many hops we expect people to make, how many layers of indirection to follow. There are advantages to simplicity, I'd like to see us discuss it. 15:23:16 +1 15:23:19 q- 15:23:21 agropper has joined #did 15:23:34 q 15:24:09 agropper: The glossary project group met yesterday, ran a survey across service endpoint issue, we weren't ready to present for another 2 weeks. When ther eis discussion, the results were interesting. 15:24:20 agropper: Not time to go into them, wanted to ask chairs for time to respond. 15:24:52 burn: These are all good things to understand when scheduling the special topic call on this topic. 15:24:57 Topic: Core issue status check 15:25:02 burn: Now for everyone's favorite item... 15:25:10 https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc 15:25:16 burn: The fuller review. 15:25:39 burn: We are looking for status check on these. 15:25:41 https://github.com/w3c/did-core/issues/176 15:26:11 mike: I created a PR, Amy has approved, removes offending sentence, feel like we hsould merge it. 15:26:41 mike: I had about 4 other issues that I created, when I had my DID day - I looked through all of them, thi sis the only one I can resolve by myself... all the other ones need a special topic call. This one is easy, let's get it done. 15:26:56 https://github.com/w3c/did-core/issues/85 15:27:12 brent has joined #did 15:27:18 present+ 15:28:15 selfissued: We need to sort the metadata issue, that will address this one. 15:28:21 https://github.com/w3c/did-core/issues/163 15:28:22 present+ 15:28:43 burn: This is going to be addressed before CR. 15:28:45 selfissued: Agreed 15:28:48 drummond: Yep 15:29:07 https://github.com/w3c/did-core/issues/119 15:29:31 burn: Referred to this earlier, both PING survey and explainer - we need both of them for TAG review. 15:29:42 burn: We're getting close, can finish up other two, can do TAG review after that. 15:30:50 burn: The nightmare scenario for chairs -- the W3C TAG and other Horizontal Review folks hate having review right before CR. We had big issues that could change entire document and how to think about DIDs, those have largely been resolved, working through details... don't think structure of document will change that much, this one falls into that one... couldn't do it before now, had to do it before CR, we should get it in as soon as we can so they don't 15:30:50 feel pressed for time. 15:30:57 burn: Any questions about that? 15:31:02 *crickets* 15:31:09 https://github.com/w3c/did-core/issues/23 15:31:28 burn: keeeeey formats.... 15:31:54 dbuc has joined #did 15:31:59 present+ 15:32:16 Orie: These are really publi ckey bytes representations 15:32:30 Orie: additional examples that use them in DID Core spec, this one could just be closed. 15:33:06 manu: this one could be closed. I'm concerned we're gonna lose... we should open a new issue that's more specific about publicKeyPem 15:33:07 ... maybe 15:33:12 present+ 15:33:16 ... I'll put this in the issue 15:33:45 https://github.com/w3c/did-core/issues/171 15:33:46 burn: Ok, put something in the issue. 15:34:22 selfissued: I don't know where the spec is wrt. this. 15:34:25 q+ 15:34:31 ack manu 15:35:06 manu: the decision on the special topic call was that a lot of these key representations, especially naming, the group didnt' want to take a position on that so now there's another group dealing with the naming and will come back to the group with a suggestion on naming and key expression and that will be that 15:35:10 ... we're expecting 3 weeks of discussion 15:35:14 ... and that will close this 15:35:23 q+ to ask what group is discussing it? 15:36:27 ack jonathan_holt 15:36:27 jonathan_holt, you wanted to ask what group is discussing it? 15:36:58 manu: at the last special topic call people said they're not interested in the discussion, so it's orie, myself, tobias and dave longley, and what we come up with we'll put forward for broader agreement 15:37:01 ... they're ad hoc calls 15:37:07 ... there's a repo that the discussion is happening in.. 15:37:24 work in progress: https://github.com/OR13/best-linked-data-suites-2020 15:37:30 https://github.com/w3c/did-core/issues/170 15:37:42 ^ summary, is there is not agreement over types vs interfaces and naming conventions 15:37:55 sorry, my comment is for the link above 15:38:33 Orie: The resolution is the spec is for key types other than JWK, so those properties are for non-JWK representations. 15:38:49 selfissued: That's only a partial answer - what about for JWKs. 15:39:01 Orie: I think we need a special topic call on this - will explain more in issue. 15:39:36 burn: Good, was looking for that, let's get this in the issue before we schedule that call. 15:39:40 https://github.com/w3c/did-core/issues/199 15:40:31 brent: This is something we started resolving -- the appendicies that Drummond is working on, also related to representation and sameAs properties. 15:40:54 burn: Could you link to thoes items in issue? 15:41:02 drummond: We'll talk about link relations today in special topic call. 15:41:15 q? 15:41:15 burn: Make sure to mention that in the issue. 15:41:16 https://github.com/w3c/did-core/issues/318 15:41:31 burn: Assigned to Kyle... 15:41:42 https://github.com/w3c/did-core/issues/318#issuecomment-648469714 15:41:51 q+ 15:41:58 ack dlongley 15:42:31 dlongley: This issue is bikeshedding name that appears in spec itself, do we want to give this thing a different name - people need to register opinions, doesn't impact implementations. Really about understability in the spec. 15:42:43 burn: Can you add comment saying that call would be helpful. 15:42:48 q? 15:43:00 https://github.com/w3c/did-core/issues/151 15:43:33 burn: Looks like a lot of agreement, but no work. 15:44:14 https://github.com/w3c/did-core/issues/281 15:44:47 burn: I'll leave this to editors to decide on when to mark as pending close. 15:44:54 https://github.com/w3c/did-core/issues/8 15:45:16 q+ 15:45:32 ack Orie 15:45:36 selfissued: all part of the same ball of wax. 15:46:21 Orie: it's not all a part of the same ball of wax - for methods using other key representation, other registries, they specify which relationships to use, we don't need to specifically rely on RFC7518 anywhere in the DID spec. 15:46:26 burn: Can you put that in the issue. 15:46:38 burn: Please put careful explanation of where portion of group is coming from. 15:46:58 selfissued: Your answer confuses me, we have publicKeyJwk, we have algorithm identifiers in it, so people know what algorithms to use. 15:47:19 burn: Let's resume on issue, we may need another call. I'd like to see how Orie's point and Mike's point turn into a discussion or not. 15:47:22 the value of the `publicKeyJwk` property is a JWK -- so the JWA stuff will be in there. 15:47:46 manu: ... and that's up to the cryptosuite to link to JWK spec... not the DID spec's job. 15:47:51 q+ 15:48:09 ack manu 15:48:41 manu: the discussion we had in the special topic call about jose and about naming around linked data suites, effectively had the group saying it's somebody else's job 15:48:53 ... based on that,w e're having a discussion - orie, tobais, dave longely, myself - on naming and what those cryptosuite specs say 15:49:02 ... the group has decided that is outside of the scope of this group 15:49:05 ... that's what has changed 15:49:12 ... it is up to the cryptosuites to link to jwk, and we are doing that elsewhere 15:49:29 ... but the group has come to a position, a decision seems to have been made where the group says this is not in our purview, other peopl eneed to figure it out 15:49:39 ... I think it will result in what you want mike, the cryptosuites that use jwk will refer to the jose registry 15:49:44 ... but it won't appear in the DID core spec 15:49:52 ... it will appear in the linked data suites specs 15:49:56 selfissued: that's not a normative reference of tihs spec 15:50:11 q+ 15:50:12 ... one ofthe most important meta issues is we should not be depending on stuff in community groups for the interoperable portions of our data structures 15:50:17 ... if that's happening in a CG it's unstable 15:50:19 q- 15:50:22 selfissued... you should have not punted the namign discussion from this wg then ; p 15:50:33 ... I disagree with manu's characterisation of the situation 15:50:45 ... we've not resolved the issue in such a way that all of our data structures are in finished specs rather than moving targets 15:50:47 selfissued: I disagree with manu's characterization of the situation, we haven't resolved the isuation in a way that all of our data structures are in finished specifications. 15:50:51 burn: Clearly we need more discussion. 15:51:04 q+ 15:51:22 q- 15:51:29 burn: This one, I think there is a rationalizatoin of statements/decisions that have been made before we make a decision on this one. 15:51:57 https://github.com/w3c/did-core/issues/104 15:52:32 ivan: I18N review has been done, we passed, keeping it open until we get to CR. 15:52:32 Orie, I'm not aware that I punted a naming discussion. Which names are you referring to? 15:52:49 https://github.com/w3c/did-core/issues/36 15:53:21 drummond: Markus is making an update - a PR to finally close this, we left this open to make sure he makes that PR. I'll make a comment to that effect. 15:53:48 https://github.com/w3c/did-core/issues/294 15:54:22 burn: It looks like there is still conversation happening, but needs something to kick it forward. 15:54:37 But publicKeyJwk is within purview of our working group, and so we should fully define how to use it 15:55:33 dlongley: Last I looked, there seemed to be consensus that we wouldn't be making any changes. I think Kyle thinks we should put some text around this... 15:55:59 burn: normally, I'd like to close - but let's document - Kyle should propose closing or create new PR for his thing, let's get this documented. 15:56:20 burn: Issue 105, going to skip that one 15:56:24 https://github.com/w3c/did-core/issues/105 15:56:35 https://github.com/w3c/did-core/issues/260 15:56:54 drummond: This is the appendicies issue, 373 15:57:20 ivan: Can we close this as a duplicate? 15:57:28 burn: Is there something captured here that isn't in the other issue? 15:57:48 burn: This is a pretty short thread - I'm fine w/ that, if you'd like to pending close this one, you can suggest it as one of the Editor's 15:58:19 burn: Thanks everyone 15:58:47 rrsagent, draft minutes 15:58:47 I have made the request to generate https://www.w3.org/2020/08/18-did-minutes.html ivan 15:58:47 burn: Mike, looks like ther eis IRC discussion happening, you might want to have a discussion w/ Manu/Orie about this - would be good for you guys to come to an understanding and present that to the group -- thanks all, talk w/ you later today. 15:58:51 (in 6 hours) 15:58:52 zakim, end meeting 15:58:52 As of this point the attendees have been burn, rhiaro, selfissued, ivan, chriswinc, drummond, JamesQU, justin, manu, jonathan_holt, dlongley, identitywoman, agropper, dmitriz, 15:58:55 ... Orie, pam, JoeAndrieu, brent, justin_r, dbuc, wayne 15:58:55 RRSAgent, please draft minutes 15:58:55 I have made the request to generate https://www.w3.org/2020/08/18-did-minutes.html Zakim 15:58:57 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 15:59:01 Zakim has left #did 15:59:42 rrsagent, bye 15:59:42 I see no action items