14:41:26 RRSAgent has joined #did 14:41:26 logging to https://www.w3.org/2020/11/02-did-irc 14:41:29 RRSAgent, make logs Public 14:41:30 please title this meeting ("meeting: ..."), ivan 14:41:44 Meeting: DID WG (Virtual) F2F Meeting, 1st Day 14:41:44 Chair: burn, brent 14:41:44 Date: 2010-11-02 14:41:44 Agenda: https://tinyurl.com/yydapmu3 14:41:44 ivan has changed the topic to: Meeting Agenda 2020-11-02: https://tinyurl.com/yydapmu3 14:46:40 present+ 14:49:25 burn has joined #did 14:49:33 present+ 14:53:48 present+ 14:58:56 jeff has joined #did 14:59:02 present+ 14:59:55 scribejs, set jeff Jeff Jaffe 15:00:47 brent has joined #did 15:00:52 present+ 15:01:27 present+ 15:01:28 markus_sabadello has joined #did 15:01:37 Mizushima has joined #did 15:01:46 kristina has joined #did 15:01:51 justin_r has joined #did 15:01:57 present+ 15:02:14 selfissued has joined #did 15:02:19 present+ 15:02:33 present+ 15:02:39 identitywoman has joined #did 15:02:44 present+ 15:02:54 Tetsuya has joined #did 15:02:55 present+ 15:02:58 present+ 15:03:02 fujimura has joined #did 15:03:09 GeunHyung_Kim has joined #did 15:03:17 present+ 15:03:30 present+ Geunhyung_Kim 15:03:58 phila_ has joined #did 15:04:17 present+ 15:04:20 present+ Tomoaki_Mizushima 15:04:24 Slide deck: https://tinyurl.com/yyc5fu63 15:04:49 guests+ Mizushima 15:05:14 by_caballero__juan_ has joined #did 15:05:18 scribejs set Mizushima Tomoaki Mizushima 15:07:36 scribe+ 15:07:53 JoeAndrieu has joined #did 15:07:55 brent: For the agenda today... we're going to start out w/ going over CR 15:08:04 brent: or rather the process to CR and the process overall 15:08:11 present+ 15:08:27 brent: Then we're going to dive into preventing privacy violating properties... discussion around type and more. 15:08:38 brent: Please volunteer to scribe, we need scribes. 15:08:50 dmitriz_ has joined #did 15:08:50 scribe+ 15:09:21 brent: The goal of the DID WG is to standardize the DID URI scheme, data model, syntax, and information related to DIDs. 15:09:22 brent: The goal of the DID WG is to standardize the DID URI scheme, data model, syntax of DID documents 15:09:56 brent: DID Core is our recommendation-track specification 15:10:03 brent: we're hoping to get through big issues this week 15:10:40 brent: We also have Notes as deliverables (DID Use Cases, Decentralized Characteristics Rubric) 15:10:45 dmitriz_ has joined #did 15:10:49 agropper has joined #did 15:10:54 brent: Other deliverables are the registries, test suites 15:11:03 brent: Reminder: WD do not imply consensus 15:11:03 present+ 15:11:22 dmitriz_ has joined #did 15:11:27 jonathan_holt has joined #did 15:11:34 present+ jonathan_holt 15:11:42 brent: A Candidate Recommendation needs to be feature-complete, wide review, and it needs to specify implementation requirements for exiting CR 15:11:49 present+ dmitriz 15:12:01 brent: To exit CR, there must not have been substantive changes 15:12:33 brent: A Proposed Recommendation (PR) is a sanity check where hopefully nothing major happens 15:12:48 brent: Then W3C votes on making it a Recommendation 15:13:18 brent: We entered FPWD, we are working toward CR. Original goal for first CR was November this year. 15:13:38 brent: At this point it's highly unlikely we will achieve that goal. We will discuss reconfiguring our timeline 15:13:54 brent: We're not in trouble, but let's work hard. 15:14:00 identitywoman has joined #did 15:14:20 brent: We entered "feature freeze" in July (rather than May) 15:14:46 brent: We wrote December 2020 for CR1. This will give us enough time for implementation, and to see if we need a second CR by March. 15:15:04 q? 15:15:12 brent: If we can hit this timeline, then we have the time we need for implementation, review, and to reach Recommendation. 15:15:21 drummond has joined #did 15:15:30 present+ 15:16:06 brent: This meeting has 3 primary goals: 1. Get everyone on the same page what work remains for CR, 2. Resolve major outstanding issues (topics from the last few months - Abstract Data Model, and privacy concerns) 15:16:14 brent: These are the topics we really want to resolve 15:16:38 brent: We also have around 60 open issues, this is way too many. We want to resolve 25% during this F2F. 15:16:50 Topic: introductions 15:17:00 brent: I'd like to open up for introductions 15:17:36 q+ 15:17:43 brent: Everybody please introduce themselves, say something about yourself 15:18:06 ivan: When you are a guest, please write your name in IRC! 15:18:07 ack ivan 15:18:09 present+ 15:18:21 brent: ivan please introduce. 15:18:31 ivan: I am staff contact for this Working Group, it's my job to be interested. 15:18:36 brent: burn please introduce. 15:19:08 burn: I am co-chair with Brent of this Working Group, I am ED of the Enterprise Ethereum Alliance. Started working in W3C in 1999. 15:19:21 scribejs, set by_caballero__juan Juan Caballero 15:19:24 burn: Started working on DID in the early days, it's a real joy to see things move forward. 15:19:28 self-introduction: i am juan caballero, researcher, here on behalf of Spruce ID. not active on github so will try to take up as little time as possible. 15:19:35 brent: jeff please introduce. 15:19:43 guests+ by_caballero__juan_ 15:19:50 jyrossi has joined #did 15:19:59 present+ 15:20:00 present+ 15:20:04 jeff: I am CEO at W3C. I'm just here to observe. 15:20:17 by_caballero__juan_: I'm just here as a guest se well, just observing. 15:20:54 phila_: Phil Archer from GS1, we do the barcodes, very involved in supply chain industries. We're very interested in DIDs and VCs to support this process. 15:22:06 agropper: Adrian Gropper, invited expert on privacy. I am very excited to be working on use cases as they relate to the DID spec. Working on HIE of one to be standard compliant. 15:22:23 guests+ daisuke 15:22:33 daisuke: I am working at Japanese broadcasting (?) corporation. I am interested in decentralized architecture, including DIDs and VCs. 15:23:01 dlongley: I am CTO of Digital Bazaar. I have been working on DIDs and other standards for a decades, these power our technologies at Digital Bazaar. 15:23:12 Orie has joined #did 15:23:16 present+ 15:23:37 dmitriz_: Software engineer at Digital Bazaar. Secure Data Store Working Group. Co-editor of did:web and did:key methods. 15:23:38 guests+ fujia 15:23:49 fujiia: It's my first time joining this meeting for research purposes. 15:23:53 @Dmitri - can you say more about the renaming of SDS? 15:23:54 s/fujia/fujiia/ 15:24:58 GeunHyung_Kim: I am Geun Hyung Kim, I represent a company in South Korea, I am for the first time in this meeting. I am interested in DID specifications. I want to apply them in several applications that require decentralized identity. 15:25:22 Guests+ Jay_Kishigami 15:25:38 Jay_Kishigami: I am interested in DID and VC, I expect a good discussion here. In Japan it's midnight so I can't promise to stay up until the end of the meeting. 15:26:29 JoeAndrieu: President of Legendary Requirements, Invited expert, leadership of RWoT, former co-char of CCG. I am interested in greater freedom and more privacy for individuals. 15:27:37 Jonathan_Holt: Certified physician, at Standford. I was involved in standards for a long time. Involved in DID and VCs in the last 3 years as inivited expert, and CMO of Consensys Health. I have worked on the CBOR section and CDDL. 15:28:37 justin_r: I'm involved in DIDs on behalf of one of my clients. I worked on OpenID Connect and OAuth, UMA, various extensions. Looking at next-generation protocols such as GNAP. I'm here in the DID space because there are some interesting problems and technologies. I keep an eye on how things fit together. 15:29:08 drummond: One of the co-editors of the specification. Chief Trust Officer at Evernym, also at Sovrin and Trust-over-IP. From Seattle. 15:29:14 and I had a fantastic egg sandwich on a biscuit this morning, my daughter and I made the buscuits by hand last night 15:29:35 guests+ jyr 15:29:59 I will have to drop for a quick call, but I'm Orie, I'm co-editor of the did spec registries, and I work on DIDs and VCs in the context of global supply chains. 15:30:08 jyrossi: Happy to meet again friends from W3C, even if it's only online. Very happy to come back to the discussion on DIDs. We have invested time in ID management, we are now associated members of FIDO Alliance. We are very happy to be back in this process. 15:31:00 identitywoman: My name is Kaliya Young, my handle is identitywoman . I am an expert in this field and co-founded the Internet Identity Workshop 15 years ago. One problem in the beginning was how do people own their own identifiers? In this WG I work part-time for a startup called Wireline. 15:31:20 scribejs set jyrossi Jean-Yves Rossi 15:31:20 geusts+ jyrossi 15:31:21 guests+ jyrossi 15:32:36 present+ kristina 15:33:08 kristina: My name is Kristina, I work at the identity standards team at Microsoft. I am based in Tokyo so usually read notes. I'm excited to join this virtual F2F. It's nice to see many people from Japan, there are many interesting use cases here. 15:33:21 present+ tan 15:33:52 Leonard_Tan: We work on a key management solution. We are mostly known for cryptocurrency wallets. We are interested in how we can implement DIDs. 15:33:56 Kazuaki has joined #did 15:34:25 luu: In my company there is a project with OpenID, I am here to learn about DID. 15:34:31 lentan has joined #did 15:35:20 manu: I am Manu Sporny, CEO of Digital Bazaar, co-editor in this specification as well as other specs in W3C. I am involved for many of the same reasons as others, to do great good in the world, as long as we get it right. I appreciate everyone being here. 15:35:32 scribejs set dtluu Duy-Tung LUU 15:35:47 present+ Duy-Tung LUU 15:36:02 present+ Dmitri Zagidulin 15:36:03 guests+ dtluu 15:36:14 markus_sabadello: markus_sabadello from Vienna, Danube Tech, co-editor of the spec. 15:36:25 Masa: We are very keen on the use cases of DIDs in the financial industries. 15:36:51 Kazuaki_Arai has joined #did 15:37:12 selfissued: I am Mike Jones, I work on identity standards at Microsoft, I have worked on JWT, OAuth, FIDO, etc. I try to keep things simple enough so that developers actually implement them. 15:37:15 In-browser Zoom and my mic do not get along. I'm Amy Guy, working with Digital Bazaar. Previous history with decentralised social web stuff. Preferred breakfast is last night's leftovers, especially if spicy. 15:37:21 guests+ Masa_Mashita 15:38:10 guests+ Shigeru_Fujimura 15:38:17 Shigeru: I am observer of this meeting. I am a representative of a Japanese telecommunication company. I am interested in collaboration between DID and Web of Things. 15:38:41 On a side note... I feel like we have a massive blind spot wrt. Asia-Pacific interest in the space and probably need to figure out what just happened!? 15:39:03 shigeya: I am an alumni of W3C, I'm associate director of a blockchain lab. I see there is a possibility for DIDs as a global identity standard, I look forward to the discussion. 15:39:18 scribejs, set shigeru Shigeru Fujimura 15:39:33 guests+ Takashi_Minamii 15:39:33 indeed, Manu. Surprising but pleasant (and important to understand) 15:39:35 Takashi_Minamii: From a Japanese credit card company. In W3C I was in Web Payment, now I join as an observer to catch up on DID and VC. 15:39:41 Sorry for the sound problem. I'm Kazuaki from Japanese payment company called JCB. I'm working on the area of digital identity and security. This is my first time in TPAC, and happy to be here! 15:39:50 Agreed -- thrilled to have all the APAC folks here. 15:39:55 Tetsuya_Kono: It's my first time to attend the WG, I'm very excited, thank you. 15:39:56 guests+ Tetsuya_Kono 15:40:24 Tomoyaki_Mizushima: I am observer at these meeting. I usually join WoT Working Group, so now I decide to join these meetings. 15:41:29 Wang_Haiguang: I am a senior researcher in Huawei, my office is in Singapore, I do research on trust, I am a newcomer in this group. I have contributed to IEEE. I have been following the discussions in the DID spec since last year. 15:41:46 brent: Kazuaki try one more time to introduce? 15:42:02 burn: Kazuaki introduced herself in IRC above 15:42:39 brent: I am Brent Zundel, I work with Evernym, we have been heavily involved with DIDs and VCs from the beginning. My day job is crypto engineer, I play with math. I am also co-chair of the DID WG. 15:42:59 brent: Thank you all for being here. Over to my co-chair to walk through steps to CR. 15:43:20 Topic: steps to CR 15:43:20 burn: Thank you everyone for joining. We are pleasantly surprised by the substantial attendance from Asia. 15:43:24 jonathan_holt has joined #did 15:43:35 burn: Let's find out if we can find better ways to accommodate you. 15:43:42 present+ jonathan_holt 15:43:53 burn: This will be interesting for many of you, maybe challenging. We are in deep deep details. 15:44:01 present+ Wang_Haiguang 15:44:30 burn: The group would like to get to CR, this is a target for most groups when they get close. 15:44:46 burn: We were hoping to get to it in this meeting, but we still have a number of issues we need to get through. 15:44:57 burn: It's very important to understand what it means to get to CR. 15:45:11 burn: Now it's appropriate to go over the complete list of requirements. 15:45:25 burn: The official document is the process document (Process 2020) 15:45:42 burn: There is often additional information and detail in other places (Pubrules, and W3C Guide). 15:46:32 burn: Editors used to have to check list of requirements for the spec manually. But a number of years ago W3C folks wrote the automated Pubrules checker which goes through your proposed document. 15:46:43 burn: brent and I went over those documents and listed all the requirements. 15:47:39 burn: The two general requirements are on the current slide (14): 1. The document is considered complete and fit for purpose, no further refinement to the text is expected. A CR is well-written, detailed, self-consistent. 15:47:58 burn: The key point here is: The document is "complete". It is "ready" to become a Recommendation. 15:48:25 burn: Of course without implementation experience, the standard is useless. The purpose of the CR phase is to gather implementation experience, which can result in changes to the spec 15:48:44 burn: The group may have misunderstood something, there may be gaps; this may require another CR. 15:49:10 burn: We tried to allow time in the schedule for two CRs. This doesn't mean we want this one to be a "trial", but the reality is don't get everything right the first time. 15:49:44 q+ to talk about the process document 15:50:12 q? 15:50:14 burn: The first CR publication after approval of a Transition Request is a CR Snapshot. 15:50:20 ack jeff 15:50:20 jeff, you wanted to talk about the process document 15:50:56 jeff: I agree that the Process document can be confusing, it's meant to cover all details. We also have a document "Process for busy people" which 1/4 the size. 15:51:06 jeff: It's a simplied version of Process 2020. 15:51:26 burn: The process can be tricky when you make significant changes. 15:52:02 burn: Here is a list of of requirements (showing Slide 15) 15:52:27 burn: The two most important items have asterisks * 15:54:05 It's important to also mention that many of the people at DIF and the CCG are *also* in this group on a regular basis. 15:54:20 burn: * Complete Wide Review, this is not very precisely defined, the intent is to ensure that a broad section of potential stakeholders have an opportunity (are encouraged) to review the specification and give feedback. 15:54:23 burn: This happens in your domain, e.g. we asked the W3C CCG and DIF, who are the groups that are most closely connected to this work. 15:54:25 burn: Wide Review also includes something called Horizontal review (review by groups within W3C). 15:55:14 burn: After workin on many specs, I can say that W3C's Horizontal Review is one of those things that make specifications as good as they are. 15:55:53 burn: E.g. Accessibility reviews made HTML really good. 15:56:18 q+ to ask about horizontal review for privacy/security 15:56:30 q? 15:56:32 burn: We are expecting someone from the TAG to join us during this F2F. 15:56:33 ack jonathan_holt 15:56:33 jonathan_holt, you wanted to ask about horizontal review for privacy/security 15:57:19 q+ to note security audits happening elsewhere. 15:57:36 jonathan_holt: Wayne and I were working on a security review. If we don't get any feedback, does it actually mean there are no security and privacy concerns? Given the nature of our document, is there a formal process for doing a security audit of our document. We had a bunch of ethical and moral dilemmas about the use of our document in the futures. 15:58:14 burn: W3C does not require and does not have a process for formal reviews. However, individual groups (either by own initiative, or encouragement) may decide to do that. It depends on the specifics of the specs, and the checks the group and W3C think are needed. 15:58:34 burn: When the Security and Privacy review document is complete and sent to the groups, we will see where it goes from there. 15:59:00 burn: With regard to our spec.. Those of you who are observing, we have spent substantial time discussing privacy, many of use care deeply about this time. 15:59:20 q? 15:59:23 ack manu 15:59:23 manu, you wanted to note security audits happening elsewhere. 15:59:23 burn: We have spent very significant time on privacy. Our next topic is a privacy topic. We will continue spending time on it as needed. 16:00:25 s/Wayne and I/Wayne, Adrian and I/ 16:00:48 manu: Agree with everything. In addition, a number of companies that are building solutions are actively undergoing reviews with regard to privacy. E.g. it's known that the U.S. DHS Privacy Office is looking into this. 16:01:25 manu: Privacy and security is deeply of interest of the group. We are getting multiple reviews from multiple angles, even though not everone in the group may have visibility into this occurring. 16:02:02 burn: ivan , can you monitor the unknown caller.. 16:02:59 burn: * The major item for CR is to complete the work. We need to formally address all issues raised about the document. This doesn't necessarily mean that all issues must be accepted or agreed with. We need to seriously review and respond to issues. 16:03:40 burn: This is another thing that makes W3C specifications good. We are not allowed to ignore issues. It's a requirement that we officially address and mark every issue. 16:03:49 burn: manu did this work for the VC spec. 16:04:21 burn: That's why during this F2F we want to address 25% of the issues, to "unstick" ourselves 16:04:30 gannan has joined #did 16:04:46 burn: We're also required to document all new features since the previous publication. There are class 3 and class 4 changes. 16:05:05 burn: We need to publicly document such changes. It's optional to document editorial changes. 16:05:23 burn: We use ECHIDNA to publish. Every time with commit, a new Working Draft is published. 16:05:34 burn: We will likely join a diff document since the FPWD. 16:05:50 burn: We also have an opportunity to identity features in the spec as "at-risk". 16:05:59 Does anyone have links to definitions of "class 3" and "class 4" changes? 16:06:38 burn: If there is lack of sufficient implementation experience, we may have to remove a feature. This is a substantive change that requires a new CR. If we believe there is a risk that a feature gets removed because of that, then those features can be marked "as risk". 16:06:51 drummond, https://www.w3.org/2020/Process-20200915/#correction-classes 16:06:56 burn: This is how we can let the world know that this is a substantive change that could occur. 16:07:11 q+ can you define what defines/composes a 'feature'? 16:07:20 burn: We have to document what it means to have "sufficient implementation experience". A common approach is to require two independent implementations. 16:07:27 burn: We usually try to get the strongest result we can. 16:08:02 burn: If you cannot get two demonstrate implementation, you can't call it a "standard". The goal is that independent parties can read the spec and implement it in an interoperable way. 16:08:27 burn: We need to specify a deadline for comments, must be at least 28 days after publication. 16:08:37 q? 16:08:46 q+ to ask: can you define what defines/composes a 'feature'? can you provide an example? 16:08:49 burn: It's a really short time for implementations. 16:08:59 burn: All this needs to be done before we can request publication. 16:09:18 ack jonathan_holt 16:09:18 jonathan_holt, you wanted to ask: can you define what defines/composes a 'feature'? can you provide an example? 16:09:29 jonathan_holt: What's a "feature"? 16:09:42 burn: This can be defined differently by different groups. 16:09:55 q+ 16:09:58 q- 16:10:02 burn: Most groups define this as something that can be implemented in a way that's independent of other pieces. 16:10:12 burn: E.g. You remove it, and the rest of the spec still "works". 16:11:02 burn: We do a formal Transition Request for the CR. We must document any formal objections. 16:11:26 burn: We are expected to document what has changes since the previous step. 16:12:03 burn: We report on the requirements and how they have been met. 16:12:21 burn: We report on changes in dependencies with other groups, and information about implementations 16:12:54 burn: It is common to require a formal review meeting with the Director, to ensure we meet all publication requirements. 16:13:13 burn: Once we have approval, it's 1-2 weeks to publication. It's reasonable to assume a month, since the Transition Request. 16:13:30 burn: Any questions about this walk-through of the requirements for CR? 16:13:31 q+ 16:13:34 ack manu 16:13:49 q+ 16:13:56 q+ 16:14:10 manu: Process question on CR.. I was not aware of the CR Snapshot thing. My expectation is that everything else is still in place. E.g. we need to go through another CR if we have a substantial change. 16:14:33 q+ to on 'mark at risk, expecting changes in implementation' 16:14:44 q- to on 16:14:47 q- to 16:14:56 burn: We were told about this in an Advisory Committee meeting. This process is backwards compatible. If we want we can do the same traditional process. The problem is that this is not what the Process document says. 16:14:58 q+ to ask 'mark at risk, expecting changes in implementation' 16:15:07 ack brent 16:15:59 ack ivan 16:16:02 q+ 16:16:11 brent: I second what burn said. We were told that we are all on Process 2020 since it's all backwards compatible. The brief summary is that we can go the CR Draft route (what we anticipated)... If we go the Snapshot route, it enables us to do the IPR step in CR rather than PR (that's the primary difference). 16:16:58 ivan: Let's put IPR aside for a moment, then the difference is only in names. We can update the CR via ECHIDNA except when the changes are relatively significant (judgement call). We can go back to the Director when we want a "well-announced CR to the world". 16:17:33 ivan: Aside from the the new process, there is also a new IPR policy. At the moment, this WG is still in the old IPR regime. The biggest change is whether we think that we want to have IPR protection on CRs or not. 16:17:39 ivan: The WG has to decide this 16:18:21 ivan: If the IPR in this WG is not a major point of discussion, then this is not relevant to us. If we want IPR protection for CR already, then we need to move to the new IPR policy. 16:18:35 ack manu 16:18:35 manu, you wanted to ask 'mark at risk, expecting changes in implementation' 16:18:40 burn: We do have time scheduled specifically for the new IPR in our agenda. 16:18:54 manu: burn you had mentioned marking sections as "at-risk". 16:19:32 manu: Can we mark those sections as "this section may change", so that we don't have to go through CR again if it changes? 16:19:52 q+ 16:19:53 manu: Does this language allow us to not move through CR again if the change is substantive? 16:20:31 burn: My reading is that the process regarding such changes hasn't changed. I think it's likely to be okay as long as you are precise enough about the nature of the change. 16:21:41 burn: I agree with what brent said. We should be able to do this our normal way, unless we want a CR Snapshot for IPR reasons. I don't think we need to concern ourselves with this right now. We will talk about it. This is largely going to be something the Editors and Chairs will have to do. The process is basically the same. 16:21:51 ack burn 16:21:55 ack jonathan_holt 16:21:57 burn: We will continue to learn as W3C refines its descriptions 16:22:21 If that happens, we're toast :P 16:22:34 or rather, we won't go into CR if we're in that position :) 16:22:43 jonathan_holt: What is a feature... What if that feature is e.g. the Abstract Data Model. If we can't get agreement on this, will we drop such a core fundamental piece? 16:23:04 burn: Agree with manu, we won't go into CR if we're in that position. 16:23:52 burn: There is a director, but there isn't a king. The Working Group decides what counts as a sufficient specification. If there is no Abstract Data Model and nothing to replace it, then there specification is not sufficient and we will keep working on it. 16:23:56 q? 16:24:21 rrsagent, draft minutes 16:24:21 I have made the request to generate https://www.w3.org/2020/11/02-did-minutes.html ivan 16:24:46 burn: After the break we will talk about privacy violating properties. (This used to be the "type" topic). 16:25:24 burn: We will leave this Zoom room open. We will show a slide that will have a link to a breakout room. Please be back here, ready to begin, at the top of the hour. 16:25:25 Very very fun! 16:25:41 burn: Thanks everyone, enjoy your break, we will talk in about 34 min 16:35:27 fujiia_ has joined #did 16:37:29 sekine_ has left #did 16:37:51 t_ has joined #did 16:37:57 t_ has left #did 16:40:49 fujiia_ has joined #did 16:58:28 Topic: Avoiding Privacy-Violating Properties 16:58:33 Slides: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.p21 16:58:41 scribe+ 17:03:23 drummond: welcome back everyone 17:03:39 ... this session was originally two sessions and we decided to devote both to this outstanding privacy related issues 17:03:50 ... it may not take us 90 mins, but it may.. we have several important decisions to make 17:04:03 ... as we go through this I have specific text, either in the spec now or proposed, I think it would be valuable for us to look at together 17:04:07 ... nothing very long 17:04:15 ... hopefully we'll make some decisions 17:04:27 Kazuaki_Arai has joined #did 17:04:33 ... This session si motivated because we believe after the last few meetings that there is strong consensus that privacy is a paramount consideration for our spec 17:05:01 ... and that we are proposing a general principle that we can apply throughout which is that DID method specifications and DID controllers that control what goes into a DID doc should not use privacy violating properties in publicly available DID docs 17:05:08 ... cook on that for a second. 17:05:20 ... The proposed structure for this session is to discuss this overall privacy stance 17:05:35 ... and then if we have general agreement on that, seek consensus on proposed wording of a PR that amy submitted that would capture that clearly 17:05:41 ... and then decide on the action items for completing that 17:05:45 ... and getting it in for CR 17:05:53 ... That's the assignment for this section. That's a very important decision 17:06:05 ... will close the discussion around the type property because we're now saying this involves any property in this area 17:06:13 ... Since we're on the topic, let's talk about the other open privacy issues, there are several 17:06:24 ... if there's time we'll look at wording we have in the spec or proposed wording and see if we can decide on that 17:06:31 ... if we get all that done in 90 mins I'll be very happy 17:06:38 ... That's how we propose to move forward 17:06:46 ... Now part one: privacy violating properties 17:07:00 ... let's be specific about what we propose this means for the open issue around the proposed type property 17:07:08 ... First it means we would not specify a type property in did core 17:07:19 ... or for that matter any other property that could be a privacy violating property 17:07:30 ... the second point we discussed on our last wg call, DID docs use an open world data model 17:07:42 ... which means a DID method spec or a DID controller that controls what goes into the DID doc 17:07:46 ... they can add other properties as they desire 17:08:00 ... this motivated us to say the issue we're addressing is larger than just the type property 17:08:06 ... it applies to any privacy violating property 17:08:10 ... that's a strong term, "privacy violating" 17:08:27 ... we're using that to call out that properties that might seem innocent can still turn into privacy violations if used in certain ways, and thus are best avoided 17:08:40 ... so the last point is that amy has proposed language in PR #444 17:08:56 ... we'll see on the next slide, it includes some enhancements by brent and wordsmithing I added on the next slide, not exactly what's in that PR 17:09:01 ... this is what i suggest we review 17:09:04 q+ to ask about whether we expect that govs or other verifiers 17:09:12 ack agropper 17:09:12 agropper, you wanted to ask about whether we expect that govs or other verifiers 17:09:29 agropper: a very quick question - in the context of what we're doing here, are we assuming governments for example or other verifiers will simply keep or publish a white list of acceptable did methods 17:09:48 ... the fact that the open world model will be dealt with in terms of privacy and accessibility, in this way, want to get a sense from the group whether that's our assumption going forward? 17:09:55 drummond: that's a very interesting question 17:10:05 ... if I may, i want others to volunteer their answers, I'd like to break mine into two parts 17:10:12 ... one.. will governments publish whitelists of acceptable DID methods? 17:10:24 ... i believe they either will or they will point to industry defined or consortia defined lists 17:10:41 ... there will be a distinction.. those allow lists may not just be about privacy, but about security, reliability considerations 17:10:46 ... whatever might determine DID methos are okay 17:10:58 ... part two is that doens't by itself constrain a DID controller from adding properties to a DID doc 17:11:09 yes, consumers of DIDs will absolutely make choices around which DID methods they accept 17:11:16 ... depending on.. a DID method may not allow that but if a DID method does allow that you have a second consideration of what a DID controller would do not constrained by the DID method 17:11:22 q? 17:11:22 q+ 17:11:30 ack dlongley 17:11:40 dlongley: In short we should expect consumers of DIDs to make choices around which DID methods they accept, that's really the only way it can work 17:11:42 drummond: agreed 17:11:50 q+ 17:12:16 drummond: I'll pause for 60 seconds [so you can read this] 17:12:33 ... this is proposed text in a PR from amy, I was not clear where... was this proposed for the privacy considerations section? 17:12:37 yes privacy considerations section 17:12:54 ack jonathan_holt 17:13:13 jonathan_holt: to raise the push back as far as a allow/deny list for DID methods... I think there are DID methods out there such as IPID which don't rely on a specific verifiable data registry 17:13:23 ... all about how you implement that representation of the DID doc, not necessarily the underlying VDR 17:13:27 ... I'd be careful about choice of words 17:13:44 ... this goes back to the early days of the internet... [he] described this mentatiliy of people thought they could own parts of the internet 17:13:56 ... here theres' going to be a grey area of what is a DID method, what is a particular VDR of a blockchain technology 17:14:00 ... to delineate that, it's too early 17:14:46 Proposal for the privacy consideration section: https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.ga6aa7427ae_1_42 17:14:48 q+ 17:15:01 q+ 17:15:03 drummond: are there any questions about what this is saying or clarifications anyone would need? 17:15:09 q+ to point out that serviceEndpoints can essentially type the DID subject 17:15:18 ack dan 17:15:37 burn: comment that would be invalidated... in the last sentence I think you mean SHOULD *only* be used for expressing cryptographic material.. not just should 17:15:39 q+ to ask about defining "public DID Documents" 17:15:47 ack burn 17:15:49 ack burn 17:15:50 ... but amy made the comment that this is a non normative section so it's quesitonable whether the SHOULD is appropriate 17:16:00 drummond: my reaction is we should add only and the should can become a lowercase should 17:16:01 ack manu 17:16:06 "To minimize these risks, all properties in a DID document ought to only be for expressing cryptographic material, endpoints, or verification methods related to using the DID." 17:16:11 manu: along those lines, "is expected to be" 17:16:14 ... overall great text 17:16:21 ... I think it captures the discussion we've been having for months fairly well 17:16:24 yes, +1 from me for the text as well 17:16:36 ... I did read ahead a bit and there are multiple times that normative language is in this guidence, but tha'ts the only thing, that's easy we can change it 17:16:44 +1 to the text 17:16:45 For the purposes of the record, the "he" describing the early days of the internet in Jonathon Holt's comment is Robert Khan: https://en.wikipedia.org/wiki/Bob_Kahn 17:16:45 ... assume the shoulds and musts are going to go away but the guidence will be there 17:16:51 ... this is the expectation of what implementers will do 17:16:52 ack dmitriz_ 17:16:52 dmitriz_, you wanted to point out that serviceEndpoints can essentially type the DID subject 17:17:16 dmitriz_: I want to add that, I like the language proposed, want to highlight the cryptographic material, services, verification methods part - and claim that service endpoints can and will fingerprint 17:17:19 ... and identify the DID subject 17:17:31