23:02:47 RRSAgent has joined #did-topic 23:02:47 logging to https://www.w3.org/2021/01/19-did-topic-irc 23:03:01 markus_sabadello has joined #did-topic 23:03:04 brent has joined #did-topic 23:03:05 Meeting: DID Special Topic Call 23:03:06 present+ 23:03:08 kdenhartog has joined #did-topic 23:03:09 present+ 23:03:12 present+ 23:03:14 present+ 23:03:16 present+ 23:03:24 rrsagent, make logs public 23:03:31 rrsagent, draft minutes 23:03:31 I have made the request to generate https://www.w3.org/2021/01/19-did-topic-minutes.html manu 23:03:36 present+ 23:03:49 scribe+ 23:03:52 brent: Welcome all -- this is a working session. 23:04:02 tplooker has joined #did-topic 23:04:16 present+ 23:04:29 q+ need feedbacks on diagram on issue# 453 23:04:44 https://github.com/w3c/did-core/issues/453 23:04:48 ack shigeya 23:04:54 Happy to backup scribe if need be manu 23:05:08 shigeya: I have a drawing, need feedback 23:05:30 burn has joined #did-topic 23:05:41 present+ 23:05:50 shigeya: original concern I had was with original image 23:06:54 shigeya: the image in the document today mixes data relationships -- trying to create relationship between VDR and DID Document, and also try to clearly differentiate functionality and data relationship -- know that there is a discussion going on between resolution/dereferencing -- how to draw this might be debatable. 23:07:16 drummond has joined #did-topic 23:07:21 present+ 23:07:26 shigeya: is the relationship clear? 23:07:28 q+ 23:07:29 q+ 23:07:35 ack manu 23:08:20 manu: We're showing data and systems. Maybe what's missing here is the resolver, I think it was in the previous diagram but not this one. The question is what are we trying to show here. 23:08:53 manu: In the VC data model, we only showed the entities and information. But this is more like concepts. The big challenge is we're mixing conceptual stuff with entities. It may be best to create two different diagrams. 23:09:26 yeah thanks markus apologies had to step away for a second 23:09:27 q+ 23:09:36 ack drummond 23:09:46 shigeya: yes, I was thinking in that way too -- responding to manu's comments -- can we have more than one diagram? 23:10:02 manu: Yes, anything that improves the specification is fine. 23:10:14 shigeya: for this diagram, I'm trying to replace the diagram if possible... 23:10:20 shigeya: we may need more diagrams 23:10:26 q? 23:10:41 drummond: The reason I agree with that is I spent time w/ Amy on developing the diagram - about as accurate as we could get at the time. 23:10:56 drummond: If there is additional information, additional diagrams would be good. 23:11:00 ack justin_r 23:11:20 justin_r: Yes, somewhat of a metapoint about big diagrams... with this many layers, it's difficult for someone looking at it to figure out what they're supposed to be getting out of it. 23:11:50 justin_r: It's often beneficial to decompose layered diagrams into multiple diagrams w/ accompanying text... not to say it's easy, visual design is difficult to pull off. 23:12:17 justin_r: With some NIST documents I've worked on recently, we've been able to split into multiple diagrams that tell one part of the story - those seem to have been better received. 23:12:26 justin_r: DID URL and Resources might be different story. 23:12:36 q? 23:12:45 justin_r: multiple related pictures might be beneficial here. 23:13:09 shigeya: Yes, getting more and more difficult -- leading discussion -- last weeks special call, seems to be difficult to think about this. 23:13:27 JoeAndrieu has joined #did-topic 23:13:38 shigeya: I will try, but if I fail to capture it, I'll fall back to the original one... not touch the current figure - we'll see how much progress I can make. 23:14:05 brent: Anyone else have any PRs that they're struggling with? 23:14:14 https://github.com/w3c/did-core/pull/457 23:14:22 Topic: Persistence 23:14:29 https://github.com/w3c/did-core/pull/457 23:16:01 ( Follow-up to the discussion on #453, this is the current version for the reference: https://github.com/shigeya/did-core/blob/shigeya-453-diagrams-work/diagrams/did_architecture_overview-work1.png -- I will put the link to the issue ) 23:17:02 drummond: This is the current note on persistence -- previewing 23:17:39 drummond: Taking in content from Kyle... 23:17:44 drummond: would like feedback from Joe 23:17:50 q? 23:18:38 TallTed has joined #did-topic 23:19:12 Joe: I have issues with this language, going back to XDI, IIW, Rebooting/elsewhere -- DIDs are not bound permanently to anything, and I think it's going to be a big issue to talk about DIDs in this fashion -- you might as tattoo a number to your neck or implant a microchip. 23:19:35 JoeAndrieu: Any DID I use, shouldn't be permanently bound to me, language has been rooted undermines the point as to how many of us are here. 23:19:56 present+ 23:19:58 brent: Would it be fair to say you support getting rid of this note? 23:20:37 JoeAndrieu: I think we should go further -- all identifiers can't be bound permanently -- we need to explain how this creates security problems on how this particular identifiers? 23:20:47 drummond: Have you read this PR? 23:20:54 JoeAndrieu: Yes, "permanently bound" is the issue? 23:21:37 drummond: Can I try to explain how this takes your viewpoint into account. 23:21:51 JoeAndrieu: Well, I wrote text, but it wasn't incorporated. 23:21:56 change "permanently" to "persistently"? 🤷‍♀️ 23:22:01 q? 23:22:32 brent: Current DID Core spec has a note on persistence -- Drummond is trying to fix it to address concerns that have been brought up. 23:22:37 q? 23:22:40 brent: new text feels like an improvement. 23:23:01 ^ worth discussing that proposal justin_r it is a note on persistence at the end of the day 23:23:05 q+ 23:23:19 brent: Drummond has proposed some text to improve things, let's try to assist with concrete modifications. 23:23:27 q+ 23:23:33 ack drummond 23:24:56 drummond: Different point of view - I appreciate use cases for people and need for best privacy features we can provide - herd privacy, etc. There are other use cases, DIDs for information use cases -- software, IoT devices, security architectures around assumptions or policies on subject/call. DIDs were originally URNs, all persistent identifers, we moved away from that. 23:25:11 There's an entire conference about persistent identifiers! Next week! https://pidapalooza2021.sched.com/ 23:25:32 drummond: Original note said that, we revised it to say what it says in green - if you need, as DID Controller, your policy is to have a permanent binding, architecture of DID infrastructure, DID Method you would choose, would support that (but not required). 23:26:02 q+ to recommend a change and a location 23:26:09 drummond: It's up to their policieis, did my best to reflect that -- want to make it clear - permanent binding, there are use cases for it -- don't know why that end of the spectrum isn't provided. 23:26:11 ack ChristopherA 23:26:18 q+ to provide a viewpoint -- default position. 23:26:42 ChristopherA: I may have different concerns than Joe on this -- I think I'm in general more skeptical in last year "someone needs it so we need to add it in" 23:27:03 q+ 23:27:07 ChristopherA: I'm skeptical right now, don't understand Joe's argument enough to make a concrete suggestion -- maybe Joe needs a PR? 23:27:13 scribe+ 23:27:17 brent: This is the only PR currently. 23:27:22 ack brent 23:27:22 brent, you wanted to recommend a change and a location 23:27:53 brent: Recommend a possible -- some use cases may expect a DID to be persistent, a DIDs ability to continue to identify the same subject is a function of... 23:28:07 q+ 23:28:09 brent: the persistence of a DID depends on DID Method infrastructure -- first suggestion. 23:28:09 q+ 23:28:23 brent: second suggestion, seems like this note should go in security considerations section. 23:28:34 present+ jonathan_holt 23:28:34 drummond: Shigeya was recommending something to that effect. 23:28:37 ack manu 23:28:37 manu, you wanted to provide a viewpoint -- default position. 23:28:39 +1 to security or privacy considerations section 23:28:52 q+ to ask I'm actually more concerned about the permanence of the subject. 23:29:25 manu: Im trying to hear what joe and drummond are saying, I think it may come down to a default way of thinking about dids and there are two ways being discussed right now 1) dids are permanent (bound permanent) 2) dids are ephemeral 23:29:38 ... we can do alot of variations between these two 23:29:42 q+ 23:30:01 q+ 23:30:06 possible new first line text: "Some use cases may expect a DID to be persistent. However, a DID's ability to ..." 23:30:30 ... If I am understanding joe correctly, he is trying to ask what is the default model we should be thinking e.g permanent or ephemeral 23:31:32 ack markus_sabadello 23:31:33 ... the difference here is in the assumptions around the binding for example do you get to assume without checking a did is continually bound to one subject 23:31:52 q+ 23:32:15 markus_sabadello: A bit surprised permanence and persistence is so negative and harmful -- in beginning, intention was -- DIDs are persitent in sense that they cannot be taken away from you unlike domain names. 23:32:18 q- 23:32:27 +1 to markus 23:32:29 markus_sabadello: It's an identifier that no one can take away from you 23:32:41 q+ to discuss the difference between the permanence of an identifier vs the permanence of its binding 23:32:55 markus_sabadello: Maybe what we forgot to point out was that you yourself could do that -- controller could change persistence and permanence -- this is what drummond might be clarifying with his PR. 23:33:03 ack justin_r 23:33:04 markus_sabadello: Positive aspect to Drummond's PR. 23:33:39 justin_r: The best way to frame this, suggestion to moving to security/privacy -- might be in dealing not with nature of technology itself, but the problems come from correlation which happens next to the technology. 23:34:18 justin_r: It's not that a DID identifier is the same person over time, as much as it's "this specific person" and "I can figure out who that specific person is" -- even on impermanent systems, timebox and correlate to external party -- I can figure out who it is. 23:34:41 justin_r: I like moving it down to considerations and promoting it out of a NOTE -- hopefully in order to bring it up in an external context. 23:34:47 ack ChristopherA 23:34:47 ChristopherA, you wanted to ask I'm actually more concerned about the permanence of the subject. 23:34:51 q? 23:35:16 ChristopherA: I guess I feel like we're conflating a number of different things - I like Markus' point, persistence -- it couldn't be taken away from you for as long as you want it. 23:35:39 ChristopherA: Worried that single word "persistence" has issue since it goves over multiple things. 23:35:54 ChristopherA: Permanently bound to a subject, having that be the default assumption kinda scares me on a number of levels. 23:36:30 ChristopherA: Especially when one of those subjects might be a person - DID initially about a service... well no, now is about person who has control over service... well, no it's the heir that inherited it... and then ultimately, there isn't a subject. 23:36:44 ChristopherA: "Bound to subject" sounds permanent, which I also don't like. 23:36:46 ack drummond 23:37:25 rgrant___ has joined #did-topic 23:37:51 drummond: I want to reinforce, although manu characterized it as "DIDs are permanent" -- we did start there, that's no longer true -- I tried to clarify that -- even if DID Controller wanted it to be permanent, that DID Method might not support that. 23:37:52 q? 23:37:55 agropper has joined #did-topic 23:38:03 drummond: I'm definitely convinced it should go to security considerations. 23:38:11 present+ 23:38:57 drummond: I'm taking notes -- one of the primary needs for URNs, reference in security architecture are to same subject... one of the challenges, URN community has always acknowledged, RFC8141 to acknowledge no technical way to ensure permanence... global uniqueness, no technical way to maintain the binding, always the operational and dependent on policies of different parties. 23:39:31 drummond: I'm no longer saying "persistence is default assumption" -- it is important to say "architecture supports" -- if you need persitence -- choose a method that supports it... or if you don't want that, that's fine too. 23:39:43 q+ have we discussed undeletable-but-narrowly-shared as a thing not ephemeral and not persistent? 23:39:54 q+ 23:40:06 drummond: Policy should be keep checking on the binding, but if you want a policy in place -- did is permanent -- architecture/ecosystem where things don't change -- you can program that they're not going to change/assume they don't change. 23:40:10 ack jonathan_holt 23:40:13 q+ to as have we discussed undeletable-but-narrowly-shared as a thing not ephemeral and not persistent? 23:41:23 jonathan_holt: I can see the dilemma on both sides - but mostly siding w/ Joe -- concern is w/ correlation and use for nefarious purposes -- persistence of the DID, same identity over same time -- function of DID Controller, not their policieis... cross check association is function of Verifiable Credentials tying together different attributes/identifiers/assertions/credentials. 23:42:01 jonathan_holt: What this is trying to do is make the association at DID to DID Subject risky -- for example, w/ my kids -- have @me.com email addresses -- but I was controller, but they are the DID Subject, but that DID Subject may change over time. 23:42:12 ack tplooker 23:42:12 tplooker, you wanted to discuss the difference between the permanence of an identifier vs the permanence of its binding 23:42:42 tplooker: Just a quick note - in general, we're using persistence almost interchangably even though to me they meand different things... Persistence and permanance of something, an identifier vs. a binding... which is identifier binding to abstract subject. 23:43:24 +1 to tplooker 23:43:24 q+ 23:43:24 tplooker: The language around the binding is problematic, drummond your point that update to RFC that you cited, essentially infeasible to guarantee persistence over time... we shouldn't say that's possible, we should scope this about persistence of identifier itself rather than around the binding. 23:43:30 ack JoeAndrieu 23:43:32 q+ to ask a question -- what use cases are at risk? 23:44:39 JoeAndrieu: I like how Manu phrased the discussion, I think he captured the essence of it -- I'm concerned about the language Drummond is using... I would posit there is not DID Method that provides proof of control and permanance with out biometric (fingerprint, DNA, etc.). 23:44:46 q+ to remind Joe that DIDs are not just for people 23:45:13 +1 to JoeAndrieu, the assumption of the policy is the problem 23:45:39 JoeAndrieu: Drummond is saying if you have a policy in place where you can assume permanance, that is the issue. 23:45:43 ack rgrant___ 23:45:43 rgrant___, you wanted to as have we discussed undeletable-but-narrowly-shared as a thing not ephemeral and not persistent? 23:46:26 rgrant: DID once exposed is undeletable, like Christopher, I'd like the ability to share things w/ people that ar emore premanent than others, saying that the thing is persistent kinda gets in the way of my controlling it. 23:46:32 ack kdenhartog 23:47:11 kdenhartog: One of the things I think that is important to consider is guarantees we're providing to relying parties -- that's where what Joe is articulating, consistent checking coming into play -- VC is consistently checked whether it's been revoked, signature is still valid, etc. 23:47:44 kdenhartog: VCs in offline, not possible to actually verify these things -- at time of verification, at time of reception -- what it's stating in VC -- when verifier takes it on as a risk. 23:48:17 kdenhartog: concept can be mapped to DID and DID Controller -- binding of identifier, some level of trust w/ DID Controller for that situation, in some cases, they want the binding, in other cases they don't. 23:48:34 kdenhartog: It comes down to not setting it, but allowing trade-off to make decision. 23:48:35 ack manu 23:48:35 manu, you wanted to ask a question -- what use cases are at risk? 23:48:44 q+ to explain how even with hardware devices, you can't guarantee permanence 23:48:54 manu: i wanted to point out that I think there is more alignment here 23:49:24 ... no one things any use case is off the table by this language? 23:49:28 q+ 23:49:37 to address manu's point 23:49:45 q+ to suggest Joe submits a PR. :) 23:49:53 ack ack drummond 23:49:56 ack drummond 23:49:56 drummond, you wanted to remind Joe that DIDs are not just for people 23:50:51 drummond: One other high level remark -- it feels like I need to remind folks w/ different perspectives that DIDs are not just for people, maybe it's for a particular use cases, uniformly, there are a class of subjects that need to be identified that are not people, constant requirement is identification of a legal entity that will only be used for that legal entity ever. 23:51:03 drummond: I don't think anyone here thinks there shouldn't be URNs. 23:51:19 manu: I would say that use-cases aside, this is really about security and privacy concerns about making assumptions about the policy 23:51:32 To me the key to that usecase is in how the assignment is done, which is often outside the scope of the identifier directly 23:51:59 Therefore the binding is external to the identifier 23:52:03 present+ 23:52:13 drummond: It's important to keep in mind, those cases -- not an advocate for persistent things -- except for peer dids, I don't have to change it because I don't control it -- if there is no person there, no problem -- policy-based thing slike registries -- we're trying to point out the ends of the spectrum, pay attention. 23:52:43 ack JoeAndrieu 23:52:43 JoeAndrieu, you wanted to explain how even with hardware devices, you can't guarantee permanence 23:53:19 JoeAndrieu: The examples Drummond just gave are centralized and shouldn't shape the spec, if you can achieve them w/ DIDs, that's fine... but forcing that shouldn't be how we frame this. 23:53:39 +1 to JoeAndrieu, agree the use-cases presented are centralized and don't have as much of a role in a decentralized world. 23:53:46 ack kdenhartog 23:54:05 1. Remove language about permanent binding 23:54:09 kdenhartog: I was under assumption that by removing language, we were removing mental model of use cases -- just wanted to clarify - do you see ability to have persitent identifiers as sometihng we're trying to remove, or is it going ot happen no matter what? 23:54:15 Joe, the notes didn't capture your second suggestion 23:54:22 2. Clarify how contextual correlation can be used, when appropriate 23:55:33 drummond: I don't see it as either one -- if controller wants persistence, what they need to pay attention to -- that's what I think we're trying to answer... if we put it in security considerations, that'll help. 23:55:52 drummond: Thanks to all for input around subject, will try to turn this around in 48 hours. 23:55:54 ack manu 23:55:54 manu, you wanted to suggest Joe submits a PR. :) 23:56:19 manu: just a request to joe, can you do a PR then we can review these side-by-side 23:56:21 q+ 23:56:31 ack jonathan_holt 23:56:41 jonathan_holt: Is there an example of these "binding policies"? 23:56:53 jonathan_holt: I haven't seen that before. 23:57:13 drummond: I will just reference the URN RFC - we can just point to that guidance... for operations infrastructure for persistent identifiers. 23:57:21 drummond: I was trying to pull out any mention of policies. 23:57:45 jonathan_holt: The challenge is that they have a different role for centralized identifiers vs. decentralized identifiers... URNs might not apply. 23:58:06 gotta run! 23:58:12 No motions? 23:58:18 URNs are very much not centralized... 23:58:22 just for the record 23:58:39 brent: Thanks for conversation/feedback, thanks for all working on PRs -- you guys are fantastic, a pleasure working with you! :) 23:58:45 rrsagent, draft minutes 23:58:45 I have made the request to generate https://www.w3.org/2021/01/19-did-topic-minutes.html manu 23:59:18 rrsagent, make logs public 23:59:45 chair: brent 00:00:02 meeting: DID WG Special Topic 00:00:13 zakim, end the meeting 00:00:13 As of this point the attendees have been markus_sabadello, manu, brent, shigeya, kdenhartog, TallTed, tplooker, burn, drummond, ChristopherA, jonathan_holt, agropper, rgrant___ 00:00:16 RRSAgent, please draft minutes 00:00:16 I have made the request to generate https://www.w3.org/2021/01/19-did-topic-minutes.html Zakim 00:00:18 I am happy to have been of service, brent; please remember to excuse RRSAgent. Goodbye 00:00:22 Zakim has left #did-topic 00:00:36 rrsagent, please excuse us 00:00:36 I see no action items