13:49:55 RRSAgent has joined #did 13:49:55 logging to https://www.w3.org/2020/06/30-did-irc 13:49:57 RRSAgent, make logs Public 13:49:58 please title this meeting ("meeting: ..."), ivan 13:50:43 Meeting: DID WG (Virtual) F2F — 1st day 13:50:43 Chair: burn, brent 13:50:43 Date: 2020-06-30 13:50:43 Agenda: https://tinyurl.com/ycyhrv8w 13:50:43 ivan has changed the topic to: Meeting Agenda 2020-06-30: https://tinyurl.com/ycyhrv8w 13:50:44 Session slides: https://tinyurl.com/y87mqtlf 13:50:53 burn has joined #did 13:52:04 present+ ChristopherA 13:52:15 present+ 13:57:34 present+ 13:59:03 phila has joined #did 13:59:50 tzviya has joined #did 14:00:41 justin_r has joined #did 14:01:39 chriswinc has joined #did 14:01:43 present+ phila, charles, chriswinc 14:01:50 present+ 14:01:55 present+ 14:02:06 present+ 14:02:24 present+ PaulMadsen 14:03:01 JoeAndrieu has joined #did 14:03:34 present+ dirk 14:03:39 present+ manu 14:03:58 I'm getting a password prompt from zoom... 14:04:08 present+ drummond 14:04:08 present+ 14:04:42 present+ kdenhartog 14:05:33 present+ EugeniuRusu, brent 14:06:04 present+ timcappalli 14:06:17 rrsagent, make minutes 14:06:17 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html manu 14:06:22 Eugeniu_Rusu has joined #did 14:06:28 drummond has joined #did 14:06:39 present+ 14:06:40 brent has joined #did 14:06:41 rrsagent, make logs public 14:06:44 present+ 14:06:47 kdenhartog has joined #did 14:07:01 Can someone provide the meeting password? 14:07:36 scribe+ 14:07:52 brent: Welcome everyone to the DID WG -- going to go over Agenda, IPR, then set stage for status of deliverables, timeline. 14:08:19 brent: We'll be meeting until 10am-1:30pm ET today 14:08:26 brent: tomorrow we'll be starting at 12pm ET 14:08:55 brent: We have breakout rooms here -- https://zoom.us/j/91515310373?pwd=WVF0T1Jrc0Nwazl3TUZhYU85dUEyZz09 14:09:06 present+ identitywoman 14:09:18 brent: We abide by the W3C Patent Policy here - only people/companies listed can make substantive changes to specs we're writing, please follow W3C Code of Conduct. 14:09:29 brent: which basically boils down to "be nice to each other" 14:10:11 brent: We're goign to go over logistics, use cases, break, rubric and implementation guide. 14:10:12 present+ 14:10:18 q? 14:11:32 brent: Please add your name to scribes if you can scribe... you can use queue via "q+" -- use the queue if things get crazy. 14:11:40 brent: keep your comments brief 14:11:42 DirkBalfanz has joined #did 14:11:44 markus_sabadello has joined #did 14:11:47 present+ 14:11:51 brent: helps scribes if you use the queue. 14:12:06 brent: make sure to 'present+' yourself. 14:12:31 oliver has joined #did 14:12:35 present+ oliver_terbu 14:12:39 brent: over to Dan. 14:13:17 paulmadsen has joined #did 14:13:30 burn: Usually, we have an introductions section -- but we're not doing that today because we are short on time... 14:13:35 zakim, who is here? 14:13:35 Present: ChristopherA, ivan, burn, phila, charles, chriswinc, justin_r, PaulMadsen, dirk, manu, drummond, JoeAndrieu, kdenhartog, EugeniuRusu, brent, timcappalli, Eugeniu_Rusu, 14:13:40 ... identitywoman, markus_sabadello, oliver_terbu 14:13:40 On IRC I see paulmadsen, oliver, markus_sabadello, DirkBalfanz, kdenhartog, brent, drummond, Eugeniu_Rusu, JoeAndrieu, chriswinc, justin_r, tzviya, phila, burn, RRSAgent, Zakim, 14:13:40 ... ivan, rhiaro, deiu2, hadleybeeman, ChristopherA, bigbluehat, wayne, faceface, Travis, dlongley, manu, loveish, root, dlehn 14:13:41 burn: our mission is to “... standardize the DID URI scheme, the data model and syntax of DID Documents, which contain information related to DIDs that enable the aforementioned initial use cases, and the requirements for DID Method specifications.” 14:14:12 ch has joined #did 14:14:26 +p 14:14:30 burn: Named deliverables in the charter 14:14:41 burn: Decentralized Identifiers v1.0 -- Almost all major issues resolved, lots of little stuff 14:15:01 burn: We've gotten pretty far w/ major issues... lots of little stuff left, definitely not done, more than 50 issues left. 14:15:12 burn: We still have a bit more to do, major issues have been resolved. 14:15:23 s/+p// 14:15:45 dmitriz has joined #did 14:15:56 present+ 14:16:11 burn: We have a couple of other notes that are optional. 14:16:12 present+ 14:16:25 burn: Decentralized Identifier Use Cases v1.0 -- Close to done.  Maybe today? 14:16:26 present+ 14:16:33 agropper has joined #did 14:16:46 burn: It would be nice to get done or close to done on that document. The group has been pretty clear on it's understanding on what DIDs are and what they do. 14:16:53 present+ 14:17:16 burn: With respect to Decentralized Characteristics Rubric v1.0 -- Nothing yet. We will discuss today. -- what does "Decentralized" mean? 14:17:42 burn: at time, we concluded that there were different definitions... we wanted to come up with questions that you should ask yourself in order to understand how "decentralized" a particular item is for your use case. 14:18:13 burn: Goal is not to provide answer, but to provide questions... what needs to be considered. Haven't begun that work yet, even though there is preliminary work elsewhere. 14:18:29 burn: There is another deliverable that's important -- Test Suite and Implementation Report -- There are some tests, but we have not yet SERIOUSLY begun. 14:19:03 burn: Any questions? 14:19:06 q+ 14:19:28 i can scribe 14:19:36 manu: there are also the did spec registry documents 14:20:07 s/i can scribe/scribe+/ 14:20:12 burn: you're right. these are the items that are in the charter. We should have added some more bullet pts for other othe documents, such as the DID Registry Spec 14:20:15 scribe+ 14:20:34 burn: If it becomes relevant, we can bring it up - we've made good progress on that... progress on that document allowed us to resolve big sticking points in specs. 14:21:22 burn: That document contains a collection of registries, not just one - we seem to be winding down on what belongs in that document... which registries belong in that document. Obviously, people can keep adding items to that registries document... that document is in pretty good shape right now... good examples, fuller information on alternate representations, JSON-only, and CBOR. 14:21:33 burn: We're going to be talking about that during this meeting. 14:22:04 burn: We are still in Working Draft stage, does not imply consensus. 14:22:36 burn: Next stage is Candidate Recommendation (CR) -- Entry - to publish as CR, the document is expected to be feature complete, have had wide review, and must specify the implementation requirements needed to exit. 14:23:01 burn: anyone that might have significant opinion should have had opportunity to comment, haven't started wide review yet... need to specify requirements in order to exit CR stage. 14:23:16 burn: To exit, you have to satisfy requirements, multiple independent implementations. 14:23:30 burn: This is why test suite becomes important... you don't need test suite to exist in order to get to CR. 14:23:54 burn: Our goal is to ensure test suite is as ready as possible before we enter CR, ensure little delay for implementers to check implementations against test suite. 14:25:09 burn: To go from CR to PR, you can't make any substantive changes... you can say features are at risk to prevent that... concern that there might not be sufficient implementations... this feature will be removed if we don't get sufficient implementation reports. if you have warned about a feature at risk, then feature can be removed in switch to PR... but any other unplanned substantive change (change to implementations) then you have to issue another CR 14:25:09 or go back to WD stage. 14:25:28 burn: We work pretty hard to make sure we think document is good and ready short of any feedback we might receive from implementers. 14:25:41 burn: Exit - to exit CR (and move to PR), the document must satisfy the stated implementation requirements; it must also not have made any substantive change not warned about upon entry 14:25:54 burn: Going to Proposed Recommendation (PR)...Basically a one-month sanity check during which the AC is encouraged to have any final review and discussion, but if anything major happens it’s a fail (requiring a move back to CR or earlier) 14:26:47 present+ 14:27:12 burn: We go to a large amount of effort to make sure we won't fail... 30 day clock typically, then it becomes a Recommendation. Still possible to do Errata after that. 14:27:29 ivan: It's a six week clock now instead of 30 days, because of Covid situation 14:28:47 burn: There is a pretty picture of the process here -- https://www.w3.org/2019/Process-20190301/#recs-and-notes 14:29:34 q+ 14:29:38 q- 14:29:52 burn: We were chartered for 2 years, starting last year... in August 2021, we're done unless we're extending charter... that requires approval by W3C Members -- need a very good reason or big support. 14:30:01 q- 14:30:02 burn: We counted backwards to get to dates we need to hit. 14:31:10 burn: In order to finish by August 2021, we need to have PR by July, which means CR2, CR2 by March 2021, CR1 Nov 2020. 14:31:48 burn: This is not a get out of jail free card... "it's not really a CR" -- no, we are absolutely convinced by Nov2020 of this year... and then oops, we missed something, so we had to do another one. If we do that, we're still fine, still fit within timeframe. We need first CR by this year. 14:32:28 burn: Targeting feature freeze by May 2020... not feature freeze yet... at very end of June, that's ok, we have addressed major topics and clearened minor ones along the way. Chairs will be calling for feature freeze very very soon. 14:32:52 burn: Why are we going to be pushing so hard for feature freeze... if spec isn't ready, it isn't ready, but if we want to hit our timeline, we need to get to feature freeze soon. 14:33:34 burn: The goal of this meeting is to GET TO FEATURE FREEZE... :) 14:33:58 burn: If you have something new that isn't in the spec and there isn't an issue, then very soon, we're going to disallow new items like that. Any questions? 14:34:02 Silence 14:35:00 burn: There is a precise list of things that needs to happen to get into CR, we'll put that list together when group agrees on feature freeze. 14:35:21 Topic: Use Cases 14:36:11 phila: Dan said use cases might be done on this call, I think we're close, still need a few weeks of work. 14:36:57 phila: As I hope everyone on call is aware, use case document that Joe and I are working on, adaptation of one worked on in CCG by Kim and Adrian... we did get FPWD out in Nov last year as Charter asked us to do. 14:37:15 -> https://w3c.github.io/did-use-cases/ editor's draft of the Use Case document 14:37:30 phila: Because this work is not starting from nothing, it would've been unhelpful if we couldn't talk about DIDs and DID Docs and things that underpin core work. We do say early on, we are not starting from scratch, but these are use cases that underpin it all. 14:37:50 phila: We didn't want to put solution before the problem, a bit of a balance between those two, we know the space we've been working in... 14:37:55 phila: We're trying to go from there. 14:38:41 phila: Original document from CCG - 4-5 focal use cases, they are still in doc, but have been amended. There was one that had solutions everywhere, etc... new section that not was in original, short use cases, 1-3 paragraphs long, a bunch of short use cases that Joe and I have curated, but not written by us. 14:39:29 phila: One of the problems we've had throughout the document is making sure use cases demanded existence of DIDs and functionality and not automatically going tinto VCs... make sure use cases are not VC use cases. I think we've succeeded, VCs are a use case, but making document stand on it's own, DIDs have purpose in absence of VCs have a purpose. 14:39:49 phila: We've been chatting our way through it... short list of issues outstanding that we can't resolve betwene ourselves, want to focus on that today. 14:40:16 https://github.com/w3c/did-use-cases/issues/2 14:40:22 phila: Issue 2 Need to add coverage of portability/substitutability Left over from CCG -- Propose: close (overtaken by events) 14:40:51 q+ to attempt to explain. 14:41:00 One of my favorite phrases => overtaken by events 14:41:39 q+ 14:41:51 q+ 14:42:02 ack manu 14:42:02 manu, you wanted to attempt to explain. 14:42:31 manu: The initial goal here was to ensure that the identifier that a VC used was portable... for example, portability of a DID. 14:42:36 q- 14:42:53 scribe+ dmitriz 14:42:55 present+ 14:42:55 Orie has joined #did 14:42:59 present+ dmitriz 14:43:01 timcappalli has joined #did 14:43:01 present+ 14:43:05 present+ 14:43:08 present+ 14:43:22 q+ 14:43:31 JoeAndrieu: What does portability mean? Is there some way that I can take a DID in one ledger and get it into another ledger. That's why this isn't written up yet. 14:43:40 JoeAndrieu: I don't think it's in the use cases, but adding it to ticket. 14:43:44 ack drummond 14:44:00 q+ to say intent wasn't for capital Portability. 14:44:27 drummond: I thought portability of data - move portability of blog from one provider to another. 14:45:18 phila: Would be good to get something from you Drummond. 14:45:24 re what joeAndrieu said, this issue is related: https://github.com/w3c/did-core/issues/33 14:45:25 ack dmitriz 14:45:55 dmitriz: Glad Joe brought up portability of DID Document itself, if that's in scope, related issue 33 on DID Core -- "sameAs" property. 14:46:03 q+ 14:46:21 +1 14:46:27 +1 14:46:36 present+ oliver 14:46:45 ack manu 14:46:45 manu, you wanted to say intent wasn't for capital Portability. 14:46:47 dmitriz: How do we link one DID Document to another, both represent the same subject in preparation for migration. Relevant topic, relevant to use cases, whether or not it should be in DID Core is the controversial bit, different views there. We need the linking to DID Document sameAs functionality in order for DID Document to be portable. 14:47:05 manu: I think the original intent of the portability issue was lowercase-p portability 14:47:08 q+ to suggest moving to Issue disussion for the sake of timeboxing 14:47:13 q+ 14:47:20 ... not necessarily full equivalence "move the DID from one ledger to another" use case 14:47:37 ... and I fully admit that all of these are portability use cases, and we'll just have to figure out where we're drawing the line (or if we are) 14:47:52 ... it's a pretty deep rabbit hole to go down. And we'll have to figure out where to stop, at least for this version of the WG 14:48:11 ... and I'm sure as you and Joe have discussed, there are various ways to document the use cases (but not solve/implement) 14:48:21 ... so, basically, it was supposed to be the _easy_ portability problem 14:48:45 phila: yes, we need a bit of text that hints at those use cases, but we don't need to go into great depth. 14:48:46 ack drummond 14:48:55 q- 14:49:08 drummond: Dmitri is right on, I'm working on PR for sameAs property... would like Dmitri to work with you on that. 14:49:41 ack JoeAndrieu 14:49:41 JoeAndrieu, you wanted to suggest moving to Issue disussion for the sake of timeboxing 14:49:55 JoeAndrieu: Let's move this to issues... need to get through rest of stuff. 14:50:26 https://github.com/w3c/did-use-cases/issues/14 14:50:46 phila: Issue 14 What does it mean for a DID to be "recorded in a registry"? Mike raised this, Joe and Manu have discussed, DaveL supports... 14:51:26 q? 14:51:52 q+ to offer a naive solution to 'what does it mean for a did to be recorded' 14:52:20 JoeAndrieu: We refer to DID Registries as where you go to do resolution... but some DID Methods, resolution is baked into DID itself, there really isn't a separate registry... however, we also have Verifiable Data Registries, different beast, we call them both registries... we've cleaned up language in use case document, when we use registry, we mean it for DIDs that use a registry, not all DIDs use a registry. 14:52:24 q- 14:52:26 q+ 14:52:27 ack dmitriz 14:52:31 JoeAndrieu: We might be clear in use cases, not in DID Core, uses may be compatible. 14:53:04 q+ 14:53:15 dmitriz: I like what Joe said -- proposed we resolve this - if this is controversial, similar interpretation - since we talk about CRUD operations on DID Documents, create, read, wanted to propose, recording DID in registry... talk about it. 14:53:23 phila: Under action on Create, that's what we talk about. 14:53:24 q? 14:53:39 ack drummond 14:54:08 drummond: We're taking comments on PR for terms - only use verifiable data registry, that's what we're using now, don't use "registry" by itself, only call it VDR. 14:54:17 ack next 14:54:17 drummond: You are either using one or you're not, that's all. 14:54:25 q? 14:54:51 markus_sabadello: Dmitri and drummond said what I already wanted to say - create operation applies to every DID and DID Method... don't have to think registry, ledger, etc... DIDs can be created and resolved. 14:55:06 https://github.com/w3c/did-use-cases/issues/39 14:55:20 phila: Use Case issue 39 is a duplicate of core issue 248. Need term for relying party 14:55:25 phila: What do you call a relying party? 14:55:45 -> related https://github.com/w3c/did-core/issues/248 14:55:47 +1 to 'Requested Party'. 14:55:48 phila: I wrote out history -- I believe there is consensus around Requesting Party - people commented are content with that, no strong objections to that. 14:55:50 er, requesting. 14:55:55 q+ 14:56:00 ack markus_sabadello 14:56:03 phila: any objections? 14:56:09 q+ 14:56:49 markus_sabadello: I didn't understand this issue, You have to say what action you're thinking about... someone who resolves the DID, someone trying to authenticate DID Controller, someone requesting proofs/claims... what is this entity/actor doing? 14:56:50 ack justin_r 14:57:01 q+ 14:57:14 justin_r: I haven't dug into the text of the issues... but did want to point out that Requesting Party is used in UMA protocol. 14:57:27 justin_r: Want to make sure Editors were aware of it's use in different but related space. 14:57:41 q? 14:57:43 ack dr 14:57:47 ack drummond 14:57:56 phila: We have jumped around trying to think of alternatives... "Brandishing Your DID" was put forth briefly *chuckles*. 14:58:08 drummond: We might want to use Verifier -- consistent with both specs... 14:58:13 -1 for verifier 14:58:14 q+ 14:58:17 phila: We looked at it, it was shot down. 14:58:28 present+ agropper 14:58:45 phila: It sounds as if we have to come up with something, where someone is making use of DID in particular way 14:59:08 phila: It's difficult, we're searching around for a term that doesn't reuse something someone else is using, finding it difficult to find a word here. 14:59:11 q+ 14:59:16 ack agropper 14:59:22 phila: nearest I can come to is Requesting Party unless someone has an objection. 14:59:47 I don't have a strong objection to "Requesting Party". I'd prefer "verifier", but "Requesting Party" is okay. 14:59:59 ack ivan 15:00:04 agropper: I introduced the term, I did it explicitly because Requesting Party was defined adequately in UMA - giving proxy to Justin, no way want to insist on Requesting Party, if we have consensus, great. 15:00:31 ivan: Just want to say that this is a NOTE, not a REC, so we can go the other way, leave it as is, put a note to make it clear that term is used in loose way. 15:01:07 ivan: Then we should move on - have DID Core define it... 15:01:25 q+ 15:01:32 +1 requesting party 15:01:33 +1 to Requesting Party 15:01:35 ack drummond 15:01:44 phila: Then we can't finish until DID Core until that's done. Let's see if we can get Requesting Party done. 15:01:52 drummond: I'd be fine w/ Requesting Party -- 15:02:17 identitywoman has joined #did 15:02:23 present+ 15:02:36 PROPOSED RESOLUTION: That we use the term "Requesting Party" 15:02:41 +1 15:02:42 +1 15:02:42 manu: +1 15:02:42 +1 15:02:44 +1 15:02:44 +1 15:02:47 +1 15:02:47 +1 15:02:48 +1 15:02:48 +1 15:02:48 +1 15:02:51 +1 15:02:55 +1 15:03:00 minor clarification: We'll use the term "requesting party" to refer to the party who uses a DID for any purpose. 15:03:02 Eugeniu_Rusu has joined #did 15:03:10 RESOLVED: That we use the term "Requesting Party" 15:03:35 https://github.com/w3c/did-use-cases/issues/75 15:03:47 present+ rhiaro 15:03:54 phila: Issue 75 We are doing an auto-inclusion of glossary from DID-Core. Amy has done a lot of work on this lately, couple of references outside of that document, messing things up. 15:04:06 phila: do we fix those errors - which we hope will make the filter mechanism work - or take a snapshot and allow a delta with “the core spec is normative” warning? 15:04:14 phila, I raised this on drummond's recent terms PR 15:04:26 q+ to note that this is all fixable. 15:04:31 q+ 15:04:32 ack manu 15:04:33 manu, you wanted to note that this is all fixable. 15:05:06 q- 15:05:09 manu: it's just a simple code fix, we have control over that. 15:05:17 phila: Great, then let's get that fixed. 15:05:28 phila: Joe and I have a list of things to finish up -- 15:06:06 phila: Issue 13 describe relationship between DID Methods and DID Authentication in Use Cases document (raised by Mike) 15:06:20 https://github.com/w3c/did-use-cases/issues/13 15:07:17 JoeAndrieu: We have some authn use cases, we didn't want to specify solution-based documentation, we might not want to talk about this. 15:08:17 phila: Do we need time on this? 15:08:47 JoeAndrieu: I'd like to just close this - authentication is intended to be method independent, I don't know how we describe relationship other than that, current language doesn't confuse the issue on that. 15:08:48 Sounds like a direct email to Mike would be good 15:08:53 phila: Then let's note this as pending close. 15:09:02 https://github.com/w3c/did-use-cases/issues/52 15:09:04 JoeAndrieu: Issue 52 Consider use cases from key representation discussion in did-core 15:09:08 https://github.com/w3c/did-use-cases/issues/82 15:09:13 https://github.com/w3c/did-use-cases/issues/81 15:09:37 phila: Issue 58 Suggestion: Better partitioning of "DID" actions Text already updated. Need to create better diagram, likely to be a set of SVG diagrams. 15:09:38 https://github.com/w3c/did-use-cases/issues/58 15:09:59 s/https:\/\/github.com\/w3c\/did-use-cases\/issues\/82// 15:10:13 phila: I need to create a set of SVG diagrams to make explicit what actions are. 15:10:31 https://github.com/w3c/did-use-cases/issues/62 15:10:39 phila: Issue 62 Jargon from VCDM and crypto. Need to read through and generally make it more readable. Lots done in this regard but more to do. 15:10:53 rrsagent, make logs public 15:10:57 rrsagent, draft minutes 15:10:57 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html manu 15:11:29 phila: WG Member's to do list -- If your use case isn’t there, or if your requirement is not covered by a use case, Please supply a PR... focus on DIDs, NOT VCs. 15:11:41 phila: We have a PR outstanding but the contributor, YueJing95, has not responded to request for clarification. 15:11:57 -> https://github.com/w3c/did-use-cases/pull/70 outstanding PR 15:12:52 phila: Re-do collation of requirements (including issue 87 domain map)... 15:13:04 q? 15:13:05 q? 15:13:06 phila: We won’t rename the master branch... 15:13:45 burn: Thank you, fabulous - increasingly in good shape w/ that document - please do continue to contribute. We have 15 minutes until break. 15:14:12 burn: We don't have a lot of time in this meeting... surprise request of Orie -- since we didn't put anything about Registries -- is there anything you'd like to get group input on? 15:14:19 Topic: group input on registries 15:14:48 Orie: I think it's ok to not have any registries issues discussion... we are going to talk a bit about this in key representations... ethereumAddress support. 15:15:05 q+ transform-keys 15:15:19 Orie: I'm advocating strongly for it's support in DID Core JSON-LD context... I think if people are looking for issues, PRs to review - please see DID spec registries. 15:15:25 https://github.com/w3c/did-spec-registries/pull/73 15:15:33 ack oliver 15:15:37 burn: I'll take you comment, Oliver, but may want to discuss later. 15:15:53 oliver: Recently we opened issue on registry for transform-keys=jwks - right time to discuss this? 15:16:17 oliver: Wanted to say that this is a feature that's very useful -- DID SIOP spec would strongly benefit from that feature... don't know if this is the right time, or can jump into that later? 15:16:25 link to that issue? 15:16:29 burn: Orie, thoughts? 15:16:29 about transform-keys? 15:16:57 Orie: We could cover it as it relates to key representations... could be DID Parameter that added that to DID Registry, we have seen enough examples of it, detailed enough about that. 15:17:16 burn: Whenw e're talking alter, we'll bring it up. 15:17:26 burn: In interest of best making use of F2F time -- suggestion brent? 15:17:35 q+ on a mechanical issue 15:17:38 brent: One thing we need to do is get scribe after break... other than that, happy to chat. 15:17:39 ack ivan 15:17:39 ivan, you wanted to comment on a mechanical issue 15:18:06 ivan: Echidna isn't working on DID spec registries... 15:18:22 ivan: Editors should look at what is happening... if there is a problem, I can talk w/ deniak. 15:18:23 q+ 15:18:30 q- transform-keys 15:18:38 ack manu 15:19:06 manu: The Editors will take a look. 15:19:20 burn: Anything else from anyone else for now? 15:19:45 +1 15:19:48 +1 15:20:01 burn: We'll take our break now, start 30 minutes from now. 15:20:14 burn: We will start at 11:50am. 15:20:39 Can you list the links for the breakout rooms? 15:20:41 brent: We've established two different zoom rooms for that use. 15:20:52 brent: One issue is you don't know who is in a room before stepping into it. 15:21:20 brent: Breakouts are on slide 3 15:21:39 rrsagent, draft minutes 15:21:39 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html manu 15:33:23 jonathan_holt has joined #did 15:48:26 present+ jonathan_holt 15:48:38 rrsagent, draft minutes 15:48:38 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html ivan 15:50:24 scribe+ rhiaro 15:50:31 TOPIC: DID Rubric 15:52:21 burn: the main question is whether we still want to do a decentralised characteristcs rubric? 15:52:30 -1 too early 15:52:30 ch has joined #did 15:52:31 +0 15:52:34 ... +1 we do, -1 we don't need to 15:52:36 +0 15:52:40 +1 15:52:41 +0 15:52:41 +0 15:52:45 +0 15:52:47 +0 15:52:55 +0 -- don't know who in the industry needs it. 15:53:04 -0 15:53:07 +1 15:53:10 q+ to note "someone else" doing it. 15:53:11 +1 because I thought we had started and it seems quite important but I might be missing something 15:53:15 But not strongly 15:53:37 burn: nothing has started in the WG yet, there's no rubric document yet 15:53:44 ... we're going to discuss here 15:53:44 ack manu 15:53:44 manu, you wanted to note "someone else" doing it. 15:53:59 manu: it may be people are on the fence because they feel like they don't need it, things have been resolved 15:54:07 q+ 15:54:13 ... the rubric came up at a point where we were really wringing our hands around centralized vs decentralized DID methods 15:54:33 ... another thing to think about is that if we d on't do a rubric of some kind another organisation is going to do it and we will probably hav eno power in influencing that discussion in the worst case 15:54:40 ... by choosing not to do this we should realise that somebdoy else is going to pick it up 15:54:45 q+ 15:54:57 The rubric was recommended as a way to address the challenge of calling our identifiers "decentralized" 15:54:58 burn: we're going to go into discussion in a moment 15:55:02 q+ 15:55:14 ... for people who joined us late, we're not explicitly discussing not doing the rubric, I wanted to get a sense from the group of how much interest there was in doing it 15:55:16 ... let's have a bit of discussion 15:55:28 ... I'll leave time for us to discuss what might be a starting point, assuming there is someone interested in doing it 15:55:30 ack agropper 15:55:31 q? 15:55:49 q+ 15:55:53 q+ to say maybe it is best for it to be an independent objective assessment 15:56:11 agropper: people are going to attack us whatever we do from the unintended consequences of privacy aspect. I don't think a rubric document is the way to solve that 15:56:17 ack ivan 15:56:18 q+ 15:56:19 ... we're not dealing with the unintended consequences of the core spec 15:56:33 ivan: i think the group has to produce documents that are not for ourselves, our implementers etc 15:56:46 ... to people around us for whom DID still remains a somewhat difficult to understand spec 15:56:52 ... we will need this kind of document 15:57:04 ... one of the issues that will come up is you guys produce shitloads of methods why should I use this one or that one 15:57:16 ack wayne 15:57:17 q+ 15:57:18 ... what's the reason and whatever, I think the goal of the document is partially to answer these kinds of questions, which are already there 15:57:32 q? 15:57:36 wayne: the concerns just now, picking the right did method and privacy concerns, these are some important dimensions of value i'm seeing out of a rubric 15:57:39 ... specifically decentralisation 15:57:53 ... if you're trying to have censorhsip resistance. how resiliant is this actually? some blockcahins are just run on three nodes 15:58:06 ... these measures, the single measure across many blockchains, how expensive is it to start adjusting your DIDs 15:58:19 ... having objecting tests that can measure these metrics we can all agree on would be hugely useful, in terms of picking the right DID method to a use case 15:58:35 kdenhartog has joined #did 15:58:36 ack drummond 15:58:37 ... +1 to the privacy aspects, there could be implications if you had a more private use case 15:58:38 q+ 15:58:44 present+ 15:59:00 drummond: one of the most valuable aspects is education about what decentralisation means 15:59:06 ... there are a lot of folks, that's a new concept 15:59:12 ... why is decentralisation important? 15:59:19 ... this document a little bit indirectly has a lot of education about that 15:59:24 selfissued has joined #did 15:59:28 ... i agree with ivan that it's the kind of document you would expect a mature spec like this 15:59:33 ... it will be referenced a lot 15:59:36 Eugeniu_Rusu_ has joined #did 15:59:44 present+ 15:59:46 ... as we discussed when we created it, we couldnt' find a reference for that definition 15:59:49 ... a lot of work has gone into it 16:00:00 burn: no work has gone into it from a WG standpoint 16:00:01 ack jonathan_holt 16:00:01 jonathan_holt, you wanted to say maybe it is best for it to be an independent objective assessment 16:00:06 could some of the original intentions of the rubric be met by the implementation guide? 16:00:08 present+ selfissued 16:00:15 jonathan_holt: certainly this topic has come up in a CG, I think it was incubated too early and we are a biased bunch 16:00:20 ... i welcome an outside objective view on this 16:00:22 https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu 16:00:28 ... I see this as a method of weeding out different methods 16:00:40 ack burn 16:00:43 ... if we more formally define what decentralized, portable nature of it and hand that off to an outside group to give us an outside perspective 16:00:52 q+ 16:00:54 burn: for this document we do not have to all agree that it needs to be done 16:00:58 ... we just need to not have anyone who objects 16:01:16 ... my secret reason for asking is because assuming there's enough support for doing it is I expect the people who spoke in favour to do the work 16:01:21 ack oliver 16:01:45 oliver: as one of the contributors to the rubric do, I believe it's useful as it has education in it, but as it is currently written i feel like certain types of methods might be discouraged 16:02:09 ... to my surprise, not necessarily those who are supposed to be.. the ones more decentralised.. im generally okay with having it, but if we do so i suggest we don't include a full evaluation of each did method 16:02:14 ... the evaluation is always very subjective 16:02:18 +1 oliver 16:02:22 +1 to not include an evaluation, other than some simple examples 16:02:22 ... we might even ask the method authors if they feel okay with the current evaluation 16:02:23 ack Orie 16:02:28 q? 16:02:51 Orie: i'm one of the authors of one of those PII DID methods. It's very helpful to have DID methods that have certain characteristics that we might consider to be 'bad' from a privacy perspective, but might be good from a public reputation perspect 16:02:59 ... it helps provide clarity on the advantages of all the other DID methods 16:03:08 ack ChristopherA 16:03:11 ... I'm a big fan of having the rubric and committing the work to describing the differences between these things 16:03:18 ChristopherA: i have mixed feelings 16:03:23 +1 to Orie's point about using the Rubric to describe many different kinds of DID methods 16:03:24 ... I like the work that was done in the CCG and elsewhere 16:03:29 ... IIW and RWOT on the rubric 16:03:44 ... but there have been several people already on this call that have said oh it'd be useful to help choose between methods or to filter methods or to eliminate methods 16:03:47 q+ to mention challenges with the RWOT paper: only decentralization and differing opinions 16:03:50 ... and that i think is exactly part of the problem 16:04:02 ... the intent, especially moving to the language of rubric, wasn't that we would make any decisions about that type of stuff 16:04:05 ... it was up to the implementers 16:04:08 ... i'm concerned about it 16:04:30 ... my question is is there a substitute now that we've gone through the exercise of ther rubric to take what we learned and do a note on decentralisation, not on how to evaluatte methods? 16:04:36 +q to ask, what if we put the differing opinions into the rubric doc itself? 16:04:42 ... i'm kind of leaning in that direction rather than the rubric as much as i like the rubric 16:04:44 ack JoeAndrieu 16:04:44 JoeAndrieu, you wanted to mention challenges with the RWOT paper: only decentralization and differing opinions 16:04:58 JoeAndrieu: some people may not know we're basicaly done with the rebooting paper 16:05:04 ... amy has volunteered to help us turn that into respec 16:05:09 zakim, close the queue 16:05:09 ok, burn, the speaker queue is closed 16:05:09 ... we're going to have a proposal for consideration 16:05:12 q? 16:05:19 ... i want to touch on some of the challenges we had, they have not gone away 16:05:44 ... i second oliver's observation. we have to provide examples, it was almost impossible amongs the authors to really understand some of the descriptions without concrete examples, but we shouldn't use all methods across all examples 16:06:02 ... the fundamental problems were about, 1 it is not the kind of thing that has been asked for from wayne, it does not address privacy and security 16:06:06 ... it's only decentralisation 16:06:15 centralization => less privacy :) 16:06:18 ... lots of people want to use it to evalute which method, but the current work doesn't really address all of that 16:06:28 ... it's going to be hard to figure out how we deal with the boundary of what's decentralization and not 16:06:31 ack dmitriz 16:06:32 dmitriz, you wanted to ask, what if we put the differing opinions into the rubric doc itself? 16:06:35 ... given that balance, i think we should do something, but still a lot of work 16:06:36 single point of correlation. 16:07:08 dmitriz: before when the did methods registry still belonged to the CCG i would have said this is a document to help people make sense of the did method registry. I agree with ivan, we have produced too many and we're confused about which ones do what 16:07:18 ... now that the responsibility for did registries is passed to the WG we should probably do this document here 16:07:34 ... because if we don't we will have failed in marketing an dpublicising DIDs if peopel see 60+ methods 16:08:02 ... Also, what if we explicitly put the differning opinions illustratively into the rubric? to help people.. it's like when you're reading product reviews, you look for 5* and 0* to help understand both sides 16:08:07 zakim, open the queue 16:08:07 ok, burn, the speaker queue is open 16:08:19 burn: what i heard as chair is sufficient interest in creating a document 16:08:21 ... it may be the rubric or a successor 16:08:32 ... we are not required to state in advance exactly what a note must be, we can publish a note on anything we wish at any time 16:08:42 ... i've heard enough support for creating a document, the contents people disagree, that's fine, we can work on that 16:08:49 ... i'm going to declare enough interest in creaing something, people willing to work on it 16:08:59 ... the next question - what should we use as a starting point for the document 16:09:05 ... and i'd like to give JoeAndrieu first opportunity 16:09:05 yes we should have a document - specifically because of the concerns raised by the privacy community. 16:09:11 See https://github.com/w3c/did-rubric/issues/2 16:09:11 JoeAndrieu: we do have a document 16:09:15 https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu 16:09:23 ... this was a rebooting paper, 6 or so of us worked on it for the last year 16:09:27 ... it was a lot of work 16:09:30 ... it still has rough edges 16:09:44 ... part of the problem is in order to evaluate any methods you have to note things about the method that are not well documented because there are questions about governance 16:09:54 ... you may need to know internals of the organisation that created the spec which may be hard to find 16:10:03 ... that said, it's an interesting starting point because ithas been kicked around 16:10:06 ... it's not a gold standard 16:10:11 ... it has a certain maturity that would be nice to leverage 16:10:31 ... what we do need is someone else who can work with some of the continuing authors who might continue (I will) but we need someone who can break out of the mould we set with that 16:10:36 ... it needs to be broken and fixed in a constructive way 16:10:40 ... resetting a bone.. 16:10:50 burn: we can discuss some more 16:11:15 ... what i'm looking for is people who might have a concern or wants to discuss before we do a proposal 16:11:35 ... just a straw poll 16:11:38 q+ 16:11:44 ack jonathan_holt 16:11:52 jonathan_holt: it's just so hard, i've seen thi sbefore, it's huge to consume, i'd like ot ponder it 16:11:54 q+ 16:12:00 ... but it seems very much like a filtering mechanism that i'm not too fond of 16:12:03 But is it to be a rubric? 16:12:09 ... but it has some good fodder for discussion about defining mor ematerial for us to pass on 16:12:09 q+ 16:12:14 ... to external group sto educate them about the criteria 16:12:23 ack brent 16:12:26 burn: we're looking for a starting point, not approval.. it could be one word that says 'document' 16:12:39 brent: to extend the bone setting metaphor.. when a doctor sets a bone he knows approximately what shape the arm should be 16:12:49 ... do we have some sort of idea what shape the final doc ought to be? 16:12:53 ... that's the hold up for me personally 16:13:06 ... i agree there's a lot of great information in the rubric and a lot of work has gone into making it, it could be a great starting point 16:13:13 q+ to suggest the distinction 16:13:14 ... but do those who want to continue have som eidea of where they want to go with it 16:13:26 burn: this should be open discussion now, 17 minutes left, will be looking for resolution 16:13:30 ack agropper 16:13:33 ... the goal now is to see whether we can get to a starting point 16:13:40 agropper: i'm pondering on joe's point about the governance issues 16:13:58 ... i think, i am willing to help work on this doc, i think it's value will be to the extent that it does highlight or educate about the governance of different methods 16:14:01 q+ 16:14:16 ... if the main reason is to help people navigate through the 60 methods, i would say that governance is one of the most important things that would have to deal with 16:14:19 ack JoeAndrieu 16:14:19 JoeAndrieu, you wanted to suggest the distinction 16:14:41 q+ to note that we have two options on the table right now, a document that has had a significant amount of work put into it and not doing the work. However, seems folks want something other than this document - a Q/A process/flow that helps you pick a set of DID Methods. 16:14:46 JoeAndrieu: i'd like to put before the group as we choose how to move forward, responding to brent, do we know what the doucment shape should be - seems there's an important choice and we need to make it as we come into this work 16:15:00 q+ 16:15:05 ... is it going to be just decentralisation as the current rubric is? or do we want to include sections for security and privacy and have it be a rubric for the evaluation of DID methods 16:15:11 ... broader, more work, but it seems like what people are asking for 16:15:13 ack burn 16:15:18 ... quite a different shape if we add security and privacy 16:15:33 burn: i don't care which direction we go. my only concern is i've seen group want to agree on all of the details before they begin 16:15:56 +1 to burn.... we need to agree to do the work and put people in charge of moving stuff forward... not solve the problem today. 16:16:05 q+ to mention third party enablement 16:16:09 ack manu 16:16:09 manu, you wanted to note that we have two options on the table right now, a document that has had a significant amount of work put into it and not doing the work. However, seems 16:16:12 ... folks want something other than this document - a Q/A process/flow that helps you pick a set of DID Methods. 16:16:19 burn: ... will be looking for. 16:16:35 manu: at this point we have a document that has been worked on for a year on and off and what i see as a very good starting point fo ra variety of the things we've discussed 16:16:38 ... that's option 1 16:16:42 ... option 2 is let's just not do the work 16:16:52 ... enough people weant to see something happen here that let's not do the work would probably result in people objecting 16:16:57 that matches my understanding of the options as well 16:16:58 ... it really feels like we have one workable option 16:17:08 q? 16:17:13 ... someone can always prpose they're going to go off this week and write something but i struggle to see how it would have the amount of thought and content 16:17:21 ... so +1 to take the work alreadyd one and transition that into the first editors draft 16:17:31 ... as far as a starting point, I don't see any other workable option 16:17:44 ... the second thing, it feels like what the document is today and what peopel are asking for are fairly different 16:18:03 ... i think there's enough raw content in the document we have to get to what folks are asking for but it reallyseems like.. we've heard a number of people say i would lik esomething that will help me pick a did method 16:18:13 ... i think the documen as it stands today is mor ea list of questions you should ask yourself 16:18:19 ... it may not give you the type of clarity that people want 16:18:28 s/documen/document 16:18:44 s/mor ea/more a 16:18:50 ... having been involved in writing these flow charts to help people pick somehing, usually waht people want is a nice guided tour of 60 options and when they get to the end of the flowchart tour, do you awnt this or that, is this or that important, you whittle down from 60 choices to 3 16:18:55 ... fundamentally that's what people really want 16:19:03 ... they don't want to read a giant document 16:19:10 ... the actual desired work item is a help me pick a did method work item 16:19:12 q? 16:19:18 ... not these are all the ways things could be viewed as decentralised or not 16:19:51 ack ivan 16:20:04 ivan: my answer is yes, whether security and privacy should be addressed 16:20:15 ... as far as i can see, of course decentralisation is a central feature, but so is security and privacy 16:20:19 ack chriswinc 16:20:19 chriswinc, you wanted to mention third party enablement 16:20:21 can we interpret +1 as start with the doc, and -1 as lets not do the work? 16:20:29 chriswinc: i would support using this doc as a starting point 16:20:33 ... and the expansion as ivan said 16:20:47 +1 to starting with this submission and +1 to adding discussion of privacy and security 16:20:50 +1 using the rubrics doc as a starting point 16:20:58 ... i do think our role in this, all of us are way too close to this. what we should be doing is explaining how did methods work from a tehcnical standpoint so third parties can evalute what works for them 16:21:02 +1 16:21:03 ... i don't think we should be enabling evaluations 16:21:26 PROPOSED: Use https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu as a starting point for a document intended to become a WG NOTE. 16:21:29 +1 16:21:30 +1 16:21:31 +1 16:21:31 +1 16:21:33 +1 16:21:33 +1 16:21:33 +1 16:21:33 +1 16:21:34 +1 16:21:35 +1 16:21:35 +1 16:21:38 burn: 0 won't have an effect, -1 means we won't use this a starting point 16:21:39 +1 16:21:41 +1 16:21:41 +1 16:21:42 +1 16:21:54 0 my concern that the true meaning of Rubric is "A statement of purpose or function" as in how a church service should be conducted. but the direction here is a set of criteria to judge that church service 16:21:58 burn: i'm going to call it 16:22:22 RESOLVED: Use https://docs.google.com/document/d/1rYdWiwawWmLOWtHRvT0GzYcdewW_OS9M2mAkENLFdtY/edit?pli=1#heading=h.4p260dq0jbu as a starting point for a document intended to become a WG NOTE. 16:22:28 ... markng resolved, the did spec we have today is definitely not the same as what we started with 16:22:31 ... the work can begin 16:22:50 ... joe, the chairs would like to talk with you about how to get started 16:23:12 Add me. 16:23:13 can I nominate daniel buchner from ms? 16:23:14 ... if ther'es someone else who is willing to commit a lot of time on this as a potential editor, please drop your name in irc or contact us directly and we'll get that started 16:23:19 agropper willing to edit 16:23:43 paulm has joined #did 16:23:44 TOPIC: implementation guide 16:24:17 q? 16:24:18 drummond: another one of our deliverables 16:24:27 q+ 16:24:35 ... markus and i were trying to figure out, we couldn't remember when we decided to add it and does anyone remember when we made the decision to do this? 16:25:04 markus_sabadello: i remembered it, we created the implementation guide repo about 2 weeks after amsterdam f2f because during that meeting we had lots of dicsussions about toipcs that don't fit into the core spec 16:25:14 ... topics around immutability of objects, identifiers for keys, thing slike that 16:25:35 ack markus_sabadello 16:26:01 drummond: more recently as we were crafting and taking early parts of the did spec from the CCG, there were certain sections where we said that won't belong in a final w3c spec like the future work section, so we moved that to th eimplementation guide 16:26:03 ... manu did that 16:26:13 ... we definitely do feel that it is a good place for best practices 16:26:24 ... at least, whatever our learnings are at the time we are done with did core and the registries 16:26:29 ... so we just listed a set of bullets 16:26:45 ... some very specific advice that we want to be able to provide to did method spec authors who are direct audience of the did spec 16:27:07 ... and implementers of resolvers, to extend verifiable data registries.s hould not touch on the rubric except to point to that. and appication developers, general use of dids 16:27:12 ... that's what we felt it's for 16:27:23 ... we still have a fair number of questions about what else might go in there 16:27:31 ... we thought we'd start by sharing what's in there now 16:27:53 markus_sabadello: over time there have been many ideas and comments on gh issues and prs to discuss or suggest what kind of topics could go into it 16:28:09 ... quite a few issues on the did core spec where the impemenation guide has been mentioned as a potentail place for certain issues to be addressed 16:28:14 ... in practice we don't have much 16:28:21 ... two topics that manu moved from the did core spec to the implementation guide 16:28:27 ... some content about the use of jsonld 16:28:53 ... the implemenation guide talks about some specific jsonld features, jsonld 1.1 feature,s how to use them, what to watch out for as an implementer, how to extend it and use contexts etc 16:29:05 ... the second item is the future work section which used to be in did core 16:29:19 ... things like equivalence, or use of vcs, did doc recovery 16:29:39 ... one thing i did was search the issues and prs on did core spec where implementation guide had been suggested 16:29:44 ... it has been a frequent pattern 16:30:10 ... we discuss topics and there may be an insight that the topic should not result in content for the core spec but is more suitable for the implementation guide 16:30:14 ... about ten issues 16:30:18 ... just a plain text search 16:30:38 ... here's one example 16:31:04 ... a few months ago an issue was raised on the core spec to suggest we discuss the relationship between DIDs and eIDAS, an EU framework for traditional state issued identity infrastructure 16:31:11 ... some ongonig efforts and initiatives to align with DIDs 16:31:18 ... someone raised an issue suggesting we should cover that topic 16:31:34 ... i think in the course of the discussion we had a better understanding of what type of content shoudl go into which document 16:31:57 ... my feeling was the did core spec would not be a place where we discuss identity frameworks, and there are many, how dids would be implemented and aligned with some of these 16:32:11 ... not for the core spec, but something that could fit into the implementation guide, and also the use cases or to a smaller degree into the did core spec 16:32:20 ... there is a proposal how this very broad topic could be split up 16:32:28 ... there could be some smalle rimprovements or updates to DID core 16:32:36 ... the main content to address this would go into use cases to describe what is it for 16:32:40 ... and why are some politicals working on that 16:32:50 ... and then th eimplementation guide would be a place for describing how that is done on the technical level 16:33:11 ... there are some concrete imlemenations or gateway initiatives, actual code has been written to align dids with this identity framework so i think this would be a good thing for the implementation guide 16:33:15 ... this is just one examaple 16:34:17 drummond: we wantthis to be a question to discuss - what other types of content seem like they could be good candidates 16:34:30 ... the topic of all the way syou can use, good guidenceto provide around dids and did docs coudl be very broad 16:34:40 ... all the questions around how they relate to decentralised pki relates to convential pki 16:34:51 ... very deep topic around proof of control 16:34:56 ... security of dids 16:35:14 markus_sabadello: a topic daniel hardman suggested 16:35:45 ... service endpoints and verification methods inside the did doc, many discussions on how these ids are generated or designed and should be immutable or not 16:36:04 ... when you change your key, update it in the did doc, you rotate it, does the new key still have the same id value as the old key? or does it change every time you change the key? 16:36:34 ... at some point we said the did core spec would not mandate how you generate those ids, but there are good practices and security ocnsiderations, could also be one topic, identifiers of keys and other things inside the did doc 16:36:46 drummond: some of these you can look at like whole docs or notes themselves about them 16:37:03 ... for shorter things we could have a section of the doc that is an faq, there are a lot of common questions about dids 16:37:32 ... eidas is a subset of the question of dids and how they relate to national id programs, that's a topic i'm talking about every day 16:37:53 ... another area that has a lot of attention is activitypub, federated social web and all that 16:37:56 q+ on relationships with the use case document's examples 16:37:56 ... a lot we could cover 16:38:08 ... part of what we should get feedback on is what is most appropriate and what is highest priority 16:38:27 ... and an open question about timing 16:38:54 ... volunteers for editors? and encourage PRs 16:39:17 ... main quesiton is to ask for feedback about what folks feel should be the main thrust of the guide if there is one 16:39:20 ... and ideas for content people have 16:39:23 q? 16:39:28 q+ 16:39:30 q+ 16:39:37 ack ivan 16:39:37 ivan, you wanted to comment on relationships with the use case document's examples 16:39:40 q+ 16:39:41 link to repo? 16:39:50 ack jonathan_holt 16:39:53 q+ ivan 16:40:14 jonathan_holt: cbor is missing, i'd be happy to contribute, now i really understand cbor and cddl and have working code to do it i should contribute 16:40:16 drummond: fabulous 16:40:23 ... it would fit right alongside the section on jsonld 16:40:27 q- later 16:40:37 ... maybe if the plain json folks it would be good to have a subsection of the document about specific representations 16:40:37 ack kdenhartog 16:40:47 q+ to note don't do a new DID Method comment from dmitriz 16:41:14 kdenhartog: one thing i've noticed tribal knowledge about the relationshp between controllers, subjects and delegates. a lot of nuance and edge caes around that we can't really put in the core spec 16:41:19 ... curiosu if this is the right place to do that 16:41:23 drummond: that's another great topic 16:41:40 ... the core definitions need to be in the core spec, but some of the more advanced questions about how those things might be put together belong here 16:41:44 ack ivan 16:41:55 ivan: you had a slide on the relationship with eidas, triggered a more general thing 16:42:01 q+ 16:42:02 ... maybe worth creating bridges with the uses cases 16:42:29 ... use cases with implementation may not be that obvious. in the implementation guide give examples of the most important use cases, a realisation of how that use case can be done by this and this type of DIDs 16:42:32 drummond: great idea 16:42:32 ack manu 16:42:32 manu, you wanted to note don't do a new DID Method comment from dmitriz 16:42:41 manu: to speak to the question around priorities 16:42:49 ... i wanted to draw attention to something dmitri said in chat, which was great 16:43:05 ... half joking.. which is talking people out of doing things in the implementation guide, if you are seriously considering doing a did method pelase take a look at the ones that exist already 16:43:18 ... another one might be if you're tihnking of creatin gnew types of crypto suites, really understand why you're doing it 16:43:23 ... because the world may not need yet another one 16:43:35 +1 to manu's comments 16:43:36 q+ 16:43:37 ... it's general guidence on please don't do these things that are harmful to the community, well intentioned but harmful 16:43:49 ... and having a section on specifically not doing things, avoid tdoing these things, would be useful 16:43:55 I strongly agree with Manu's points -- the "PLEASE DON'T DO" section 16:43:59 drummond: i agree so much 16:44:11 ack markus_sabadello 16:44:27 markus_sabadello: i had the same thought as ivan, there could be a relatioship between the use cases and this one 16:44:30 +1 to "antipatterns" 16:44:40 ... ideall we have someone contribuign the use case and how they implemented it 16:44:51 drummond: this is perfect, the implementation guide is now a book published by o'reilly.. 16:44:56 ack kdenhartog 16:45:10 yes! 16:45:10 kdenhartog: is this a place to talk about how to define an extension? 16:45:14 drummond: what a great question 16:45:15 great question, kdenhartog 16:45:17 .... :( 16:45:31 ... my reaction, better in the did registries, but i'm curious 16:45:35 +1 to drummond... lets centralize extensions in 1 place 16:45:38 q? 16:45:53 Orie: i would prefer to put as much guidence on extensions in one doc as possible and link to that single place 16:45:58 ... from any docs that might have related topics 16:46:03 q? 16:46:23 drummond: certainly that we would want to point out the general need or pattern of use of spec registries for extensions, go look there for instructions 16:46:58 Orie: yeah, here's the spec registries, here are properties in the core context, here are properties defined elsewhere, in the implementation guide if you believe you need to extend the core data model go over here ot the regsitries and if you want your extension to be interoperable you'll have to conform to the mechanism 16:47:11 drummond: actual instructions on how to register an extension, in the spec registries document? 16:47:18 q+ on difference between adding vs. creating. 16:47:21 Orie: if there is not a section that explains how to do that, it's almost useless 16:47:24 thanks makes sense to me 16:47:24 ack manu 16:47:24 manu, you wanted to comment on difference between adding vs. creating. 16:47:38 manu: just to clarify orie, i wa snot entirely clear on what you were suggesting. i think there's a nuance that kyle might be getting at 16:47:47 ... adding something to the registry is one thing, creating an extension is something else 16:48:04 ... instructions for adding should clearly be in the registries. the process a developer would og through to create an extension might be better placed in the implementation guide 16:48:14 ... it could also go in the spec registries document.. but that would be a fairly nonstandard way to do this.. 16:48:23 ... typically spec registries don't have instructins on how you write extensions 16:48:35 ... the question si the process of creating an extension, do we document it in core, implementation guide or spec registries 16:48:39 +1 to extension process in core for core registries 16:48:42 q? 16:48:47 +1 to did core 16:49:06 burn: i'm going to speak to that to say if you look at ietf docs, yeah your spec needs to define the process for registering new entries 16:49:08 ... for the core spec 16:49:17 ... where it gets interesting is we've combined a variety of things into this did registries 16:49:39 ... there may be some things that are not really defined by the core spec that maybe belong somewhere else, but normall you puti t in your normative document 16:49:50 +1 for process in normative document, IETF requires "IANA Considerations" sections 16:49:55 burn: any other comments? 16:50:06 ... what i want now is people to commit to editing this document 16:50:09 ... contributing this document 16:50:12 ... so we can get it done 16:50:33 drummond: as folks contemplate that.. in terms of timing.. would it be safe to assume that the priorit should be for folks who do want to contribute 16:50:37 ... feature freeze on did core? 16:50:39 burn: yes 16:50:42 ^ yes, to be clear... I would prefer the process of defining extensions in the normative document.... agree strongly with justin. 16:50:49 yes, please, feature freeze on DID Core is Priority #1 :) 16:51:05 drummond: let's make sure we get did core done and any essential things there or in registries, then a lot more of us as that happens will be able to start fleshing this out 16:51:18 ... another question, a document like this, what is the actual status of an implementation guide? 16:51:20 burn: it's a note 16:51:30 .... there will not be normative language. you can write hwatever you want 16:51:33 ... the entire doc is informative 16:51:49 drummond: when should we be really saying we need to have it really ready for final proofing 16:52:17 burn: the answer i'm going to give is i suspect as we require and encourage more reviews of our core spec we are going to get questions for whom the answers are in the implementation guide, or should be 16:52:21 ... it's tempting to wait until the end 16:52:33 ... but if it ends up being a blocker for getting our review work done on the spec we need to put earlier effort into it 16:52:42 ... otherwise the only deadline for it is the WG's completion in september of next year 16:52:56 ... we need implemenations, that's part of the process 16:53:08 ... if your'e hoping people will look at the implemenation guide when theyr'e building, it's good to have something there 16:53:27 ... in the VC case, we had concerns people raised they wante dot make sure they were written somewhere, they were not comfortable with the spec being done without text in the guide 16:53:38 ... even though it's not normative, the group members wanted to see it before they would say yes to the spec 16:53:45 ... that's why i'm going to encourage this work to get going after feature freeze 16:53:47 ... don't wait 16:53:54 ... the next step after feature feeze is CR, which means implemenations 16:53:56 +1 to not waiting 16:53:59 ... the implementation guide will be relevant to that i hope 16:54:03 drummond: makes sense 16:54:24 ... everything we put in to guide implemenations during CR, and the revisions we make after we learend that much more from the immplementations 16:54:26 burn: sure 16:54:30 ... anything else on this? 16:54:54 ... thanks drummond and markus for putting this together 16:55:04 TOPIC: features at risk, CBOR and JSON 16:56:04 manu: let's start off by talking about what they are 16:56:19 ... for some of the people in thsi group, it might be your first time through, so we'll establish what a feature at risk is 16:56:25 ... we usually start talking about it when we get close to candidate rec phase 16:57:02 ... the main reason we do this is as dan mentioned if we change anything substantial in the CR phase, if we change normative statements that affect an implementation, if we add normative text, if we make any change that changes an implementation we may have to go through another CR publication process, it takes time 16:57:06 ... it's expensiv ewhen we're in CR 16:57:17 ... what most groups try to do is protec themselves when they go through CR 16:57:28 ... the main tool they use to do this is 'feature at risk' 16:57:43 ... this is a provison the w3c process provides when you mark something as a feature at risk, you're signalling to implementers 16:57:57 ... that this thing could change, keep your eye on it, we may change it in a significant way or remove it completely 16:58:05 ... by marking at as such then you don't have to go through a new CR phase if you end up changing that feature 16:58:09 q+ My big question on CBOR, I want it, but does it put us at mercy of registering CBORE tags with IETF? 16:58:18 q? 16:58:23 ... you can abuse this an dmark th eentire spec as at risk, clearly you have to be very precise on the sectios or features you are marking as at risk 16:58:25 q+ to ask big question on CBOR, I want it, but does it put us at mercy of registering CBORE tags with IETF? 16:58:32 ... so it's something you expect is going to change and you don't want to that to affect your ability to go to PR 16:58:35 ... any questions? 16:58:37 ack ChristopherA 16:58:37 ChristopherA, you wanted to ask big question on CBOR, I want it, but does it put us at mercy of registering CBORE tags with IETF? 16:59:22 ChristopherA: do we need to register tags at ietf because they're the org that registers cbor tags? 16:59:25 manu: good question 16:59:35 ... cbor is a topic of discussion in this hour, we'll cover it later 16:59:49 ... a fundamental things we have to figure out 16:59:56 (I've been puzzling through CBOR crypto tags at https://github.com/BlockchainCommons/Research) 17:00:05 q? 17:00:28 manu: there are a variety of reasons why you'd want to mark something as at risk 17:00:38 ... if you think a feature will get less than two implementations you should mark it at risk 17:00:44 ... if you expect there to be a normative change 17:00:52 ... there's a talbe of normative values that may change based on implementation experience 17:01:10 ... if there is a feature that youf eel is not thoroughly documented. we don't like to go into CR with features that still need work or are not thoroughly documented 17:01:22 ... but sometimes groups do this, espeically for rough features that appear a couple of weeks before CR 17:01:33 ... usually you want to mark those as at risk because the group doesn't have enough experience to kno wwhether it's going to change 17:01:43 ... the other thing that may trigger it is you've got multiple people implementing things 17:01:53 ... you're getting signals that there's not actual interop 17:02:13 ... you have to be careful about even if you have independant implementations you have to look to see if things are shaky 17:02:36 ... there are also looming formal objections, if you get one during CR marking something as at risk allows you to remove the feature to adddress the objection 17:02:54 ... or feeling sthat a section isn't great, or this section is giving me heartburn... usually not a good reason, but it's very much a judgement call 17:03:03 ... the gropu needs to figure out which tiems to mark as at risk before we go into CR 17:03:13 ... there are around 5 areas of at risk concerns in the spec today 17:03:24 ... i'm going to go through them and introduce them, and then talk about way swe could mitigate these at risk concerns 17:03:49 burn: in yoru position as editor that you believe that as these items currently are they would need to be marked as at risk if they remain the way they are today? 17:03:50 manu: that is correct 17:04:02 ... not representing anything other than editor of the spec 17:04:19 ... So, there was quite a bit of work on json only did docs 17:04:32 ... concern around ensuring the jsonld community as not pushing jsonld things onto the json only community 17:04:39 ... there has to be a representation of a did doc that does not require jsonld 17:04:58 ... we'll get into why this may be at risk, but at present we don't know of two independent implementations of DID methods that are json only 17:05:03 ... meaning they don't use any of the jsonld stuff 17:05:12 ... that coupled with the lack of contributions to the did spec registries for the json schema work 17:05:15 ... and other items like that 17:05:25 ... have raised concerns around which organisations are going to produce a json only representation 17:05:47 ... it's not we're thinking of doing it, or we will if we have time, it's this is the main mode of operation for our did method and we will be providing something during CR - looking for a signal like that and haven't seen something like that yet 17:05:58 ... still plenty of time, but if we dont' see something like that soon we may have to mark the json only stuff as at riks 17:06:04 ... the same thing applies to CBOR only did docs 17:06:11 ... at present we only know of one implemente,r one implementation 17:06:15 ... the text is a bit rough 17:06:19 ... it does point to ipfs style things 17:06:26 ... but there are also concerns around that second implementation 17:06:28 s/riks/risk/ 17:06:33 ... no additions to the test suite, to the did spec registries 17:06:37 q+ to ask about the test suite 17:06:44 ... there's a significant amount of work tha twould need to be done for us to keep the cbor only bit in the spec 17:06:57 ... i forgot to mention for json only, we're also looking for people to submit json only tests to the test suite 17:07:08 ... you need to run the tests to do the json only stuff, we need someone to step up and write those tests as well 17:07:18 q? 17:07:45 ... oliver mentioned a couple of items and adrian - the concept of gdpr and other privacy implications on services exposed via the services parameter 17:07:58 q+ 17:07:59 ... question on whether services are a good idea from a privacy perspective or if we should figure out a different way 17:07:59 q+ 17:08:03 ack justin_r 17:08:03 justin_r, you wanted to ask about the test suite 17:08:38 justin_r: about the test suite and counting implementatons, towards the tailend of finalising VCs ?? was counted as one of the implementations to remove things from being as at risk 17:08:46 q+ 17:08:47 ... will that happen here as well or are we looking to avoid that? 17:08:50 ack markus_sabadello 17:08:59 q+ to note maybe we didn't count test suite as implementation? 17:09:04 markus_sabadello: i think that services topic is not so recent, it's comeup several times in the past 17:09:23 ack kdenhartog 17:09:23 ... that th edid doc should not contain services has come up 17:09:28 q+ 17:09:36 q+ 17:09:38 kdenhartog: if we did remove it is it possible it could be defined as an extension? 17:09:39 ack manu 17:09:39 manu, you wanted to note maybe we didn't count test suite as implementation? 17:09:41 manu: short answer yes 17:09:59 ... justin, i can't remember us counting the test suite as an implementation in the vc work 17:10:05 we did count it for several things, that wasn't part of the question but ok 17:10:09 ... i think they were all independant implementations. i don't think we did that there 17:10:11 q+ to ask about my original question on IEFT sync for CBOR 17:10:20 ... we'll have to consider that here 17:10:25 The Services topic was being discussed in Hallway: https://zoom.us/j/91515310373?pwd=WVF0T1Jrc0Nwazl3TUZhYU85dUEyZz09 at the last break and maybe can continue tomorrow. 17:10:29 to my recollection, we did not include the test suite as an implementation in the VCWG 17:10:35 manu no I am not asking on anything in particular, please don't speculate 17:10:44 ... i think you may be asking around the resolution stuff, i think there's a clear path forward meaning we wouldn't have to count that stuff as an implementation for it to stick 17:10:55 ... the VC test sutie did not count itself as an implementation, we used other implementations 17:11:05 ack oliver 17:11:08 burn: that would be a no-no for that officially to happen 17:11:30 oliver: if did-method critical features are not getting into core context easily, there would be less concerns with keeping it jsonld only 17:11:37 +1 to what oliver is saying... 17:11:42 ... if json gets dropped and things like ethereumAddress are not added I'd consider formal objection to the spec 17:11:46 ack jonathan_holt 17:12:10 jonathan_holt: i haven't seen any feedback or issues filed or prs against it or comments, i have been waiting to have dialoge, maybe we can have some time to discuss that 17:12:12 q+ 17:12:21 post the PR url? 17:12:24 ... it was just submitted a few weeks ago, i spent a lot of time on it, but it's brewing form a year and a half ago 17:12:41 ... i think it's relatively solid 17:12:55 ... to comment as far as implemenations, underlying th eimplemenation of cbor i'm most familiar with is dag cbor which ipfs uses 17:13:23 ... there are other implementers who use this particular method, ipid, in one line to publish the did doc into cbor 17:13:26 ... i can document those libraries 17:13:27 q+ to note that "feature at risk" isn't picking on anyone, even though it might feel that way, it's just a -- we need work to be done here, people need to do the work. 17:13:30 ... and how to do that 17:13:43 ... chicken and egg 17:13:56 ... you have to have two separate implemenations.. or two to use your did method? 17:13:57 q+ 17:13:59 ack ChristopherA 17:14:00 ChristopherA, you wanted to ask about my original question on IEFT sync for CBOR 17:14:13 two different implementers who use CBOR 17:14:19 ChristopherA: i'm confused on a couple of different areas 17:14:48 ... when people use cbor that is straight conformant in the ietf but not the ?? specification for the DID doc 17:15:06 q+ on the meaning of 'cbor/json only' 17:15:30 scribe+ 17:15:35 ChristopherA: 3 parts to my question: 17:15:51 ChristopherA: 1. the relationship with other organizations (having to register with IETF) 17:16:05 ChristopherA: 2. what is the relationship with how much we have to do with a method, vs. what needs to be done in the DID spec 17:16:34 ChristopherA: for example, if i can take any conformant JSON-LD doc and convert it to CBOR, do i even care if the DID spec allows for CBOR? 17:17:09 ack kdenhartog 17:17:11 ChristopherA: 3. did we say we may have to conform with protocols labs things? they are neither a standards organization nor a standards implementation organization 17:17:41 q+ to non-abstract representation. 17:17:41 kdenhartog: The simple way to address this may be to ignore.. Let's say JSON and CBOR are both dropped, and we only have JSON-LD, does this mean we go back to only a single concrete representation? 17:17:56 To be clear, my use cases use QR codes, that is one of the reasons why use use CBOR. See https://github.com/BlockchainCommons/Research 17:17:58 kdenhartog: or... even if the features get dropped, do we still stick with the abstract representation? 17:17:58 ack manu 17:17:58 manu, you wanted to note that "feature at risk" isn't picking on anyone, even though it might feel that way, it's just a -- we need work to be done here, people need to do the 17:18:01 ... work. and to non-abstract representation. 17:18:24 manu: i wanted to address the meta-concerns i am hearing. as an editor, i think it would be a very bad idea to drop JSON and CBOR 17:18:30 well... JSON-LD is JSON... its a stricter subset of JSON.... and to answer kyle's question... yes, you could create a bi-directional map[ing between JSON-LD and CBOR / JSON on your own.... 17:18:31 +1 17:18:37 +1 to doing work. manu is pointing out that the answer cannot be "someone (else) needs to do something" 17:18:51 brent: two different did methods that use CBOR? 17:19:00 manu: but the reason why we are highlighting these things.. we are saying that unless people step forward and do the work to demonstrate interopearbility between implementations, we are not going to be able to keep the features int he spec 17:19:14 manu: this is about people stepping forward doing the work, this is not one sub community attacking another sub community 17:19:39 manu: we are saying, we really need help, especially from the people who want to see the features, so we are able to safely defend the features 17:19:43 q? 17:19:50 manu: so my hope is that dropping features is hypothetical 17:19:56 q+ 17:20:02 manu: the JSON one feels easier than the CBOR one 17:20:22 manu: i don't think this is realistic, but if JSON and CBOR are removed, my expectation is that the abstract representation will remain as it is 17:20:32 +1 to manu on keeping the door open in any case 17:20:36 q+ 17:20:36 manu: we always want to keep the door open for future additional representations 17:20:40 q+ to ask what CBOR only is, vs CBOR that can round-trip with JSON-LD. 17:20:43 +1 to keeping the door open 17:20:55 +1 17:21:05 manu: i think it would be very disruptive if we removed the ability to add representations 17:21:08 +1 for keeping door open 17:21:13 +1 to keeping the door open... 17:21:20 ack drummond 17:21:27 burn: there is no decision to make here, manu just pointed out the situation 17:21:47 drummond: i wanted to second what manu said. i know that there is work ongoing. 17:21:48 zakim, close the queue 17:21:48 ok, burn, the speaker queue is closed 17:21:59 drummond: i've heard several times the notion that there is not a DID method that supports that 17:22:08 drummond: representations are completely orthogonal to DID methods 17:22:19 drummond: a DID method that only works with one representation would be an anti-pattern 17:22:28 ack ivan 17:22:28 ivan, you wanted to comment on the meaning of 'cbor/json only' 17:22:37 drummond: you may present examples using one type, but methods should not be limited to one representation 17:22:51 ivan: i agree with drummond. the "JSON only" and "CBOR only" terminology is misleading 17:23:03 did methods need to support representations, in order for them to be testable... you can't test normative statements about a representation that has no method implementations! 17:23:09 ivan: if we have DID methods supporting multiple representations, we will be fine 17:23:23 ivan: the requirement is that DID document e.g. in CBOR are interchangable among implementations 17:23:30 ack kdenhartog 17:23:33 q+ to get to mitigations 17:23:37 dlehn has joined #did 17:24:11 kdenhartog: realistically, we don't want that to happen. the way we have implemented it is that we use JSON-LD, but we don't use JSON-LD tooling. we do it with standard JSON processing (we're using typescript) 17:24:19 +1 to kyles point... we also use JSON-LD and TypeScript... 17:24:35 kdenhartog: it feels weird to say "JSON only" because we're processing JSON-LD with standard JSON tools 17:24:39 ack jonathan_holt 17:25:05 I can take that conversation offline as well to figure that out 17:25:12 jonathan_holt: my DID method IPID supports DAG CBOR natively but it can be serialized to JSON 17:25:18 jonathan_holt: it supports CBOR LD too 17:25:38 jonathan_holt: if i were to have a second implementation, e.g. i fork indy and i add CBOR, is that sufficient? 17:25:46 ack ChristopherA 17:25:46 ChristopherA, you wanted to ask what CBOR only is, vs CBOR that can round-trip with JSON-LD. 17:25:49 manu: no, because it has to be independent 17:26:11 ChristopherA: when i heard "CBOR only", i thought it was a "linked-data-less" version 17:26:33 ChristopherA: which of that are we proposing to do 17:26:38 we do not have CBOR-LD ad the moment, ChristopherA 17:27:02 manu: possible mitigations: 17:27:15 manu: if we are concerned about JSON-only DID document, we need to see two independent implementations 17:27:19 manu: same for CBOR 17:27:33 manu: for the services topic, we can mark as risk 17:27:48 For those wondering what "Linked Data" is, and why you might want your did document to be represented as linked data: https://en.wikipedia.org/wiki/Linked_data 17:27:49 manu: for the publicKey topic, we seem to have agreement to replace that with "verificationMethod" 17:28:04 manu: if we missed anything, please type it here in IRC 17:28:17 manu: also, please think of missing features 17:28:25 For safety the sections I just added may be useful to mark "at risk" 17:28:33 burn: tomorrow's call begins two hours later than this one 17:28:45 brent: thanks to the scribes, thanks everyone for coming and making this a priority 17:28:49 RRSAgent, draft minutes 17:28:49 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html ivan 17:28:51 burn: we will continue tomorrow. bye. 17:29:34 rrsagent, draft minutes 17:29:34 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html ivan 17:29:34 zakim, end meeting 17:29:34 As of this point the attendees have been ChristopherA, ivan, burn, phila, charles, chriswinc, justin_r, PaulMadsen, dirk, manu, drummond, JoeAndrieu, kdenhartog, EugeniuRusu, 17:29:37 ... brent, timcappalli, Eugeniu_Rusu, identitywoman, markus_sabadello, oliver_terbu, p, dmitriz, agropper, rhiaro, wayne, ch, Orie, jonathan_holt, selfissued 17:29:37 RRSAgent, please draft minutes 17:29:37 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html Zakim 17:29:39 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 17:29:43 Zakim has left #did 17:29:48 ch has left #did 17:32:34 rrsagent, draft minutes 17:32:34 I have made the request to generate https://www.w3.org/2020/06/30-did-minutes.html ivan 17:38:48 dlehn has joined #did 19:27:02 dlehn1 has joined #did 22:30:04 dmitriz has joined #did