15:03:10 RRSAgent has joined #did 15:03:10 logging to https://www.w3.org/2020/03/10-did-irc 15:03:11 present+ 15:03:12 present+ 15:03:13 Zakim has joined #did 15:03:22 present+ 15:03:46 present+ 15:04:12 present+ 15:04:35 agropper has joined #did 15:04:38 present+ 15:04:41 scribe+ 15:04:51 present+ JoeAndrieu selfissued dlongley joel Orie chriswinc Tom_S___USAA_ 15:04:52 present+ 15:05:00 drummond has joined #did 15:05:05 present- again 15:05:05 present+ 15:05:06 present+ 15:05:08 I would like to make a tiny announcement. 15:05:08 present- everyone 15:05:11 present- zakim 15:05:17 present- wasn't 15:05:23 present- here 15:05:30 present- hadleybeeman 15:05:31 jonathan_holt has joined #did 15:05:43 brent: We'll be giving an update on the DID resolution process, etc. and go through some issues. 15:05:56 brent has joined #did 15:06:10 present+ 15:06:22 present+ jonathan_holt running a bit late though 15:06:34 present+ 15:06:37 agropper: I'm Adrian Gropper, I'm CTO of a small non-profit called Patient Privacy Rights and I also try to lead a reference implementation of standards that sort of combine the OAuth and SSI specs. 15:06:51 agropper: I call it the Alice to Bob problem, I'm mostly on the use case side of what we do here. 15:07:15 q? 15:07:19 https://weboftrustinfo.discourse.group/t/a-dynamic-digital-passport-for-covid-19-pandemic-mitigation/213 15:07:21 agropper: I'm trying to see if there is a group interest in working on contact tracing and self-isolation economic harm reducing app around the coronavirus outbreak. 15:07:38 kimhd has joined #did 15:07:43 present+ 15:07:55 very interesting 15:07:55 agropper: I've got a link in the chat to a discourse entry in the Web of Trust Discourse, it's a short description, less than a page. Anybody that might be interested in participating please contact me directly or contribute to the discourse thread, thanks. 15:08:04 brent: Anyone on the call for the first time and would like to introduce themselves? 15:08:17 ken has joined #did 15:08:41 brent: There was a minor issue getting the doodle poll sent out, the correct one. So not a lot of responses have been made. The correct poll has been sent out and I would encourage everyone to please respond to it so we can schedule the meeting ASAP. 15:08:59 brent: Because of the lack of feedback so far I'm not comfortable in declaring a time for the next meeting. Let's extend the deadline for response to that poll to the end of this week. 15:09:08 brent: We'll schedule a meeting as soon as we have enough feedback. 15:09:21 brent: Please respond by the end of this week, the topic is to keep talking about the registries. 15:09:25 brent: Any questions on that? 15:09:26 q? 15:09:32 present+ 15:09:53 brent: Markus has volunteered to walk us through the current status of DID Resolution, so I will turn things over to him. 15:10:13 https://docs.google.com/presentation/d/1Ccnbh_A53yzTyIIrw6ol_EakAliuo3MfxIFlGsaoKos/ 15:10:13 brent: Can you post a link to the slides in IRC? 15:11:42 markus_sabadello: The first page shows two outlines, the current outline of the DID core spec on the left as it was restructured after the F2F. Part of that, those parts that are somehow related to DID Resolution and on the right side you see the current structure of the DID Resolution spec which isn't happening in this group but as a work item of the CCG. 15:11:43 https://w3c-ccg.github.io/did-resolution/ 15:12:36 markus_sabadello: The DID Resolution spec is not in scope for this group but there was consensus at the F2F that some pieces should be in scope for the DID core spec. Specifically, the contract (as Justin calls it) or the interface. When you have a DID/DID-URL what is the interface for what you can get, what makes resolution possible. 15:13:02 present+ Benjamin_Young 15:13:27 markus_sabadello: There's an overview of those two specs on that first slide. If you look through the items on the right side, Section 3 Resolving a DID, Section 4 Deferencing a DID URL. Resolution and Dereferencing are defined, but those are not protocols with client/server for example, but they are defined as abstract functions that can be realized in different ways. 15:14:16 JingxuanLi has joined #did 15:14:34 markus_sabadello: These first two sections 3 and 4 define the inputs and outputs and the algorithm for resolving and dereferencing. The section 5 talks about resolvers, etc. Do you access a DID method underlying storage directly or use an intermediary service, etc. Section 6 will change a bit involving the discussion around metadata for the data that is not in the DID Document. 15:14:45 markus_sabadello: There is a structure about a DID resolution result for that, but it may change quite a bit. 15:15:04 markus_sabadello: There is another section about an HTTP binding, if DIDs are deployed via HTTP services, etc. 15:15:14 markus_sabadello: Privacy considerations, etc. as well. 15:15:20 https://github.com/w3c/did-core/issues/198 15:15:29 markus_sabadello: We have an issue in IRC. 15:15:56 markus_sabadello: There was consensus at F2F to add some of DID Resolution into DID core. That's what this issue is for. The sections in the DID core spec, 3.4 and section 10, they are empty or almost empty and they need to be filled. 15:16:21 markus_sabadello: That's what issue 198 is trying to do. So in the remaining slides in this presentation I came up with ideas for what the boundary could be and what we might want to include in DID core and so far what's been in scope. 15:17:00 markus_sabadello: If you look at slide 3, perhaps the functions that are defined in DID Resolution (resolving and dereferencing), what are the inputs and outputs could perhaps be moved into DID core. But the detailed algorithm could remain in the DID Resolution spec. 15:17:36 markus_sabadello: That's one idea. If you look at slide 4, there's an open question because in the DID Resolution spec we define the "resolve" function, we also define, in DID core, the DID method operation, the READ operation, as it is required for each method and there's a very close relationship between those things. 15:17:40 gannan has joined #did 15:18:06 q? 15:18:10 markus_sabadello: On slide 5 and 6 there are some additional ideas on what content or topics could be considered in scope for DID core which have so far been in scope for DID Resolution. For example the architectures and the additional data structures, not just the DID Document. 15:18:18 markus_sabadello: I'll pause here and ask for questions. 15:18:22 q+ 15:18:59 drummond: Going through his slides it looks quite reasonable. What he's proposing. I'll pose this in terms of a question, we used "the contract" in Amsterdam. Is there a specific place where you'd see that contract described? 15:19:21 markus_sabadello: That would be in the new section 10. That's called "Resolution" and I think it would cover the inputs and outputs of the resolution function and the dereferencing function. 15:19:40 q+ 15:20:18 markus_sabadello: For example, it would say, if you want to resolve something, resolution works by passing inputs a DID and options and the result would be a DID Document in one of the supported representations and metadata. Another would be for dereferencing, sending in a DID URL and options and getting back content type, metadata, some other things to discuss there. 15:20:39 markus_sabadello: Open issues there, ongoing discussion on metadata and matrix parameters and things that will influence all of this. Defining the inputs and the outputs. 15:21:01 markus_sabadello: The detailed implementation could remain in the DID Resolution specification or we could decide to pull it in here but I think we'd just have the interface here in DID core. 15:21:12 drummond: Yeah, I think the interface is the contract and that's how I had been thinking about it, it sounds good to me. 15:21:12 q? 15:21:22 ack Justin_R 15:21:49 Justin_R: I just wanted to make the point that the nature of this contract is going to be at the same level as the rest of the DID Document, specification, it will describe the data structures that go in and out and not necessarily the syntax of those. 15:22:06 Justin_R: Up to the point though where we have to describe the syntax of what the data structures are that need that. That's where the content type comes in and stuff like that. 15:22:14 present+ 15:22:41 Notes from last week's DID Resolution call in the Credentials Community Group: https://github.com/w3c-ccg/meetings/tree/gh-pages/2020-03-05-did-resolution 15:22:46 Justin_R: We had a conversation on the call last week for different approaches to that that will have to be wrapped in here, but when we say things like "options" we are saying that we will have a map between strings and other strings or strings and arrays or something like that that is simple and universal that can be used to describe what each of those parts are. 15:22:59 Justin_R: It's really important that that be nailed down in the DID core spec and that hasn't been done yet. 15:23:01 markus_sabadello: I agree. 15:23:01 ack phila 15:23:50 -> https://github.com/w3c/did-core/issues/159#issuecomment-597068527 My comment on matrix parameters 15:23:56 phila: I follows on from what Justin was saying. I find it increasingly dissonant that we aren't making the DID Resolution spec part of the group. Especially with what's being pulled into core per Markus. I think we should make that spec be part of our output, it makes DIDs more real, and testable. I'd like to see it part of the WG. I personally haven't had time to look at the metadata issue but I will, it's close to my heart. 15:24:00 identitywoman has joined #did 15:24:06 present+ 15:24:18 q? 15:24:19 q+ 15:24:23 phila: I did write out a comment on the matrix parameters issue which I did on github today. We have tackled similar problems at GS1 and from my point of view we don't need matrix parameters. 15:24:33 ack dbuc 15:25:11 q+ 15:25:17 dbuc: I just posted to that thread on matrix parameters, one of the most important things we can do is scope what they should and shouldn't be used for. There should be a clear line. If you really care about this implementation, given what these matrix parameters are for ... it can get ugly with URL parameters that would make them not work the way they usually do. 15:25:26 ack markus_sabadello 15:25:43 https://github.com/w3c/did-core/issues/65 15:25:57 markus_sabadello: These topics and issue could influence what we do, please take a look at them (in IRC). 15:26:23 markus_sabadello: If there's no objection I will probably try to put what I just presented into a concrete proposal with some initial content for the DID core specification that Justin and I already committed to. 15:26:34 +1 15:26:36 markus_sabadello: I just wanted to mention this and then move ahead with concrete text for the spec. 15:26:37 +1 15:26:43 brent: That sounds great. 15:26:50 brent: Next up is the issue game. 15:27:26 brent: Sorted according to how they were last updated, you should have the list. Hopefully you'll be prepared to make some comments. 15:27:53 brent: The goal is for the person who the issue is assigned to to tell us what next steps are needed to move the issue forward, please don't discuss the issues themselves. 15:27:56 https://github.com/w3c/did-core/issues/163 15:27:57 brent: I hope you're ready Mike Jones. 15:28:22 brent: Use of terms defined in the specification should be linked to their definitions. Status update? 15:28:46 selfissued: This is just normal syntax hygiene for a W3C spec, I believe it should be assigned to one of the editors to do, it's not rocket science. 15:28:53 I can make a PR for this. 15:28:54 selfissued: Which editor is willing to do this? 15:28:56 +1 it's quick editorial stuff in respec, I think 15:29:10 drummond: I'm willing and go in and see. This obviously has been pending for a while throughout the entire spec. 15:29:32 selfissued: It's global edit that just needs to be done. It will cause merge conflicts with everything, so it should be done at an appropriate time but an editor should be assigned to this. 15:29:38 drummond: Assign me right now. 15:29:42 selfissued: Ok. 15:29:48 https://github.com/w3c/did-core/issues/165 15:30:12 brent: "What are entityship and start-of-authority (SOA) problems?" 15:30:44 selfissued: This is one of the many cases of terminology used in the spec that is not well understood most people. I'm an expert in most identity topics and I still didn't know what this was talking about. Whomever understands it should define it or I can volunteer to write a PR to remove it. 15:31:10 brent: Anyone in the group who feels like they could more concretely define this terminology and would be willing to raise a PR for that? 15:31:30 selfissued: I will volunteer to write a PR to remove the unclear language. 15:31:40 brent: I agree -- that PR will be a good place for people to suggest changes on that PR. 15:31:48 https://github.com/w3c/did-core/issues/166 15:32:14 q+ to say I can take this one 15:32:44 selfissued: This isn't testable, it shouldn't be normative. Unless someone wants to own this, I'll make the same gesture to remove the non-actionable language. 15:33:01 brent: What about Amy's suggestion to point to the Rubric? 15:33:11 selfissued: That's fine but I would remove the normative language. 15:33:21 burn has joined #did 15:33:22 q- 15:33:23 drummond: In your PR just make the language non-normative and point to the Rubric to take care of it. 15:33:25 selfissued: Ok. 15:33:37 brent: If you can make comments on the issue for what will be done would be excellent. 15:33:39 selfissued: I'm doing that. 15:33:41 https://github.com/w3c/did-core/issues/167 15:33:46 brent: I figured you were, thank you. 15:34:17 selfissued: Amy writes that this is expanded using the abridged syntax. I don't know what that does. 15:34:18 q+ 15:34:37 selfissued: When I clicked on it when I was filing these issues it didn't do anything. 15:34:47 selfissued: I'm not proposing to remove this, I think someone should add a definition. 15:34:48 selfissued: it expands the acronym on hover 15:34:54 markus_sabadello: You can assign this to me, it's relevant to resolution. 15:35:33 selfissued: We should have actual definitions in the terminology section. That's clever but when someone prints the document it's useless. 15:35:46 https://github.com/w3c/did-core/issues/168 15:36:35 selfissued: This is not syntactic, it is semantic. 15:36:45 brent: What do you feel this issue needs to move forward? 15:37:10 selfissued: I'd like the proponents of revoked keys to actually discuss this. 15:37:25 selfissued: A lot of these comments I was pointing out places where the spec says something that's not actionable or not interoperable. 15:37:53 selfissued: This is one such issue. I can say I invite... I just got a comment from Orie that he's not in favor of having revoked keys as well. 15:37:53 I second that 15:38:01 brent: Amy added a discuss label and I agree with that. 15:38:22 https://github.com/w3c/did-core/issues/169 15:38:41 selfissued: I've gotten the sense on the registries calls that we're agreeing to do this. 15:38:59 brent: I think a comment to that effect would great and hopefully we can get feedback from the rest of the group. 15:39:30 https://github.com/w3c/did-core/issues/170 15:39:39 brent: Chair note: I hope Mike and the group doesn't feel that Mike is getting picked on at all, I'm very grateful for this set of issues and that he's read the spec closely and cared about its progress. 15:39:46 brent: I want that statement out there as we move forward. 15:40:49 q+ 15:41:08 selfissued: The text should be updated to make this clearer and I agree with Orie's comment that we need examples. There should be examples. There should be examples with keys using JWK and I think it would help all of the engineers in the room, myself included, on how to reasonable this by looking at how the examples are written. 15:41:13 selfissued: I think the next step is an example using JWK. 15:41:26 brent: Would you be willing to raise that PR? 15:41:32 selfissued: It's already raised, I 15:41:40 selfissued: I'll add a reference to it when I find it. 15:41:49 https://github.com/w3c/did-core/issues/171 15:42:45 brent: If there were a PR to add examples to the spec would that address 170 and 171? 15:42:56 selfissued: It would provide background for more concrete discussion of 170 and 171. 15:43:05 q? 15:43:07 brent: Do we have a volunteer to add some examples via PR to move these issues forward? 15:43:16 ack markus_sabadello 15:43:19 ack jonathan_holt 15:43:54 q+ 15:44:02 jonathan_holt: I think Orie put an example and linked to it in the core registry. I think the issue is the conflict between `id` and `kid` and the centerpiece of this being pure JSON and JSON-LD and that we're overloading the `id`. 15:44:10 ack Orie 15:44:46 Orie: So, in the case where you have a key that's not represented by JWK, you're going to need some form of identifier for it. The identifier for a key that's in a DID Document and the identifier for a key that may represent it in some external system -- it's helpful to have both. 15:45:04 Orie: The links I'm including are examples for verification keys and there are JSON schemas for the JSON only and the JSON-LD definitions of them. 15:45:22 Orie: As we are able to pick up the pace in the registries we'll be able to provide better examples and we'll need to link back to the spec for that. 15:46:01 Orie: There is a note in the DID Core spec and there are links to the registries where the normative definitions are in the DID core spec. It's an open question with whether the core key definitions are defined in DID core, we may not want to create normative definitions in DID core. 15:46:01 q+ 15:46:16 brent: Thanks, Orie. Please summarize that comment in these issues, that would help the group. 15:46:20 ack selfissued 15:46:26 Related normative statements: https://github.com/w3c/did-core-registry/issues/9 15:47:02 selfissued: I'll actually disagree with you on that point, Orie. On the key representation calls, and in the WG, we agreed that JWK would be supported for everything and some other types would be supported for some things. At the very least we have to define JWK in a normative fashion and everything else we have normative references to. We can't just point to a community spec we have no control of. 15:47:10 q+ 15:47:18 q- 15:47:29 I agree with you mike :) we do need some of this stuff in core... not sure how much of it. 15:47:30 selfissued: There are examples in the core spec now but none of that use JWK even though it's the one key format that we agreed to support across the board. That's setting a bad example for developers. 15:47:48 selfissued: One idea is that we can take the example from the registries that Orie linked to and update the example in the core spec using it. 15:47:51 q+ 15:48:02 brent: I personally think that is a fine suggestion. 15:48:05 selfissued: Who will do that? 15:48:14 ack jonathan_holt 15:48:46 jonathan_holt: Is the `id` equivalent to the `kid` in the public key section? If I have to iterate through and find a key by ID, I'm struggling to understand how it would actually be performed. 15:48:55 brent: You should raise that question and concern in issue 170. 15:49:01 brent: To help move that conversation forward. 15:49:01 pubkicKey.id != kid for all key representations.... we still need to define all this stuff in core to make it clear. 15:49:24 selfissued: I will take the issue if I have to, but some of the rest of you may want to do it as well. 15:49:30 selfissued: I guess I'll do so. 15:49:34 brent: Thank you, Mike. 15:49:41 https://github.com/w3c/did-core/issues/172 15:50:14 brent: There's a PR that exists that has been merged. Looks like Manu says there's a couple more requests that may close the issue out. 15:51:14 selfissued: Ok, I think this is done. 15:51:17 brent: Do the honors. 15:51:54 https://github.com/w3c/did-core/issues/174 15:52:46 selfissued: There are comments that this may be method specific and that may be true but even if that's true the core spec, in our list of requirements for method specifications, we should include that the method define what "updated" means to it. 15:52:51 q+ 15:53:11 drummond: I agree both with what Mike said and with what Joe just added about this being a metadata issue. 15:53:20 selfissued: I will add that comment to the issue. That doesn't mean we're done. 15:53:33 brent: I think we need the clarifying text in the right place, that's an important aspect of this issue. 15:53:39 q? 15:53:53 ack markus_sabadello 15:54:00 Sorry lost my audio again :( 15:54:07 q- 15:54:22 https://github.com/w3c/did-core/issues/175 15:55:29 jonathan_holt: I remember discussing this a few months ago. The X.509 extensions give you the ability to add an ID field. 15:55:52 q+ 15:55:53 jonathan_holt: You can leverage self-signed X.509 certificates with a DID. 15:56:22 selfissued: My read of this was different, I thought the author was talking about augmenting the ecosystem where DIDs were used instead of certificates. Which kind of makes my point. 15:56:31 brent: That's definitely an indication that we need more clarity around this. 15:56:44 ack drummond 15:57:24 drummond: I think this text is a hold over from some early versions of the spec that we simply wanted to point out that DIDs and DID Documents had a relationship with the existing PKI, which is largely X.509 based. Not defending the wording, just saying where it came from. 15:57:54 q+ 15:58:11 drummond: As trying to enumerate the various security considerations we wanted people to understand that DID Documents could be an extension or augmentation to X.509 but we should reword what's being communicated here. We do frequently get the question about the relationship between DIDs/existing PKI. 15:58:29 drummond: So we should say something about that. I would volunteer to do that, but I would have to tap others as I'm not an X.509 expert. 15:58:31 q? 15:58:37 selfissued: Do we have any way of knowing who wrote the text? 15:58:42 brent: git blame. 15:59:21 rhiaro: I think the text is gone. 15:59:31 ack rhiaro 15:59:33 selfissued: I agree that it's gone, I'm happy to close on that basis. 16:00:19 brent: Thanks for coming, we'll keep suffering with Daylight Saving madness, keep working in github. 16:00:29 RRSAgent, draftminutes 16:00:29 I'm logging. I don't understand 'draftminutes', phila. Try /msg RRSAgent help 16:00:34 RRSAgent, draft minutes 16:00:34 I have made the request to generate https://www.w3.org/2020/03/10-did-minutes.html phila 16:00:52 ken has left #did 16:00:55 Zakim, end meeting 16:00:55 As of this point the attendees have been rhiaro, yancy, Justin_R, again, everyone, zakim, wasn't, here, markus_sabadello, JoeAndrieu, selfissued, dlongley, joel, Orie, chriswinc, 16:00:58 ... Tom_S___USAA_, agropper, phila, drummond, brent, jonathan_holt, running, a, bit, late, though, deiu, kimhd, ken, Benjamin_Young, gannan, identitywoman 16:00:58 RRSAgent, please draft minutes 16:00:58 I have made the request to generate https://www.w3.org/2020/03/10-did-minutes.html Zakim 16:00:59 thanks phila ! 16:01:01 I am happy to have been of service, phila; please remember to excuse RRSAgent. Goodbye 16:01:05 Zakim has left #did 16:01:21 RRSAgent, please excuse us 16:01:34 RRSAgent, make logs public 16:01:45 RRSAgent, please draft minutes 16:01:45 I have made the request to generate https://www.w3.org/2020/03/10-did-minutes.html phila 16:02:19 meeting: DID WG weekly 16:02:22 chair: Brent 16:02:28 RRSAgent, please draft minutes 16:02:28 I have made the request to generate https://www.w3.org/2020/03/10-did-minutes.html phila 16:03:06 RRSAgent, please excuse us 16:03:06 I see no action items