14:33:02 RRSAgent has joined #did 14:33:02 logging to https://www.w3.org/2020/11/04-did-irc 14:33:04 RRSAgent, make logs Public 14:33:05 please title this meeting ("meeting: ..."), ivan 14:34:28 burn has joined #did 14:46:52 present+ 14:47:10 Meeting: DID WG (Virtual) F2F Meeting, 3rd Day 14:47:10 Chair: burn, brent 14:47:10 Date: 2020-11-04 14:47:10 Agenda: https://tinyurl.com/yydapmu3 14:47:10 ivan has changed the topic to: Meeting Agenda 2020-11-04: https://tinyurl.com/yydapmu3 14:47:31 yoshiaki has joined #DID 14:54:43 guest+ Keiko Itakura 14:56:47 shigeya has joined #did 14:58:08 I couldn’t introduce myself on the first session, can I introduce？ 14:58:24 brent_ has joined #did 14:58:41 tm has joined #did 14:58:53 justin_r has joined #did 14:58:56 scribejs, set keiko Keiko Itakura 14:59:01 brent__ has joined #did 14:59:04 present+ 14:59:06 present+ 14:59:21 present+ 15:00:36 present+ 15:00:38 markus_sabadello has joined #did 15:01:09 kazuakiarai has joined #did 15:01:14 drummond has joined #did 15:01:21 present+ 15:01:30 present+ 15:01:30 scribe+ 15:01:36 guest+ Kazuaki_Arai 15:01:47 guest+ Takashi_Minamii 15:02:06 present+ 15:02:21 guest+ Tomoaki_Mizushima 15:02:22 present+ 15:02:35 present+ 15:02:41 burn: Welcome to the 3rd day of our VF2F! 15:02:46 present+ drummond 15:02:47 kristina has joined #did 15:02:49 burn: Let's do quick introductions for those that haven't yet. 15:03:00 present+ 15:03:01 present+ justin_r 15:03:13 present+ manu 15:03:20 Keiko: I have joined from the first day, but couldn't introduce myself. This is Keiko Takura from Japan, responsible for project management for Digital Identity, glad to meet everyone! 15:03:29 present+ rhiaro 15:03:36 burn: Thank you and welcome, anyone else? 15:03:37 zakim, who is here? 15:03:37 Present: burn, justin_r, ivan, brent__, dlongley, drummond, manu, rhiaro, shigeya, markus_sabadello, kristina 15:03:39 On IRC I see kristina, drummond, kazuakiarai, markus_sabadello, brent__, justin_r, tm, brent_, shigeya, burn, RRSAgent, Zakim, YueJing_, Mizushima, tzviya, ivan, keiko, 15:03:39 ... ChristopherA, deiu26, Travis_, faceface, dlongley, manu, hadleybeeman, wayne, bigbluehat, rhiaro 15:03:40 No one else is new. 15:03:41 agropper has joined #did 15:03:44 jyrossi has joined #did 15:03:46 present+ orie 15:03:59 present+ 15:04:11 present+ adrian 15:04:12 present+ J-Y Rossi 15:04:13 burn: As a reminder, we're on day 3 - we've made some good progress on privacy, yesterday we began conversation on unknown properties - exciting conversation. 15:04:20 burn: We will continue that conversation tomorrow. 15:04:23 present+ 15:04:26 guest+ jyrossi 15:04:38 burn: But for today, we're going to have brent talk about new W3C Process... we need to make a decision about that. 15:04:53 burn: We will also then have Daniel Buchner tell us about deterministic equivalence ID. 15:04:55 present+ identitywoman 15:04:59 burn: We've been talking about that for a while. 15:05:06 burn: Daniel has a new take that he'd like to present to us. 15:05:23 burn: After the break, we'll have a brief presentation on content identifier proposal from ISCC. 15:05:24 present+ Michael_Jones 15:05:33 burn: We will then spend working time on test suite led by Orie. 15:05:49 present+ jonnycrunch 15:05:55 fujimura has joined #did 15:06:06 burn: It is often the case in WGs that a small group of people work on test suites, but often others don't know about what's required to write tests... Orie is going to talk about how test suite works. 15:06:13 q? 15:06:49 present+ kristina 15:06:53 burn: Before we get started, there's something I'd like to talk about -- Brent and I were discussing the discussion about Unknown Properties -- we were reminded about the disagreements that existed before the group before the Amsterdam F2F meeting... that was very frustrating for both of us. 15:07:16 burn: You remember about WebRTC adoption suffered for years because of a split -- attempt to create competing standards, horrible for community. 15:07:44 burn: I wanted to talk about what it means to do work here in W3C and why we're here. I know that, and you will hear people say, what we want is interoperability. Yes, that's true, but at a higher level, we want success and adoption of the technology. 15:07:51 Orie has joined #did 15:07:53 present+ shigeya 15:07:54 burn: We want DIDs and VCs to be used broadly in the world. 15:08:22 burn: It is standards that enable that. I've seen a number of standards that have come out, that had poor interop, maybe 80%-90% -- but that was good enough. We should strive for more, but we need to remember the end goal. 15:08:35 burn: The end goal isn't a beautiful or elegant or ideal or perfect, the goal is something that works. 15:08:49 guest+ Jay_Kishigani 15:08:53 present+ 15:09:22 burn: Something that works for those that must implement -- this is a practical commercial endeavor -- we need to know that it'll work for you and that's the requirement. Some standards start off beautiful and get ugly, we might be makin gan ugly baby here, but if it's adopted in the market... that is a success. 15:09:34 Eugeniu_Rusu has joined #did 15:09:39 present+ 15:09:46 +1 to burn, +1 to priority of constituencies ... we need it to work well/simply/etc. for users of the spec 15:09:55 present+ YueJing_ 15:09:56 burn: I think we can do it, there is a path forward here -- just as we did in Amsterdam, we believe it's possible for us to come together and accomplish what we need to -- we have a lot of intelligence and ... in this community. 15:10:30 burn: Please lets work towards getting something that works... not the ideal, but something that works well enough -- that's possible, this group can do it. This group has done it in the past, and this group can be that success story going forward. 15:10:39 Topic: W3C Process and Patent Policy 2020 15:10:54 see [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_47) 15:10:58 q? 15:11:35 Brent said deeply profound things on mute. 15:11:35 We all missed it. 15:11:56 brent: These are the highlights of Process 2020 -- we are operating under Process 2020. 15:12:06 brent: There is a great wiki explainer for Process 2020. 15:12:47 see [P2020 explainer](https://www.w3.org/wiki/Process2020) 15:12:53 brent: Some highlights -- makes it easier to update RECs and CRs, strengthens patent policy, provides Living Standards capability. 15:13:06 brent: Add yourself to the queue for questions. 15:13:32 brent: The big changes -- in order to make substantive changes to Recommendations -- you can republish them and make changes inline. You can republish editorial stuff easily. 15:13:59 brent: That can just sort of happen -- changes to RECs, you have caniddates, you review just those changes, allows patent/AC reviews, then it's as simple as update request to republish REC. 15:14:13 brent: This stuff was going to apply more to the VCWG than this group... 15:14:25 brent: It is possible to publish a REC that identifies features that can be expanded upon. 15:15:01 brent: We can say what features can be updated -- can be added following process above. Allows for us as spec writers to identify things we wish we could have done, but couldn't in first round. 15:15:21 brent: In all of these -- the whole Director's Approval process is more streamlined -- for things that are not controversial, it's automatic. 15:15:37 identitywoman_ has joined #did 15:15:38 brent: That reduces some of the bureaucracy. 15:15:49 brent: The thing that applies to this group -- CR Snapshots and CR Drafts. 15:16:06 brent: You can trigger patent review process at this stage (it used to happen in later stages) 15:16:08 q+ 15:16:17 ack ivan 15:16:45 kristina_ has joined #did 15:16:52 ivan: We need to be precise, patent review on CR is subject to WG accepting new patent policy. At the moment, we are in the old patent policy... all patent policy implications are not relevant to us. 15:17:03 brent: Yes, that is what we need to decide today, we're straddling both world today. 15:17:24 brent: This is language that I've pulled out of the wiki -- thank you for sharing that Ivan. 15:17:31 brent: Betwen snapshots, we can publish CR Drafts 15:18:12 brent: If WG wants to do CR Draft, we can do so like Echidna works for us now... 15:18:21 brent: Pushes it out to TR space, as you'd expect it to happen. 15:18:30 q? 15:18:35 brent: Streamlines the process of updating a CR and working toward the next step for a CR. 15:18:48 brent: Process 2020 is designed with new Patent Policy. 15:18:49 q+ 15:19:02 ivan: What it means in practice, the publishing CR drafts can be done in Echidna as we do now. 15:19:27 brent: Yes, just as we made a decision to publish WDs, we can use Echidna to publish CRDs. 15:19:34 ack ivan 15:19:43 ivan: Drafts, CRSes still go through the full blown process. 15:19:52 CRD -- Candidate Recommendation Draft 15:19:58 CRS - Candidate Recommendation Snapshot. 15:20:34 Where CRS is approx. equiv to the prior "Candidate Recommendation" 15:20:40 brent: Patent policy 2020 update -- CR snapshot can be done as a patent review draft... previously it was a Proposed Recommendation (much later in the process), which didn't provide implementers with patent protection. 15:21:03 q+ 15:21:05 brent: Any questions on Process 2020 before we jump into Patent Policy 2020 15:21:07 ack burn 15:21:22 burn: So, the staement that you just made -- is that the case even if we don't accept new Patent Policy 15:21:30 burn: Or only if we adopt the new one. 15:21:42 brent: If we don't accept the new patent policy, the new one will come in during REC. 15:22:18 brent: Process 2020 and Patent Policy 2020 were written to work hand in hand... probably nto much thought put into mix/matching them. 15:22:39 brent: CRs are now a CR Snapshot and could contain patent protection 15:22:54 brent: CR drafts make it easier to publish 15:22:59 brent: Flow is more automated 15:23:21 brent: We are not operating under Patnet Policy 2020, we're under Patent Policy 2017 15:23:55 brent: We could operate under PP2017, patent review doesn't exist until REC... but in my opinion, things would be much smoother if we can operate under there. Having said that, I am not a lawyer. I am definitely not your lawyer. 15:24:02 +1 to moving to Patent Policy 2020 based on what I've heard so far 15:24:34 jonathan_holt has joined #did 15:24:53 present+ jonathan_holt 15:24:56 q+ 15:24:57 brent: Changes to Patent 2020 -- Patent Review Drafts... new process, do patent review earlier... that could be better. 15:25:03 dmitriz has joined #did 15:25:08 Doing patent review earlier IS better. 15:25:20 manu: Agree with Drummond. 15:25:42 ivan: For people new to W3C -- might be worth emphasizing what patent policy exists and why it's important. 15:26:03 Ivan: The thing that led to the current patent policy is that implementers hsould be able to implement things w/o being afraid of being sued by infringing a patent. 15:26:13 That's also a big plus. 15:26:42 ivan: if you are a member of the WG, a company, the patent policy means that you sign a commitment that even if you have a patent somewhere, that might be relevant for this specification, you will not go after another company who uses that patent to implement this specification. 15:27:00 ivan: This is what the patent policy is all about at W3C... the big difference is that this kind of commitment kicked in once the document was published as a REC. 15:27:45 ivan: In practice, what that meant in some WGs, where implementers needed to implement in patent shark tanks... that meant implementers were scared to implement. Implementers didn't want to implement until they were protected. 15:27:55 yoshiaki has joined #DID 15:28:36 ivan: As soon as something is a CR Snapshot, that is a patent review draft... meaning, you will be protected... in practical terms, can't judge if this community is operatin gin a patent heavy environment. If the ansewr is no, we may not care, if the answer is yes, then we are better moving to new patent policy as soon as it can happen. 15:28:37 q+ 15:28:40 ack ivan 15:28:42 ack ivan 15:28:56 brent: Other slightly more extensive changes... 15:29:04 ack manu 15:30:13 scribe+ 15:30:14 manu: I just wanted to speak in favor of this. There could be patents in there, but the sooner we can deal with this the better, it's easier for larger entities to start pushing things when they know about patent protection. We can do patent policy about a year in advance -- let's do all the positive signaling we can. 15:30:38 brent: What we went through was differentces, by specification, we mean REC track document -- patent review draft, specification that is under review. 15:30:44 +1 to Manu's point about the earlier we can enable the market signaling, the better 15:31:15 brent: Changes to commitments, make explicit that anything that you don't add an exception for, an eclusion for, becomes a part of the RF license. 15:32:05 brent: Added persitence of licensing commitment... if you didn't have exclusions for previous review draft, next draft will use same essential claims... this section adds subsequent patent review drafts.... doesn't change anything, just clarifies. 15:32:21 q+ 15:32:50 agropper: Who pays for the patent review? 15:33:08 agropper: Who is doing patent reviews and who is paying for them? 15:33:09 Each member company does their own patent review. 15:33:39 Ivan: The member companies do that patent review for their own patents. It's always a discussion when we have potential members, but we do not necessarily ask a company to go through their entire patent pool all the time. 15:33:57 ivan: Rather, it's a statement by each organization that effectively says: "If we have a patent, it does not apply to THIS specification." 15:34:26 ivan: So, when we say "patent review" it doesn't mean that institution will go through their entire patent database... it's more of a promise for their own patent pool. 15:34:58 q? 15:35:00 ack agropper 15:35:01 agropper: Just want to say it back to all of us -- I specifically have a patent, as a signatory of the IPR policy, I'm simply saying I will not enforce this patent against implementers of the specification. 15:35:13 agropper: It doesn't require me to do any work as long as I continue to stand by this thing that I signed. 15:35:20 q+ to remind folks not to talk about specific patents. 15:35:30 scribe+ 15:35:36 ack manu 15:35:36 manu, you wanted to remind folks not to talk about specific patents. 15:35:52 manu: adrian what you said is totally fine. Do not bring up patents in the group, do not tell us if you know one, there are all kinds of horrible ethings that leads to 15:36:05 ... if you do know of a patent in the space do not tell us, do not bring it up in this meeting 15:36:20 ... even saying if you knowing that there is one is dangerous 15:36:52 burn: I had that happen in a group -- someone on a call said "I know of this patent" -- and everyone said "stop talking" -- if you don't know why this is important, consult your legal counsel. 15:37:51 In short, much bad stuff 15:38:11 brent: If you are not excluding your patent -- you don't need to speak up. 15:38:16 brent: I am not a lawyer 15:38:34 brent: Minor changes for being able to do multiple patent disclosures... 15:38:41 I agree that this is an improvement. +1 to accept. 15:38:51 s/Do not bring up/By the way, do not bring up/ 15:39:44 q+ 15:39:47 ack agropper 15:39:58 brent: I suggest we agree to Patent Policy 2020 -- we need to revise our charter... if we do -- Director will approve on December 2020. 15:40:05 (like a big mass wedding) 15:40:16 like they do for Star Wars weddings sometimes. 15:40:19 but for Patents. 15:41:13 agropper: If you are the holder of a patent AND you / your lawyer says you can benefit from excluding it -- you mention is because you're the holder... then you have separate process that has be done... spec has to find its way around the patent 15:41:18 q+ to say how you disclose. 15:41:47 burn: Don't mention patents that you don't own -- license or disclose - for patents that you hold... -- do not mention patents that you do not hold. 15:42:26 manu: to be more lawyery than that, don't disclose them to the group, expose them to the staff contact. There's a chance people change their minds which is bad. there is a process for disclosure, please follow the process for disclosure 15:42:27 ack manu 15:42:27 manu, you wanted to say how you disclose. 15:42:52 agropper: When someone discloses this to the staff, it causes work for someone -- just want to be clear that that's true and to be sure we understand how that works. 15:43:00 agropper: I don't think any of us want to make work for anyone. 15:43:36 ivan: If that happens, then yes, you create work that's on lawyer, W3C staff -- maybe I was lucky -- was busy in WGs for 15 years, personally haven't had to do a PAG. 15:43:42 q+ for PAG 15:43:55 q+ 15:43:58 ivan: Though this was a big drama when it was created -- become widely accepted by community - very few cases. 15:44:10 ack manu 15:44:10 manu, you wanted to discuss PAG 15:44:33 manu: ivan maybe it would be helpful to talk to the patent advisory group that would be formed if a patent happens. I hesitate eto talk too much mor eabout this. The likelihood of it happening is rare 15:45:15 ... we went through it in web payments and it was a horrible terrible experience and we never want to do it again. It took almost a year. Patents got chucked into the group and ran to disrupt it. it can be a terrible process, but the w3c has a really good process to navigate it 15:45:18 q- 15:45:59 brent: What you need to do is discuss this with your organizations -- we are going to ask this question -- make a proposal to the group that we do this. I hope you will be ready at that time to make that determination. 15:45:59 I heard two different things from Manu and Ivan. 15:46:01 If you wish to disclose a patent you have in order to not have to license it royalty-free, please reach out directly to Ivan and he will involve W3C legal. 15:46:12 Do not mention it to the group. 15:46:35 burn: Change of agenda. 15:46:54 burn: We are putting Orie now, he needs to leave later... don't know where Daniel Buchner is. 15:47:13 Topic: Test Suite - Working Session 15:47:14 See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_62) 15:47:39 Orie: This session is progress on test suite... 15:48:02 Orie: Our roadmap for how we're getting tests for normative statements in the spec... if you take one thing away, you'll be able to undrestand how we're testing normative statements in spec. 15:48:39 Orie: Before we dive into details... provide some background on testing... my background is in cybersecurity and computer science... I write tests on a regular basis -- personally comitted to them... but others may not be familiar with them. 15:48:48 Orie: hard to test randomness... you want deterministic tests. 15:48:53 Orie: Choose Determinism. 15:49:19 Orie: You want to commit test vectors/fixtures to Version Control... if you are generating data and testing data -- you won't see when data changes in ways that are breaking. 15:50:18 Orie: People break up tests differently -- you want to group by common feature set -- positive and negative tests... 15:50:48 Orie: Don't want individual test cases to be too long... then move on to next thing -- smaller, more precise tests... document what youre scenarios are testing in plain english... 15:51:02 Orie: If your business folks can't understand the tests, doesn't matter if engineers think it's right. 15:51:21 Orie: When you write tests, link to issues and spec text, have as much info as possible, whether tests are good enough or not... 15:51:44 Orie: You want to use realistic data -- avoid unhelpful examples -- hard to do for negative tests -- important that you reflect test data test production data. 15:52:08 Orie: You don't wnat to overfit to unrealistic data... you want to know what your test coverage is... for software libraries, you want to know that 90% of code is covered. 15:52:15 Orie: Don't repeat yourself, write simple tests. 15:52:28 q? 15:52:33 Orie: Tests are a formal proof mechanism showing that some behavior is supported.... prove that behavior exists, don't trust that it exists. 15:52:38 Orie: Architectural Approach... 15:53:24 Orie: We need a way to test normative statement in DID Core -- how is that done? Different for each W3C spec... we proposed this Dockerized test suite structure... inspired by Jest, jused by React and Facebook and JS companeis out there -- way of writing tests... describe blocks, describe suite of functionality. 15:53:40 Orie: We create "Scenario" -- loosely like "Describe block" in Jest. 15:53:48 Orie: Basically, input, code, output... 15:54:14 Orie: for example, "did:Example" contains no upper case letters is 'false'. 15:54:26 Orie: That would be the assertion. 15:54:32 Orie: did:Exmaple is the structured input 15:54:37 'contains no upper case letters" is an assertion 15:54:45 'False" is the expected value of the assertion. 15:54:53 This is an example of a negative test case . 15:55:10 Even if you don't know Javascript, you should be able to read this and understand what we're testing. 15:55:23 s/Even if/Orie: Even if/ 15:55:58 Orie: What are we doing -- no scenario per statement... 15:56:09 Orie: It depends, but when in doubt, single scenario per statement. 15:56:33 Orie: It's ok to have many smaller separate test files... less ok to have on test file that covers everything. 15:56:33 Orie: What if you can't test a statement? 15:56:43 Orie: Raise concern around that the statement can't be tested... someone else will solve the issue or statement will be removed. 15:57:06 Orie: if you try to write a test around something, communicate it to everyone else... people might help 15:57:37 Orie: if you don't know how to program, first step for writing great tests, help with english test plan -- provide examples of what you'd like to see tested. 15:57:47 Orie: Things that do/don't support capitalized letters. 15:58:02 Orie: Getting Started.... 15:58:27 Orie: We have a repo called the DID Test Suite ... we have a list of normative statements... may want to discuss how this is broken down further. 15:58:51 Orie: Previous possible recommendations... to put a single recommendation on the table to start... we want to see companies step forward to commit for statements in sections. 15:59:24 Orie: We'd like to see multiple companies commit ot doing that -- you'd know, you'll be assigned a group of statements and you'll complete tests for all of them... that group of statements will be an issue assigned to you... you can communicate on how to close that issue. 16:00:00 Orie: The key part being that in addition to that, if you are concerned about whether or not you can write a test about something -- check issues to see if it's assigned to anyone already -- start tackling it by thinking thorugh things on issue itself. 16:00:36 Orie: Also, don't just start working on something w/o having an issue assigned to it -- we want to avoid double work, we don't want two people working on the same thing. 16:01:00 q+ 16:01:23 Orie: The next piece of this is how we do breaking up of tests... how we do assignment of test for companies -- I can speak for Transmute -- we're obviously members of the WG -- we've written some for DID Parameters... both positive and negative tests... Markus is already working on DID Syntax tests. 16:01:31 Orie: Already some examples in repo for you to follow along. 16:01:32 q+ 16:01:43 ack burn 16:01:47 markus_sabadello has joined #did 16:01:49 q+ 16:02:00 burn: Woul dit be possible fo ryou or Markus to do screen share and go to repo and pull up representative tests? 16:02:02 q+ 16:02:10 burn: For many people, they are nevrous about going there. 16:02:20 burn: Hopefully people wont' be scared off by Javascript. 16:02:29 burn: But maybe you can show what an assertion look slike. 16:02:43 orie: See the statements and tests... 16:02:51 orie: normative statements around DI DParameters. 16:03:01 orie: How do we get these things to be green and why are these things red? 16:03:19 q? 16:03:30 q+ 16:03:32 Orie: This is the test suit erepo in Github, normal repo, it's a monorepo, packages are two modules to test and generate test report... test server is where tests are implemented that are processing input/output 16:04:00 Orie: This test server is dockerized, you can run it locally, easy as possible, abstract engineering side -- can run tests from server regardless on language... you will just provide structured JSON input. 16:04:09 q+ to say I wrote tests for VC in JS and it wasn't as bad as I feared 16:04:23 Orie: An HTTP server setup w/ docker... you can easily run it in your environment... each escenario, did parameters, negative and positive tests. 16:04:35 Orie: These tests make sure that server is processing scenarios correctly, these are tests about tests. 16:04:54 Orie: You may find it helpful to write these as you go -- everything that you care about has a test associated with it... it's not required to have testa bout tests. 16:05:04 Orie: Let's look at an example... 16:05:38 Orie: We start by importing a fixture... then they are passing that data to web server that runs data on web server... response from web server is same as what's committed to source. No part of DID Parameter test scenario has changed. 16:05:49 Orie: Tells you that thing sar estable, doesn't say what's tested. 16:06:01 Orie: What are we passing in first -- look at what's testsed... positive and negative tests. 16:06:11 Orie: Here are valid inputs for DID parameters. 16:06:38 Orie: The service parameter, version id, version time... under this are response assertions... you would expect 100% of these to be true, these are positive tests, these are valid example.s 16:06:48 Orie: A valid example and positive test assertion should be true... they all are. 16:07:18 Orie: Let's look at negative tests... random base64 url encoded binary... in order to tests some structures, you need to encode JSON and test unencoded value... that's a confusing part of that piece here... 16:07:39 Orie: if you b64decode it, is it ascii string, it's not... negative test, these values, expecting them to fail. 16:08:02 Orie: Negative tests are a bit more confusing, if you find them difficult, just skip them, let someone else do them. 16:08:10 Orie: DID Parameter scenarios... 16:08:27 Orie: How are we sending this information to the server... 16:08:55 Orie: Let's look at positive one first... assertions map to normative statements... the key for assertion, value is some JS function of the scenario which contains input and expected output... program returns boolean. 16:09:11 Orie: Anything that you can test in a program you can test in this format and you can get a true/false value from it... 16:09:29 Orie: This hl, associated value must be ASCII string, we're pulling valid parameter from URL and checking if it's ASCII string or not. 16:10:01 Orie: Most of tests in block pulls different param from DID URL and then all calling isASCIIString... that's an example of Do Not Repeat Yourself 16:10:14 q? 16:10:31 Orie: When you post scenario for positive tests, this is the code that runs, that's what's used to generate responses. 16:11:00 Orie: You have to handle awkward base64url encoding -- had to represent this isn JSON, have to represent negative test cases -- pulling that encoded value apart and then asserting that that's not ASCII. 16:11:22 Orie: scenario is JSON, program is Javascript, you can put those two things together and always solve the problem. 16:11:49 Orie: Final point about this repo - test vectors... that is structure used to generate test suite... this entire respec document is programmatically generated -- says when it was last generated... 16:12:09 Orie: If you submit scenarios with positive/negative merged together... 16:13:51 Orie: In addition to testing all statements, in order to do that, update-respect-test generates respec document... takes all inputs sends them to test server, then takes response and injects responses and generates table that looks nice... this is complicated, you probably won't need to touch it, might need to have questions... how are tests written and how are they written... did-core-test-server under services -- under scenarios 16:14:07 Orie: Each scenario covers positive/negative -- any questions? 16:14:11 ack manu 16:14:27 manu: first of all +1 this is awesome and a lot of work, really appreciate you putting in the time to get this set up 16:14:34 +1 to Orie really carrying the water here. 16:14:40 ... I wanted to commit digital bazaar to writing a chunk of tests 16:14:41 q+ 16:14:50 ... I expect we may have some time to talk about assigning companies certain sections 16:15:06 ... and underscore that we need to see other companies step up to do this, Danube Tech and Transmute have, we need 3 to 5 other companies to contribute 16:15:08 ack markus_sabadello 16:15:32 Markus: This is great, spent a bit of time adding scenarios for DID Syntax, in general elegant and easy to figure out where to add scenarios. 16:15:40 q+ to ask about "final report and multiple implementations" 16:16:13 Markus: If there is something that says "DID Method" -- would you reuse most of the code and just expect result to be different... 16:16:26 Orie: yes, that's best practice, write function to do one thing, then true/false. 16:16:28 q? 16:16:52 Markus: Can you talk a bit about how to integrate with implementations, libraries -- how tests pick up files/fixtures from file system... but how do they get there? 16:17:07 Markus: What are inputs/outputs -- what part does implementation generate, how do I feed it into test suite? 16:17:24 Orie: We have two competing objectives for test sutie -- test normative sections... doesn't really help you if you're an implementer. 16:17:34 Orie: You may not care that there is a test out there that says did method needs to be uppercase. 16:17:58 Orie: Two goals - first goal is test for all normative statements... second goal is, as a DID Method implementer, generate structured data to prove that your method is conformant. 16:19:02 Orie: First comment -- provide one example of DID Method test that proves that DID Method is conformant... right now, all tests are tests for normative statements... how that example works... you as a DID Method, you use version ID, you generate set of JSON files, how you use version id -- those file smatch files in test suite... programmatically generate test fixtures and then use test fixtures to show that your implementation is conformant. 16:19:26 Orie: You can prove that your did method is conformant, but don't connect... use your DID Method to generate data that's conformant, you can therefore proving that it's conformant. 16:19:33 ack shigeya 16:19:52 shigeya: I am happy to see presentation, uI have experience in test driven development, do we have any idea on timeframe for this work? 16:19:59 orie: As quickly as we can possibly go. 16:20:02 shigeya: I'd like to help 16:20:07 ack jonathan_holt 16:20:15 Thank you, Shigeya! 16:20:30 jonathan_holt: I'm a big fan of test driven development, limited by ability to write tests... what is role of CDDL? 16:20:44 jonathan_holt: I did write this for all items in registry - using regular expressions to constrain. 16:20:57 Orie: I wrote tests suite assume CDDL wouldn't get adoption... 16:21:25 ack brent__ 16:21:25 brent__, you wanted to say I wrote tests for VC in JS and it wasn't as bad as I feared 16:21:32 Orie: The process of writing these tests is miserable because we don't have CDDL... I'm a huge +1 to get CDDL into DID Core for test conformance, in absence of that, we need to write JS programs by hand. 16:21:45 brent: Just wanted to jump in -- previous WG, jumped in and wrote tests, don't be afraid. 16:21:50 Orie: and ask for help. 16:21:57 ack wayne 16:22:00 burn: Much of the work is copy-paste for the most part. 16:22:19 ack manu 16:22:19 manu, you wanted to ask about "final report and multiple implementations" 16:22:26 Thanks Wayne! 16:22:30 wayne: I am publicly committing Spruce to write tests, want to comply to tests coming out from test suite, see you all in the Javscript mines. 16:22:59 Are they right next to the Gringott mines? So filled with lots of gold??? ;-) 16:23:08 manu: orie one of the things that we have to think ahead to is there are going to be multiple people submitting tests and usually people reviewing how the group is doing, should we go to REC, it's easy if you look at a side to side comparison where you see a feature and five implmentations all passing one test 16:23:11 ... is that built into the test report? 16:23:20 ... how do we show that there are did methods all conforming? 16:24:00 q? 16:24:06 Orie: There are test of normative statements and DID Methods... 2nd category is not supported in suite... collection of fixtures for DID Methods, when you render their test results, you can see 5 people implemented version id... it's fundamentally possible to represent the information, but we need examples around single DID Method. 16:24:23 burn: End of queue, any last words, Orie? 16:24:48 Orie: Let's collaborate on Github issues, if you are a company that wants to sign up to help support -- open issue, we'll figure out how to divide up sections for companies. 16:25:03 burn: Anyone can raise issues? 16:25:16 s/burn:/brent:/ 16:25:21 Orie: Be careful about that doing that because the spec isn't stable... editors/chairs should guide which statements we'll be testing. 16:25:55 burn: Thank you, Orie -- thank you for doing this, helpful to walk through it -- may seem obvious to some, but it's not always clear where to go. 16:26:05 burn: This was helpful to me and helpful for others, I imagine. 16:26:07 Thank you Orie! 16:26:18 rrsagent, draft minutes 16:26:18 I have made the request to generate https://www.w3.org/2020/11/04-did-minutes.html ivan 16:26:22 burn: Next item is our break -- as usual, this particular room will remain open, as will breakout room. 16:26:40 burn: Everyone be back here at top of hour... 12pm ET. 16:26:52 breakout room: https://zoom.us/j/97932508552?pwd=REFrMXF0NVBreTBhN0lzTVhYYS94Zz09 16:27:06 Thank you Manu! 16:27:20 scribe: wayne 16:28:27 oh okay thanks 16:28:29 scribe+ 16:28:40 TOPIC: Presentation - content identifier 16:34:02 selfissued has joined #did 16:34:08 present+ 16:37:04 present+ 16:45:54 Issues related to serviceEndpoints and privacy concerns which need to be addressed https://github.com/w3c/did-core/issues/382
https://github.com/w3c/did-core/issues/72
 16:46:02 https://github.com/w3c/did-core/issues/382
 https://github.com/w3c/did-core/issues/72
 16:52:21 See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9f4c7913d4_117_566) 16:52:49 guests+ Titusz_Pan 16:56:56 Hm. I thought so... 16:57:08 okay, cool. i was reading off of the agenda spreadsheet which may be out of date now 16:57:24 TOPIC: ISCC Presentation 16:57:42 See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9f4c7913d4_117_566) 16:58:23 oh, ISCC _is_ content identifier, got it... 17:01:05 brentz: Our next session is by the ISCC, we thought it would be valuable to the WG. We are joined by Titusz_Pan 17:01:12 q? 17:01:15 brentz: It's up to you if you want questions during or after the presentation 17:01:31 Titusz_Pan: I think it would be best to Q&A after 17:01:56 scribejs, set Titusz_Pan Titusz Pan 17:02:01 Titusz_Pan: This is my first contact with the DID community, I'm from Germany and an open source developer with a small business. I'm the architect and developer of the ISCC. 17:02:13 Titusz_Pan: Thanks for inviting me. Let's get started 17:02:54 Titusz_Pan: ISCC is abbreviation for international standard content code. It is meant as a universal identifier for types such as audio, video, etc. It's a lightweight fingerprint for digital content, a mix between identifier and fingerprint. 17:03:29 Titusz_Pan: It should be cross-sector applicable, such as for user generated content, meant to be used as a generalized identifier. We are planning on cross-ledger interoperability. 17:03:43 Titusz_Pan: The goal is to use these identifiers as the subjects of claims. 17:04:44 Titusz_Pan: Why are we working on this? On the Internet, content does not currently enjoy the benefit of standard identifiers. Facebook or other sites do not have identifiers for content, for example. Existing identifiers such as digital object identifiers have considerable overhead, costs, and centralization. 17:05:31 Titusz_Pan: The idea is to negotiate what an identifier means without the need for a third party, communicating "above" the identifier. Proprietary systems typically create a competitive imbalance, lock-in to platforms, etc. 17:05:49 Titusz_Pan: With DID, we are commoditizing machine-to-machine interaction, so we need to know how to talk about these things. 17:06:47 Titusz_Pan: If we have a multi-sided ecosystem, there could be an interest from any participant in the ecosystem to come up with identifiers for digital content. This is not limited to content creators, but also other users of content such as archivers, ebook distributors, or others. 17:07:11 Titusz_Pan: Authorship & copyright is not a requirement to have an identifier, but an identifier could be a requirement for authorship & copyright. 17:07:28 Titusz_Pan: We can base these on algorithms on content, such as hashes 17:08:05 Titusz_Pan: What's exactly being identified? We have 6 layers of content identification. Content is an abstract concept and we seek to deconflate the different threads composing it. 17:09:07 Titusz_Pan: We have semantic views, such as meaningful descriptions in the form of vectorized data. We may have a generic manifestations such as pixels or text. We have format-specific manifestations to a specific data type. we have exact format specifications, and also the notion of original copies. 17:10:13 Titusz_Pan: The ISCC is made of four components, hashes in the general sense, with different perspectives of the data: (1) metadata about the data and hash of that, (2) perceptual similarities of the content such as pixels for images or text for documents, (3) raw data component based on a cryptographic hash changing in an uncorrelateable fashion. 17:10:23 Titusz_Pan: We will go through each layer. 17:11:20 q? 17:11:24 Titusz_Pan: Meta-ID requires title for content, such as the filename. There is opportunity to include more details and structured formats, we want to be able to estimate similarity across content using this. We can then cluster content based on similar metadata. 17:12:02 Titusz_Pan: Semantic-ID is the identification of meaning, such as using a multi-lingual text embedding of 'king - man + woman ~= queen' 17:12:23 Titusz_Pan: We should be able to measure semantic similarity across human languages. 17:13:11 Titusz_Pan: Content-ID helps us identify content-level similarity such as two "identical" images even if they are across different data types, file formats, etc. Instead we encode information structure rather than raw data. 17:13:52 q+ to ask how Content-ID works 17:14:25 Titusz_Pan: Titusz_Pan: Data-ID does not extract the content, but only looks at the raw data and performs content-level chunking that is shift-resistant against content changes (most of the chunks will stay the same for set-similarity measurements) 17:14:30 Titusz_Pan: This lets us measure data similarity. 17:14:40 q+ to ask about the possibility of two very different pieces of content ending up with the same Content-ID 17:14:57 Titusz_Pan: Instance-ID allows us to perform merkleroot hashes over raw data, focused on data integrity. 17:15:24 q- 17:16:10 Titusz_Pan: The high level overview of creating ISCC consists of Seed Metadata from the data itself, processing based on the content using fingerprinting. We have a full implementation in Python just over 500 lines of code, and also a dockerized HTTP service so you can try it out. There are libraries to interact with the content and extract features. 17:17:13 Titusz_Pan: How does it relate to the digital object identifier used in scientific publications? They have the same prefix but then differences further in the identifier string, which may be measured against each other for similarity. 17:17:28 Titusz_Pan: It's not just an identifier for digital objects, but any assets. 17:18:16 Titusz_Pan: ISCC takes different perspectives across the layers of data for dimensions of similarity measurements. They can be used in a matrix representation, as seen on the slide. 17:19:09 Titusz_Pan: Compared to UUIDs and SHA256, ISCC brings potential semantic understanding to the identifier itself. 17:19:46 Titusz_Pan: We don't want to build a hash function that changes on bitflips, instead we're interested in a format that reflects changes to the underlying content. 17:20:16 Titusz_Pan: ISCC-ID allows us to bridge to stores such as on DLTs to bring additional context. 17:21:58 Titusz_Pan: ISSC-Code is decentralized, content-based, and similarity-preserving, while ISSC-IDs are short, unique, owned, persistent, and resolvable. We want to be able to put ISCC-Codes on blockchains, in a way that anyone can add them. The ISCC-ID contains information about the blockchain id and other deduplicating features to prevent collisions. 17:22:12 jay has joined #did 17:23:17 https://github.com/iscc/iscc-specs/issues/90 17:23:18 Titusz_Pan: We want anyone to resolve ISCC-Codes in a universal way, from anywhere. This is where we think DIDs are relevant due to their resolvability properties. We are considering a did method, but need further research. We found a potential fit after reading the did-core specification. 17:23:33 q+ to provide input on "DIDs for NPEs" 17:23:59 Titusz_Pan: This is related to existing identifier such as ISWC for digital work, and its subcategories such as recordings. 17:24:29 q- 17:24:56 Titusz_Pan: We have been approached by DIN, who brought it to ISO for standardization of the ISCC. We want to standardize the procedure and structure of the code. There is no central authoratative registry, so this is a collaboration opportunity with the DID specification and related items from this group. That's why we're here. 17:25:17 q+ to ask about semantics of DIDs for NPEs 17:25:40 Titusz_Pan: We are starting with places such as audio identifiers where there's some precedence. 17:25:41 ack manu 17:25:41 manu, you wanted to provide input on "DIDs for NPEs" 17:25:54 This is Fabulous work! 17:25:55 manu: Yes, you can use DIDs for non-person entities (NPEs) 17:26:29 manu: There's been some chat about the base58 encoding you're using, which doesn't seem to be base58btc. We're trying hard to keep base58 encoding from splitting, such as with base58. 17:26:36 Titusz_Pan: We may switch to base 32 to be case-insensitive. 17:26:41 ack wayne 17:26:41 wayne, you wanted to ask about semantics of DIDs for NPEs 17:27:03 wayne: my question is to the group, what are the semantics of resolving a DID that refers to a non person entity such as an algorithmor a content hash 17:27:11 This is indeed very interesting work. Very nice presentation Titusz. 17:27:11 ... when I find the verification method there, what does that mean? 17:27:21 q+ 17:27:53 Titusz_Pan: The idea is that I can take an ISCC code and put it on the blockchain, and it's metadata about the content. It's open and part of the metadata specification. 17:27:57 q+ to ask how to identify the different kind of fingerprint 17:27:57 q+ clarification 17:28:09 q+ to clarify 17:28:12 ack clarification 17:28:16 ack agropper 17:28:33 wayne: if I resolve an ISCC based DID and I get a public key as part of the verification method, what would that mean? is that to be defined? 17:28:51 yoshiaki has joined #DID 17:29:25 Titusz_Pan: there would be two pieces of information (1) ISCC-Code itself, and (2) a content link such as IPFS hash with extended metadata. Perhaps with license information or anything of interest. 17:29:30 q- 17:29:48 agropper: How does this interact with stenography? 17:30:02 Titusz_Pan: There is no relationship or information encoded, but they're agnostic. 17:30:04 ack jay 17:30:04 jay, you wanted to ask how to identify the different kind of fingerprint 17:30:19 multihash! :) 17:30:21 jay: Regarding fingerprint, if ISCC supports several types of fingerprinting, how do you know which fingerprinting is used? 17:30:59 Titusz_Pan: You query the metaregistry to determine this about the content. You won't get a 1-1 mapping, but multiple views from multiple parties. 17:31:24 TOPIC: Equivalent Identifiers 17:31:33 See [slides](https://docs.google.com/presentation/d/1RoE8E4y8S1j65EJaXZ8oihkduNbjTXXvdwtkzw961Xw/edit#slide=id.g9b7a7df111_1_129) 17:31:45 brentz: Moving on to Daniel Buchner, q&a during or after? 17:32:03 burn: this doesn't need to be 60 minutes 17:32:08 Daniel_Buchner: after 17:32:55 Daniel_Buchner: Not all forms of equivalence are created equal. We will examine the Ship of Theseus. You can change anything in your DID document over its lifetime. At the end... 17:33:21 Daniel_Buchner: pls update slides 17:33:23 burn: ok 17:34:19 Daniel_Buchner: T0 I could have created a unique DID document, but in T3 every "plank" of the document could have been changed in Theseus' did document 17:34:57 Daniel_Buchner: Even in T3, if the document looks exactly the same, we can distinguish the two through using the process. DIDs can change entirely over their lifetime (via documents). 17:35:01 I would argue that the DID would still be different across any two DID documents. 17:35:12 Yes, agree with Drummond. 17:35:33 (that is, fundamentally, how you know one thing from another) 17:35:47 Daniel_Buchner: DIDs are not URI entries of an exact form 17:36:16 Daniel_Buchner: A logical and deterministic process is able to determine a logical entry with several valid inbound logical inputs to form the entry. 17:36:37 Daniel_Buchner: Can many forms of a DID string identify the same DID? I think yes. 17:37:08 Daniel_Buchner: alsoKnownAs is present already in the spec. sameAs/formOf, and canonical/preferred may be candidates to add. 17:37:31 Agree, a DID is an identifier whose controller is explicit and clear, cryptographically. What the DID, or DID Subject, "means" is in the eye of the controller. 17:37:32 Daniel_Buchner: Are these related? They serve as investigatory hints. 17:37:57 I like "formOf" much more than "sameAs" 17:38:05 s/Agree/Agree manu/ 17:38:18 I like the opposite, Drummond :P 17:38:24 Daniel_Buchner: sameAs/formOf are exactly logically equivalent identifiers, determined to be so and filtered for by the method, such that Theseus' DID and the hash are referring to the same logical entry. It provides awareness of variants, update support for new formats such as base58 to base32. 17:38:26 (for the definition provided) 17:38:44 Daniel_Buchner: Only the method can determine this, through resolution. 17:38:59 q+ 17:39:53 Daniel_Buchner: We have a separate one canonical/preferred, and it's different that it's a singular value, which encourages you to modified your held references and possibly gain new awareness going forward. It supports method evolution and signals for migration processes. We are ensured that only an exact logical equivalent is populated. 17:40:00 Daniel_Buchner: Q&A? 17:40:06 ack jonathan_holt 17:40:23 q+ to "we can always do this via DID Spec Registries" 17:40:49 jonathan_holt: It depends on how you do the resolution. If one did string is base64 and another is base32, you still only have the same document. You may be able to use an array of sameAs... 17:41:13 Daniel_Buchner: I would assert we have a bit of freedom here across formats after resolution. 17:41:14 q+ to ask about multiformat/multihash 17:41:16 ack manu 17:41:16 manu, you wanted to "we can always do this via DID Spec Registries" 17:41:21 q+ 17:41:58 q- 17:42:51 q+ to speak in favor of the use cases for both of these proposals 17:43:08 manu: From a high level, I want to assert that we can always do this through the DID spec registries. You've been pushing for these features for the sidetree ION work, and it makes sense how it's relevant to that. However, if the question is if we put it into did-core or not, I want to underscore that these values can always go into registry so no one is blocked. The other point is that we talked about sameAs 17:43:15 and its security implications, but the change is if the DID method can assert sameAs using metadata, that's a perfectly reasonable thing for the DID method to do. The ledger should know if two DID documents are the same thing or meant to be hte same thing . 17:43:18 q+ to mention additional requirements on DID methods/trade offs with consumer usage 17:43:55 manu: The canonical/preferred item seems to be a requirement in layer 2 where the ledger is slow. They feel hacky, but I understand why they must exist due to requirements. 17:45:28 Daniel_Buchner: The underlying need here is that in any system that must lead to centralized constructions, such as bitcoin, time is the difficulty. In some methods such as sidetree-based ones as IONs, you can create a DID instantaneously on your client that are immediately usable. The DID itself is a URI string of the initial base patches across time. 17:45:38 Yes, but would you need that feature if the ledger had finality within seconds? I'd argue that you don't. 17:45:54 The need here is because the underlying ledgers are slow. 17:46:15 (which is reality, and is fine, and is why I'm not completely against sameAs being asserted by the DID Method/Ledger) 17:47:04 Daniel_Buchner: It's still resolvable because if you hand it to a method, they can automatically resolve it. They check the underlying records for existence or mutations. The issue that arises is that whenever an anchoring occurs, people may want to use a short form. So we want a way across all DID method to allow specification of logical equivalences across these different string representations. 17:47:07 q 17:47:14 ack markus_sabadello 17:47:15 Daniel_Buchner: That's what this is in service of. 17:47:34 markus_sabadello: Confused about this: canonical vs. alsoKnownAs 17:48:05 ack drummond 17:48:05 drummond, you wanted to speak in favor of the use cases for both of these proposals 17:48:06 markus_sabadello: Seems to be semantically something else, don't have a strong opinion about whether it should be DID core. Kind of agree with manu about unblocking, but see a universal applicability. 17:48:08 dbuc has joined #did 17:48:37 present+ 17:49:39 drummond: I think it has to be in did-core to allow methods to ensure exact logical equivalences are populated. This is a requirement on DID methods, therefore it must go into did-core. In OASIS and other groups, we found the need for canonical and sameAs come up over and over again. We didn't need alsoKnownAs because it's a weaker form. dbuc should come up with the PR as soon as possible. We also need to make 17:49:45 ack dlongley 17:49:45 dlongley, you wanted to mention additional requirements on DID methods/trade offs with consumer usage 17:49:45 sure the DID method requirements section includes the assurance text. 17:49:47 q+ 17:49:50 q+ 17:50:24 ack dbuc 17:50:28 dlongley: We should have requirements, consumers must check the value upon use, or we place a requirement on DID methods to determine whether you accept the value from controllers or not. 17:50:29 by_caballero__juan has joined #did 17:50:38 present+ 17:51:04 I agree with Dave that this is the "tax" of supporting verification of sameAs or canonical values. 17:51:30 q+ on security repercussions. 17:51:38 it's more complicated than just trying the method -- the method must have knowledge of these properties (or blanket disallow properties the DID method does not understand) so that you *can* trust them 17:51:47 s/trying the method/trusting the method/ 17:52:24 I'm hoping Daniel is referring to the new, decentralized "DTwitter" :-) 17:52:33 wait wait. that's a DID migration use case, which is very different than this formOf or sameAs... 17:52:37 dbuc: A lot of methods might not even have this nor use it. It acts the same across all of them that use it, but some methods wouldn't ever populate the field. Assurances are the same across methods. There's another interesting thing, being able to create lots of IDs for a person, mostly pairwise shielded, but one or two purposefully used across contexts such as twitter and instragram. I want people to know 17:52:38 q+ 17:52:40 ack wayne 17:52:43 it's my common DID. A DID could have to live for 50 years, so the methods need to get it perfect off the bat. If there's no in-built means to "move you over" then. There are a lot of features for security. 17:52:47 q+ 17:52:51 q+ 17:53:04 wayne: the equivalence criteria seems to be an enablement of different representations of a DID that are logically equivalent after you go through the DID method 17:53:15 ... i might have some ietf json patches that ar esigned that are jwt encoded and they're part of the did itself 17:53:28 ...this might be logically equivalent to one that is anchored with rotations back onto a ledger and they technically refer to the same thing 17:53:36 ... so we should be able to sue them across contextts 17:53:47 ... an alternative is to look at the resolution metadata param that is passed into did resolution as a place to include these updates 17:53:49 q+ 17:53:56 ... its separate because you would have a DID stand the test of time but also specify updates during resolution 17:54:00 ... have you considered this approach? 17:55:23 Daniel_Buchner: we have security concerns about this approach when using anciallary metadata that has the potential to be omitted on accident to ill effect. You could also have methods in OpenID for porting schemes at 2nd and 3rd layers, but it increases the complexity of more systems and actors, which adds difficulty and even 'transport' level operations. 17:55:27 ack manu 17:55:27 manu, you wanted to comment on security repercussions. 17:55:32 also allows for stuff like did:example:xxx --> did:example:xxx-yyy 17:56:08 Wherein you could add extra segment parts to do more things for faster resolution and other things as the DID Method evolves 17:56:25 manu: Wanted to raise some security reprecussions, agree with dlongley, if we implement this stuff, it has to be implemented across all did methods, it's super dangerous if only handful of these did methods implement these. I was feeling better about it when we were saying it's the DID method expressing these things, but at the document level there is new security concern. 17:56:30 DID Methods that have no code for it would just not populate this 17:57:06 The Method obviates that 17:57:13 because these are tied to the same security assurance 17:57:14 manu: for canonical, if you don't have a backreference, you can be attacked. if i wanted to attack dbuc, i may set up an account that does illegal things on the internet and reference it to him. We must acknowledge that canonical is bidirectional. 17:57:22 IMO, the choices are: 1. consuming `canonicalBikeshed` values means you MUST check the method to see if it's supported, 2. require all DID methods to properly validate or disallow values for `canonicalBikeshed` 17:57:22 q+ to point out the same thing Daniel is about to say 17:57:24 can the DID Method populate the field in the DID Document? 17:57:57 ack dmitriz 17:58:00 manu: The canonical entry itself can change leading to complex scenarios rife with security concerns. I retract what I said before, there actually isn't necessarily a way to do this in DID spec registries. all methods must do this or face security ramifications. 17:58:06 You will have far scarier issues if you tell users they have to do this sort of thing out of band across N transport/handshake protocols 17:58:29 and other types of DID Methods 17:58:30 dmitriz: I just want to be sure we're not talking about DID migration. 17:58:54 brentz, if the DID method knows about the field, yes, but if it doesn't, we could have trouble, depending on our consumption rules 17:59:03 dmitriz: It's a different thing if i'm migrating from ledger 1 to ledger 2. There's an implication that canonical can address this, but i want to make sure we are clear that this is out of scope. 17:59:16 dmitriz: How do you imagine did methods validating canonical or formOf 17:59:16 ack markus_sabadello 17:59:32 dbuc, hrm, well, LD Security already does this "out of band" across N protocols... or rather, there is a bi-directional protocol for this. 17:59:46 dlongley, so this really needs to be defined in DID Core? 18:00:18 q+ to say "oh wait, this is just a variation of the `controller` pattern."? 18:00:24 brentz, see my comment above about our choices: it's either DID core (all methods must handle the property by validating or disallowing it) or the consumption rules require the consumer to check the DID method to see if it supports the property or not 18:00:27 It would be a nightmare for RPs and users to have to dance like this, and if there's any urgency involved, lord help you 18:00:32 @brentz / dlongley - the implication is more, that it /can't/ be in DID Core. since each different did method validates it differently 18:00:39 +1 markus 18:00:39 markus_sabadello: Related to manu's comments on security implications, just wanted to say during our metadata discussion, we had some properties such as created or updated timestamp with the same meaning, but dependent on the did method if the values are guaranteed by the method or self-asserted by the controller. At that point, we decided not to differentiate this yet. Right now, we don't have different names 18:00:43 ack agropper 18:00:44 If they had to talk over active conduits, I mean 18:00:45 or buckets for properties on this basis. If we follow this pattern, we could register this either in did-core or spec registries. It would depend on how it's guaranteed. 18:01:09 As the type param, which it does not 18:01:11 which type had :D 18:01:19 yoshiaki has joined #DID 18:01:19 this is not commingling different logical IDs 18:01:29 it does not do that 18:01:49 No, this does not have the same privacy issues as 'type' or any other privacy-violating properties 18:01:52 agropper: It sounds like this has the same privacy implications as the type discussion around DIDs in that it expands the privacy attack surface, opening us up to unintended consequences. Can we do this outside of putting it in did-core? We should do it that if possible even if it adds friction. 18:02:06 This is all about the same Logical ID 18:02:09 q+ to ask what a concrete proposal may be 18:02:16 0 deviation of that 18:02:33 hmm, ok. 18:02:35 agropper: I also raised the issue of allow lists for methods, and depending on the implementation thereof, then it's fine. 18:02:58 ack dbuc 18:03:01 agropper: If we're doing something to cause people to raise their eyebrows at dids as a whole, then reject 18:03:42 dbuc: The security implications are not the same as type. s/security/privacy/, if I give you another string identifier with the same logical reference, then it's exactly the same thing. 18:04:00 q+ to respond to Daniel 18:04:39 q+ to say what daniel just said isn't true 18:05:03 q+ to say a DID method must either know about this property or the consumer must know if the DID method does or not 18:05:12 dbuc: If methods can't perform the requirements, then they can simply decide not to implement this. You don't need to be encumbered by this if you don't want to support it, it won't change the document in that case. If you trust the method to resolve the ID, then you can trust it to do this. 18:05:18 dbuc - got it, thanks. 18:05:26 dbuc: Spec text will be clear about what is allowed or not. 18:05:28 so, this is very clearly not cross-ledger 18:05:32 which is good 18:05:32 ack drummond 18:05:32 drummond, you wanted to point out the same thing Daniel is about to say 18:05:42 but now sameAs is a bad name :P 18:05:49 Eugeniu_Rusu has joined #did 18:06:07 drummond: responding to agropper, the new thing is that the method must ensure that only exact logical equivalences are populated. 18:06:10 manu - I thought the term being proposed was 'formOf', not sameAs? 18:06:28 the slide says sameAs / formOf 18:06:31 and I don't like formOf :) 18:06:42 Manu: i have no idea about the naming 18:06:46 don't care so much about that 18:07:06 If you want bananaOctpusEquivalent, I am down 18:07:14 drummond: because you're only asserting the equivalence that an existing did is there....because a method can assert the use of one or both of these properties, the resolver code should be able to verify this for anyone who needs it. these expressly cannot be used for migration across methods. it's possible then that the property names can capture the constrainted meanings, such as putting 'logical' explicity 18:07:15 I prefer bananaOctupi 18:07:20 in front of them. 18:07:26 ack manu 18:07:27 manu, you wanted to say "oh wait, this is just a variation of the `controller` pattern."? 18:08:25 q+ 18:08:41 I still believe we must define these properties in DID Core so that we can state the requirement that a DID method that uses either of these properties MUST only allow an exact logical equivalent. 18:08:49 manu: Now we are back to being able to do this in the spec registries. I thought canonical was a mechanism for cross-ledger, but it is expressly not for that. It's only for a single did method without the ability to point outside of the ledger, which makes it safer and easier to use. Because there is no cross-talk, we can let this play out on its own timeline, in spec registries as opposed to did-core, while 18:08:50 ack brentz 18:08:50 brentz, you wanted to ask what a concrete proposal may be 18:08:54 Yes, agree with drummond 18:08:55 still achieving the desired goals without adding to the spec authors' burdens towards CR. 18:08:58 brentz: what is the concrete proposal? 18:09:13 +1 Brent 18:09:13 I believe it is that exact logical equivilence requirement that makes it safe from a security standpoint. 18:09:25 ack agropper 18:09:25 agropper, you wanted to respond to Daniel 18:09:28 brentz: we have alsaKnownAs, sameAs/formOf, canonical/preferred. all of these could solve problems. What do we want to happen here? 18:09:41 q+ to talk about PRs 18:10:10 agropper: given drummond and manu's responses, it only applies to dids and is entirely within a single method. If people put this in, and FISMA deems it a risk, then they would just disallow the specific method. 18:10:12 ack dlongley 18:10:12 dlongley, you wanted to say what daniel just said isn't true and to say a DID method must either know about this property or the consumer must know if the DID method does or not 18:10:19 Yes, Adrian, you heard me correctly 18:11:29 I agree with Dave about these security concerns 18:11:36 dlongley: thinking about this in terms of writing code to consume this property. DID methods are aware of this and specifically prohibit it, or consumers know about it and prohibit it. If we allow methods to arbitrarily allow this as a property, then it could be used to deceive a consumer of did-web for example to misunderstand the relationship. We must be explicit for did methods in the acceptance or 18:11:42 rejection of these properties. 18:11:46 A did:web resolver would blow those away 18:11:58 q? 18:12:05 dlongley: software that resolves dids must now look into the did method to understand the implications, or the did methods must be required to address this. 18:12:07 ack dbuc 18:12:39 +1 to what dlongley said. either a) it's in DID Core, in which case /all/ DID Methods have to process it. or b) it's in registries, and only methods that need it use it. But not a + b 18:12:56 dbuc: to maintain the best security, i think we must include this in did-core to ensure enforcement of these requirements. people would be less vigilent 18:13:03 ack drummond 18:13:03 drummond, you wanted to talk about PRs 18:13:45 I have one PR, which may need some mods, and another for canonical 18:14:10 drummond: In terms of next steps, I agree with dlongley. The key is that there are attacks. There are 3 parts to it: dbuc will sign up to submit PRs, definitions of the properties, update to the DID method requirements referring to those constraints. That's why it has to go into did-core. We must also add a security consideration to cover that. dbuc must sign up for those PRs and quickly. 18:14:19 q+ to warn of upcoming objection to putting it into DID Core, probably -- lack of implementation experience, scary security stuff, etc. :( 18:14:25 dbuc: sameAs/formOf exists as a pr, i can generate one for canonical/preferred 18:14:26 i don't see how this works with did:web at all ... since the DID Doc contents are entirely under the control of the DID controller 18:14:28 ack manu 18:14:28 manu, you wanted to warn of upcoming objection to putting it into DID Core, probably -- lack of implementation experience, scary security stuff, etc. :( 18:14:43 q+ 18:14:50 I would probably just leave the current id prop language then 18:15:02 q+ 18:15:11 ack jonathan_holt 18:15:13 manu: feeling nervous about this PR because of timelines, security ramifications, implementation learnings. I am very concerned that a bitcoin/ethereum ledger needs but other ledgers don't need. Perhaps even only sidetree needs it. 18:15:23 +1 18:15:27 jonathan_holt: It'd be great to have a process to manage security concerns and threat vectors. 18:15:37 i guess did:web resolver software needs to reject DID docs with that property as entirely invalid (can't just drop the property if did:web DID Docs are signed). 18:15:48 brentz: Our process is to use github issues and raise concerns there. 18:16:06 ack dbuc 18:16:27 dbuc: any system that is robustly decentralized will encounter these issues. 18:16:46 You can have a decentralized system that has fast finality w/o needing this feature :) 18:16:47 -1 to presuming we know how all decentralized technology works :), it just depends on how fast consensus is 18:17:09 dbuc: It's not just sidetree, but anyone with a deterministic initiating form and wants to modify the form. If it's not in did-core, then we may be rejecting the entire thing. 18:17:14 q+ 18:17:23 ack agropper 18:17:28 Agree -- for example, here are examples of decentralized systems w/ fast consensus times: Hashgraph, Sovrin, Veres One, Hyperledger Fabric, etc. 18:17:37 So, it's not true that you will always hit this issue 18:17:45 agropper: NIST writes a lot about derived PIV credentials. Is that potentially helpful? 18:17:46 q+ 18:17:50 also, I'm not saying we can't do the work here -- I'm saying that it will be a non-trivial lift. 18:17:52 ack dbuc 18:17:57 and this is asking the WG to do a bunch of work. 18:18:27 dmitriz : yes potentially. github issues might be good for now, but we should make a process that is well documented 18:18:30 FIPS201-3 is the PIV and Derived PIV document that agropper is referencing: https://pages.nist.gov/FIPS201/ 18:18:44 @dbuc - sign it with the same key in the DID? that's the typical way to bind stuff, out of band... 18:19:03 just wanted to add -- even if slow consensus ledgers, you don't need this property unless you need more than just key material in your DID Document (e.g., you need service endpoints from the beginning) 18:19:10 s/even if/even with/ 18:19:24 https://content.govdelivery.com/accounts/USNIST/bulletins/2a9c676 18:19:25 dbuc: If it got pushed out of did-core, then it's effectively a NOOP. The big issue of doing this out of band, is that I don't know how to do it out of band. If I have a did in form a and it must be in form b, then i go back to the rp who i gave form a, and i wanted to communicate that it's now form b. how do i prove that they are equivalent? if i don't have the method, the arbiter of logical equivalence, how 18:19:31 do i do this? dual resolution and similartity checking? 18:19:36 dbuc: it becomes a quagmire if we do it out of the security basis of the method. 18:19:40 q? 18:19:46 q+ 18:19:51 ack dlongley 18:19:51 q+ to talk about PIV if anyone wants... 18:20:29 q+ 18:20:43 ack justin_r 18:20:43 justin_r, you wanted to talk about PIV if anyone wants... 18:20:44 dlongley: there are other did methods that can securely create things that might take time to come to consensus. for cases where consensus takes a while, the things that would not be supported are arbitrary service endpoint updates. if you can communicate them out of band, then you can do this securely even with slow consensus times 18:21:45 dmitriz: looks like we do have a issue tag "security-consideration", but perhaps a template for keeping track of them before they become a CVE 18:21:48 justin_r: just to respond to agropper, FIPS-201r3, i am a coauthor and published this week. the important thing about derived credentials, dealing with smart cards and related accounts for us feds, is that derived credentials do not necessarily need to be cryptographically derived from the same kind of keys, this linked relationship without having to proved the posession of the whole chain of keys is important 18:22:02 q? 18:22:06 ack dbuc 18:22:18 justin_r: we created this notion of an underlying account that these keys are attached to, differing from the previous notion that "everyone gets a credential and that's the end of the day" 18:22:35 s/everyone gets a credential/everyone gets a certificate/ 18:22:42 dbuc: we hope to make the language more secure to say that the property must have logical equivalence 18:23:04 q+ 18:23:05 justin_r: thank you for the correction 18:23:09 It feels stronger to have it explicit using these proposed properties. 18:23:13 I'm aware of the language :) 18:23:13 ack markus_sabadello 18:23:24 https://w3c.github.io/did-core/#did-subject 18:23:25 wayne: i said that, not justin ^ the thanks for correction 18:23:30 +1 for the language in the spec being updated first 18:23:48 https://www.w3.org/TR/did-core/#alsoknownas 18:23:57 https://www.w3.org/TR/did-core/#did-subject 18:24:01 markus_sabadello: there are existing tests around that the resolved DID must match the id in the document, would prefer this requirement is reflected in the spec. 18:24:06 q+ 18:24:17 But if we go back, that throws Daniel's use case back out again? 18:24:34 I'd be -1 for that 18:24:42 If we take that out, Daniel is back to having no solution 18:24:45 right? 18:24:49 yep 18:24:51 q+ 18:24:54 ack brentz 18:24:59 ack drummond 18:25:09 brentz: In the pasted link about did subject in IRC says a requirement for resolution of identifiers in a note 18:25:49 drummond: I have been uncomfortable with that switch, we should have really clear rules around these terms such as sameAs/canonical/etc. and clear usage requirements for methods 18:26:34 brentz: sent an email for the ADR session tomorrow, please check 18:26:49 Yup, 5 mins should do it. Oops, down to 4 mins ;-) 18:26:49 brentz: thank you all for coming, especially those in weird hours 18:26:57 brentz: pls scribes for tomorrow 18:27:26 s/:0/:D/ 18:27:29 rrsagent, draft minutes 18:27:29 I have made the request to generate https://www.w3.org/2020/11/04-did-minutes.html ivan 18:27:44 zakim, end meeting 18:27:44 As of this point the attendees have been burn, justin_r, ivan, brent__, dlongley, drummond, manu, rhiaro, shigeya, markus_sabadello, kristina, orie, agropper, adrian, J-Y, Rossi, 18:27:44 regarding ADM, easy just look at: https://github.com/w3c/did-spec-registries/pull/138 18:27:47 ... identitywoman, Michael_Jones, jonnycrunch, Eugeniu_Rusu, YueJing_, jonathan_holt, selfissued, dmitriz, dbuc, by_caballero__juan 18:27:47 RRSAgent, please draft minutes 18:27:47 I have made the request to generate https://www.w3.org/2020/11/04-did-minutes.html Zakim 18:27:49 I am happy to have been of service, ivan; please remember to excuse RRSAgent. Goodbye 18:27:54 Zakim has left #did 18:28:49 rrsagent, bye 18:28:49 I see no action items