16:50:14 RRSAgent has joined #did-topic 16:50:14 logging to https://www.w3.org/2021/01/14-did-topic-irc 16:50:16 RRSAgent, make logs Public 16:50:17 please title this meeting ("meeting: ..."), ivan 16:50:40 Meeting: DID WG Topic Call on Herd Privacy and the Appendix 16:50:40 Chair: ivan 16:50:40 Date: 2021-01-14 16:50:40 Agenda: https://www.w3.org/mid/CAHR74YUUXKYpVZVbv44XFGQwqyLU9NB+U8xVe8wQJqzaiXo=BA@mail.gmail.com 16:50:43 Regrets+ brent 16:51:13 Agenda: https://lists.w3.org/Archives/Public/public-did-wg/2021Jan/0014.html 16:53:42 scribe+ 16:56:23 present+ rhiaro 16:56:27 present+ 17:00:15 present+ manu 17:00:45 markus_sabadello has joined #did-topic 17:00:46 justin_r has joined #did-topic 17:00:52 present+ 17:00:56 present+ 17:01:06 JoeAndrieu has joined #did-topic 17:01:11 ChristopherA has joined #did-topic 17:01:20 present+ 17:01:22 present+ 17:02:13 manu: we can review joe's position, then discuss a fallback consensus position 17:02:31 Orie has joined #did-topic 17:02:42 Topic: Herd Privacy @issue 539 17:02:42 -> https://github.com/w3c/did-core/files/5810975/Herd.Privacy.and.DIDs.pdf Drummond's slides 17:02:58 present+ 17:03:05 q+ to talk some history. 17:03:37 burn has joined #did-topic 17:03:46 ChristopherA: I thought i can recap history or talk about pre-DIDs while we're waiting 17:03:50 ... this is not just a DID thing 17:03:57 present+ orie 17:04:02 present+ adrian 17:04:13 ... this is an ongoing problem that the entire internet design community is dealing with 17:04:16 agropper has joined #did-topic 17:05:20 agropper has left #did-topic 17:05:26 present+ identitywoman 17:05:43 various: discussion about handling 15 mins without drummond 17:05:45 q+ to ask Joe to state his position -- I have not been able to keep up -- I expect others haven't either. 17:05:57 I think Drummond planned to start with a presentation 17:05:58 dhh: I'm aware of the herd privacy topic and I'm pretty sure I'd say anything drummond would say 17:06:30 q- 17:06:33 JoeAndrieu: I think herd privacy is vital to the DID Core spec, and we need to update it to address herd privacy while ensuring that DID method implementers are free to innovate 17:06:48 q+ to note the use of "type" by microsoft 17:06:51 ... herd privacy means you should not be able to discern the nature of the subject by comparing did core features of dids, did urls and did documents 17:06:56 q- 17:07:01 present+ dhardman 17:07:03 agropper___ has joined #did-topic 17:07:07 +1 generally to Joe 17:07:10 dhh: the first part feesl comfortable, the second part needs some nuance 17:07:14 present+ 17:07:17 ... herd privacy ought to mean you can't tell anything about the DID subject 17:07:27 ... I think it would be fine to know a particular DID relates to a document or a iot device 17:07:35 q+ to ask concretely how this affects current normative statements in the specification, what changes are being suggested? Is this mostly non-normative? Normative? 17:07:40 ... herd privacy as it relates to things as it relates to things other than idnividuals is a little bit iffy 17:07:46 ... I'm not convinced that it's vital for nonhumans 17:07:56 Herd privacy is vital to the DID Core specification. DID Core shall be updated to better address herd privacy while attempting to ensure DID Method implementers are free to innovate. Herd privacy means that one should not be able to discern the nature of the Subject by comparing the DID Core features of DIDs, DID-URLs, or DID Documents. DID Core features that impact herd privacy MUST justify their functionality through exceptional ben[CUT] 17:07:57 q? 17:07:57 q+ to also note that registry meaning changes over time... see "master/main" in git 17:08:01 q+ 17:08:13 Orie: to note two points related the concept of herd privacy being fundamental 17:08:24 q+ 17:08:30 ... I'm aware of an intention to use the DID identifier idchar stringt o identify software packages as a distnct subset from people 17:08:38 ... this is work that microsoft folks are interested in, a registry for different types of identifiers 17:08:45 present+ grantnoble 17:08:50 ... the first use case they've talked about is software packages as distinct from did subjects that might be users 17:08:58 ... microsoft is talking about that, they are already working on things related to that 17:09:03 ... you should know about that use case 17:09:07 ack Orie 17:09:07 Orie, you wanted to note the use of "type" by microsoft and to also note that registry meaning changes over time... see "master/main" in git 17:09:12 ... It'd be awesome to hear from the about their intention for registries of types of dids for ion 17:09:16 ... they've thought about this a good amount 17:09:20 ... I've argued a lot about this topic 17:09:24 I think it's important to note is that any DID Document that contains "type" information, etc. -- it does not contribute to "the herd" -- because it can be separated from it. 17:09:30 ... One thing about registries we should be aware of is you don't get to control how the registry is used in the future 17:09:31 present+ jonathan 17:09:36 ... especially in social media, culture changes over time 17:09:48 ... eg. master for the main branch in git was acceptable before, is no longer acceptable now 17:09:57 ... we should be capable about making unenforcealbe statements in did core 17:09:59 ack manu 17:09:59 manu, you wanted to ask concretely how this affects current normative statements in the specification, what changes are being suggested? Is this mostly non-normative? Normative? 17:10:03 ... we are not in control of the future or english language 17:10:09 manu: I feel like I understand mostly where people are coming from 17:10:13 ... What changes to the spec are we talking about? 17:10:18 present+ burn 17:10:30 ... the current thing under consideration is suggesting that we move resource dereferencing out of the spec into a resolver parameter 17:10:43 q+ to discuss spec texts after we have resolution on definitions 17:10:50 ... I think Joe is saying let's take resource=true out of the core spec and if people want that they can register it in the registries and the way to do it is through a DID resolver parameter of some kind 17:10:55 ... that's one concrete spec change I can think of 17:11:01 ... everything else feels nonnormative 17:11:07 ... any other changes contemplating suggesting anyone? 17:11:11 ack ChristopherA 17:11:33 ChristopherA: I'm coming from a history of great intentions that result in regrets and there's a lot of people in ietf that have turend around and said we need to be radical 17:11:38 ... we didn't do it good enough 17:11:42 ... and consider myself in that category 17:11:51 ... a thing I love about DIDs is that it really truly abstracted a part of the bootstrap 17:12:00 ... given I need an identifier that isn't controlled by others, but I need to be able to prove control 17:12:05 ... anything beyond that ought to be a different level 17:12:23 ... yes I might ask the resolver to get me more information, it ought to be going to the endpoint and doin ga protocol but that's a differnet layer of the stack than DID is 17:12:30 ... DID fundamentally is about being able to prove control over an identifier 17:12:33 drummond has joined #did-topic 17:12:36 ... I'm more raidical, I'd probably rip more out of DID core 17:12:41 present+ 17:12:45 ... but i really am trying to protect people 17:13:20 ... I'm doing DID onion and you should know with did onion whether there's a person behind it, securing git archives and stuff and things that aren't people, but when I'm done you won't kno wat the DID level what's what or who's what or if it is a who 17:13:27 ... you'll just be able to kno that the identifier has a controller 17:13:31 ... and everything else will be another layer 17:13:58 ack agropper___ 17:14:20 agropper: to daniel's point, and I think drummond's, I don't believe that DIDs for things and documents where those things and documents are associated with people are not part of herd privacy 17:14:27 ... I disagree with what I think I heard drummond and daniel sya 17:14:39 ... And to the point just made, I would put everything behind service endpoints 17:14:44 I have never said that DIDs for certain types of things do not need herd privacy. 17:15:03 ack JoeAndrieu 17:15:03 JoeAndrieu, you wanted to discuss spec texts after we have resolution on definitions 17:15:04 ... I would see that DID core should not introduce any properties or parameters other than those involved in controlling verification, and everything else would have to go behind a service endpoint of oen kind or another 17:15:17 q+ to ask how "resource=true" violates any notion of herd privacy? Wouldn't the same thing hold for /any/ property in a DID Document? 17:15:20 JoeAndrieu: one of the reasons for this call is that I'm fed up of arguing with drummond and having concern for the privacy of individuals dismissed because of features fo rthings that aren't individuals 17:15:29 q+ 17:15:35 ... it's premature to itemise all of the things in the spec that need adjustment. resource=ture is one of them. it's on me to go through and do a deep dive 17:15:35 q+ to offer a few observations... 17:15:36 q+ 17:15:44 ... but that's not worth doing if the group doesn't support a shared definition of herd privacy 17:15:44 q+ 17:15:46 q- later 17:15:50 dbuc has joined #did-topic 17:15:57 ack drummond 17:16:50 drummond: I am upset with Joe using the term that I've been dismissing privacy 17:16:55 ... I do not want this to be about this reaction 17:17:01 ... I have a very straightfoward positon on this issue which I've shared 17:17:04 Agree -- we should stay away from tying people to positions. 17:17:10 ... which is I'm a huge supporter of herd privacy for the context in which it's needed 17:17:15 ... I know the contention on the talbe is that it's needed for all DIDs 17:17:16 and discuss the ideas on their own. 17:17:19 ... and I want to point out that that is not true 17:17:36 ... if that were true we would have to agree that there's only oen context for all DIDs, which is anonymity or pseudonymity and that would ignore use cases that don't invovle those 17:17:39 q+ to correct assertion this is about herd privacy for all DIDs 17:17:47 Microsoft must herd with other corporations to ensure that no one knows our main DID is related to Microsoft the company 17:17:53 ... so it's counter productive for the spec and for our goals to insist that herd privacy must apply to 100% of DIDs. It may be 99% of DIDs, that's fine 17:17:55 q+ 17:18:00 ... it's going to be a mistake for us to say it's going to apply to 100% 17:18:07 present+ dpbuc 17:18:07 ... and we can talk about the specific cases 17:18:10 We wouldn't want it getting out that we have a lot of trusted things tied to our DID! *clutches pearls* 17:18:24 If the herd is all DIDs and DID Subjects, across all DID Methods, then the herd is large, and some herd privacy *might* be possible. 17:18:25 If each DID Method has its own herd (separating, perhaps, IoT devices from documents/information-resources from humans; and possibly those humans who care about herd privacy from those who don't [yet, now, etc.]), then some herds will be large and may bestow some inherent herd privacy, but other herds will be small and bestow less if any inherent herd privacy. 17:18:25 If the only DID Subjects who do whatever heavy lifting is needed to use a DID Method that tries to preserve herd privacy are the ones who need that privacy, they have already lost it. 17:18:25 Anonymity and pseudonymity must be the default, and still allow for nymity 17:18:32 s/dpbuc/dbuc/ 17:18:37 q+ 17:18:37 jonathan_holt has joined #did-topic 17:18:49 ack TallTed 17:18:49 TallTed, you wanted to offer a few observations... 17:19:04 "each did method" is a herd! 17:19:17 +1 to what Ted just said 17:19:19 +1 TallTed 17:19:43 TallTed: names can be used in the anonymous sphere without disrupting the anonymity of those who prefer notn to assert soem known identity 17:19:47 q- 17:19:50 ... we have to do the anonymising, it's the only way that gets us there 17:19:56 ack dlongley 17:20:00 dlongley: I was about to say something very similar to what ted said 17:20:11 ... every time we have more information added to a DID doc that information is not random, you're creating new herds 17:20:11 "obviously did:github" is only for users of github.... "did:onion" for tor hidden services... 17:20:26 rgrant_ has joined #did-topic 17:20:27 ... every time you add more information like that, you separate an existing herd into the set of information that have this new non random piece of data and the set that does not 17:20:37 ... it's important for people to understand that you keep reducing the size of the herd whenever you do this 17:20:46 ack manu 17:20:46 manu, you wanted to ask how "resource=true" violates any notion of herd privacy? Wouldn't the same thing hold for /any/ property in a DID Document? 17:20:47 ... you create spearate herds tha tmay not be large enough to provide the protection necessary 17:21:02 manu: a concrete question I have for joe and christopher, it feels like we're all on the same page with respect to trying to protect people when it comes to herd privacy 17:21:12 ... the main point of discussion or disgreement is what endangers herd privacy 17:21:18 q+ 17:21:19 ... I've heard that this resource=true param endangers herd privacy 17:21:25 ... I don't necessarily understand how 17:21:31 ... what's different wrt this feature thta other features don't have 17:21:46 ... so for example, I think we could say any extra piece of information that you add to a DID doc besides the base key materials stuff endangers herd privacy 17:21:52 ... we may be ablet o have consensus to say that in the spec 17:21:58 ... but what specifically about resource=true is the issue? 17:22:08 ... is it this is just one example among many and we're nipping it in the bud and asserting it here? 17:22:16 present+ jonathan_holt 17:22:19 ... or is there any inherant thing that's different about resource=true from the key material and the service endpoints? 17:22:22 ack JoeAndrieu 17:22:22 JoeAndrieu, you wanted to correct assertion this is about herd privacy for all DIDs 17:22:26 if adding properties other than key material to a did document endangers herd privacy.... why did we spend months adding arbitrary extensibility to did documents? 17:22:42 JoeAndrieu: to manu's question, it reveals the nature of the subject 17:22:46 ... the cryptographic material does not do that 17:22:55 ... to drummon'ds point that is is all about me trying to get herd privacy to apply to all dids 17:23:01 ... tha'st not true. I want it to apply to al lDID Core features 17:23:10 ... DID methods must be able to innovate, and of course they will do things that are going to create new herds 17:23:12 ... but that's their choice 17:23:22 ... we have an extxensibility method that embrances that 17:23:24 ack ChristopherA 17:23:35 I acknowledge what Joe said, thanks. 17:23:36 ... plesae don't say it's all about trying to make all did methods apply with my ideas 17:23:55 ChristopherA: I have no problem with there being some type of feature where you can request is this a resource=true. I feel like resourece=true is a verifiable credential 17:24:02 ... a self defined, I sign this, I'm saying I'm a resource 17:24:07 ... all these things are at another layer 17:24:18 q+ to ask ChristopherA/Joe how saying "I'm a resource violates herd privacy, I don't get it... what's the attack? and to ask Daniel/Drummond if they'd be ok w/ resource=true as a DID Method extension? 17:24:19 q+ to address that URI construction is "not at another layer" 17:24:27 ... right after united nations id2020 when we did grand compromises on these architectures, we really said we need to separate out identifiers from names and all the other things 17:24:31 Orie, I think Joe just responded to that -- we can't stop extensibility, we say how to do it, in fact, so there is interoperability. However, Joe's argument is to not build certain things into DID core so it's not something every method needs to support or is *coerced* to support. 17:24:40 ... if we can let that one layer be as safe as possible and allow for methods and other types of things to be able to extend it 17:24:49 ... then that's the great compromise 17:25:05 ... I woul dsay I should have pushed more back then that even method type stuff ought to be at a slgithly different layer, and I didn't push that hard for that 17:25:10 ... I'm a little more radical, I'd like to cut out more 17:25:20 ... I'm not saying we don't wawnt to offer these features, I just want to make it at a different layer 17:25:29 ... Names and other identification things that are beyond the control ofthe identifier 17:25:35 ... this really is a decentralised identifier standard 17:25:57 ack dbuc 17:26:02 dbuc: use cases [use cases] [[use cases]] 17:26:12 ... I don't know the nuances of resource=true 17:26:15 ... one thing we're dogfooding right now 17:26:32 ... you could put a nonhuman type inside of the method, because that wa ssomething that didn't exist in the DID core spec, you can do that within the method so you can query by type 17:26:38 ... we're doing software packages 17:27:00 ... today we own your github, npm, we don't want to disrupt ourselves, one idea is to have a DID to stand for a software package, and to be able to index those in ion 17:27:05 ... we don't have to echo the types out any further 17:27:20 ... I can index by type, find that type of thing, get that URL, and present the same interface tha npm would but you don't have to be owned by us! 17:27:43 ... as long as the use cases are efficient and don't need a second VDR, these are expensive to run.. we need a ledger to deal with these sorts of thing 17:28:03 ... That's one use case example 17:28:07 ... I want to make sure it's not affected 17:28:09 q+ on software use case 17:28:14 ack markus_sabadello 17:28:14 q+ to answer dbuc by embracing Method innovation 17:28:15 ... service endpoints and typing can be internal to the method, but we need those sorts of things 17:28:21 markus_sabadello: comment about DID methods 17:28:25 ... each method is its own herd 17:28:33 ... methods are primarily about how control is established 17:28:36 ... how DIDs are created 17:28:41 BIG CORRECTION: "today we own your github, npm, we DO want to disrupt ourselves," 17:28:43 ... DID methods should not be about what the IDD subject is and what the DID idnetifies 17:28:45 +1 to methods about how control is established! 17:28:48 q+ 17:28:55 that's a pretty big word flip LOL 17:28:59 ... I think it would a be a big mistake for a did methdo that can only identify things, only identify github users 17:29:10 ... and extensions are not necessarily done only by DID methods 17:29:20 ... if someone wanted to invent a type property or parameter, that's not necessarily limited to a method 17:29:26 ack manu 17:29:26 manu, you wanted to ask ChristopherA/Joe how saying "I'm a resource violates herd privacy, I don't get it... what's the attack? and to ask Daniel/Drummond if they'd be ok w/ 17:29:26 s/don't want to disrupt/do want to disrupt 17:29:29 ... resource=true as a DID Method extension? 17:29:36 manu: questions for each side 17:29:48 ... I don't see how resource=true violates herd privacy, I've tried to understand and I don't get it 17:29:55 ... you still don't know if it's an iot device or a person or a chair 17:30:06 ... the reason I'm making a point of this is we need to understand where the line is in the spec 17:30:10 ... I don't think it's being well defined 17:30:18 ... if we can talk about why resource=true is an issue and separate that form just adding any othe rparams 17:30:33 ... it could be that what joe and christopher are aguing for is anything beyond how to establish control shouldn't go in the core spec except for services, that would be something 17:30:41 ... theer's nothing for me to latch onto as an editor to make a judgement call 17:30:46 ... to ask folks on the other side of the point, 17:31:00 ... I don't think anyone is saying we're not going to address the use case 17:31:02 If I resolve & dereference every DID I encounter and can see "these DIDs say resource=true, and those don't" then I can focus further observations and correlative efforts on the latter. 17:31:12 I need at least Service Endpoints, for them to be type-extendable. If you leave the type of the DID to Method-land, that's fine, but you will then have even more clear 'winners' even faster when it comes to Methods 17:31:17 ... there will be something to the effect of resource=true, the only question is is it in the core spec or the registry, and what language will we write aroun dthat 17:31:25 the Method that embraces the best typing structure will have a HUGE advantage 17:31:30 ... if it comes to it we would move it to the registry, would that trigger a formal objection from anyone? 17:31:31 ack drummond 17:31:31 drummond, you wanted to address that URI construction is "not at another layer" 17:31:34 q 17:31:48 And if you want to hand that advantage to those of us who want to do that, so be it 17:31:53 drummond: christopher said something I find helpful. We're talking about layering 17:31:59 ... it's important for us to distinguish between DIDs and DID URLs 17:32:05 ivan: oh yes 17:32:10 drummond: that distinction is so important 17:32:12 but do understand the game theoretical result of that decision 17:32:20 ... we may not remember when were wondered what to call URLs 17:32:27 q+ 17:32:40 ... my point is DID URLs, it's a little bit like we're talking about domain names and we're going to cast requirements on all the URIs on which domain names are just roots 17:32:58 ... we can say herd privacy does not apply to everything that has a URI, there are many things you need to use a URI for that doesn't require herd privacy 17:33:08 ... the resource=true parameter turns a DID into a DID URL 17:33:12 ... that DID URL has a specific use 17:33:39 ... the indy community has an immediate, they're planning on using tha tparm in their DID method. it's not a layer violation because the resource will be at layer 1, the resource will be in the VDR 17:33:43 ... there is no higher layer involved there 17:33:51 In ION, resource=true is implemented as leading byte prefix.... for "resource type". 17:34:12 Orie, is it a multicodec value? 17:34:35 ... all you're doing is taking the DID, which all by itself the did doc wouldn't indicate anything by itself, but if you'v enow turned it into a DID URL because you want to do something specific, you're going to know that that DID URL if you ... if I use a DID for an individual, even a DID that has herd privacy by itself from the DID Doc, the useage of the system.. many will be violating herd privacy 17:34:57 ack ChristopherA 17:34:57 ChristopherA, you wanted to comment on software use case 17:35:01 ... the case for the resource=true param is that it is a particular kind of DID URL which is when the resource is an information resource stored on the VDR, that should be available to any DID method that wants ot use it 17:35:20 ChristopherA: I want to respond to daniels' thing of having this universal way of differentiating this is a software file 17:35:20 DPM FTW! 17:35:31 NPM, too centralized, boooo! 17:35:32 ... I happen to be also working on securing software packages use case 17:35:33 q+ to ask Drummond again -- he didn't answer my question -- can it be in the DID spec registry? :) 17:35:54 ... th eproblem is people who are authors, contributors to code, you have organisations that are contributors, you have the actual code itself which evolves over time, based on the authority and verification of the variosu parties 17:36:05 q+ 17:36:07 ... I'm very explicitly with the did:onion, noncorrelation, at the DID level you don't know anything at that point 17:36:18 ... there's real concern, you shouldn't know that this is a person, org or thing at that level 17:36:24 Sure, and you can have the underlying DID use a blinded authority scheme for its keys and commitments 17:36:42 I think it is a wonderful idea to have DID methods that are designed explicitly to maximize herd privacy 17:36:45 ... you need to go to the endpoint for that thing and request the verifiable claims that is where it says "I'm a resource" or "organisation" or "contributor" which could be denied 17:36:53 ... because at that point, if it happens too soon it can be a denial of service 17:37:02 ... I can go i'm gonna deny that particular level 17:37:10 ... I have knowledge that i don't want these other people to share 17:37:15 ... I don't think it's required to be at that level 17:37:19 ... there is some risk 17:37:38 ... this goes back to an early rwot use case which was the amira use case where you have a software engineer who was working on anti violence software 17:37:44 ... and feels like they could become a target 17:37:48 ... of people that object 17:37:59 ... in DID onion and the code around it we're keeping that very explicit 17:38:02 @manu - I'm happy to explain why I believe resource = true should be in DID Core 17:38:07 ... the whole DID URL thing has been controversial for a while 17:38:25 ... if it's separate from an identifier in a VC there are additional params that ell a resolver to do a shortcut to get these things so I just make one request 17:38:28 ... I end up with this as a resource 17:38:37 @drummond -- not the question :) -- would you object to it being in did spec registries? 17:38:37 ... I don't have a problem with that, the resolver can do mor ethan just prove control 17:38:44 ... it can walk through the steps on behalf of the user 17:39:00 ... but that means we've made some poor choices by having so much of the DID URL spec in the Core 17:39:06 ... it should be more in deferred to the resolver spec 17:39:12 ... where I draw th eline is when there is something in the DID Doc 17:39:19 ... I'm okay if resolvers can offer other services 17:39:25 ... but if it's in the DID doc that's where I draw my line 17:39:29 I don't care if consumers of DID Docs have to go hit a SE inside the DID Doc 17:39:31 q- 17:39:37 ack JoeAndrieu 17:39:37 JoeAndrieu, you wanted to answer dbuc by embracing Method innovation 17:39:42 is this just about automating that at the Resolver layer? 17:39:53 if so, for me, that's not a deal breaker 17:40:00 JoeAndrieu: slightly different answer to dbuc 17:40:07 ... I think methods are where you should be innovating these things 17:40:12 ... if microsoft wants to do this, more power to them 17:40:28 ... the notion that certain groups are already expecting this feature is exactly why it's important that we vet all the features in DID core to make sure they are useful for every method 17:40:35 ... they will be adopted by people who aren't here fo rhtese conversations 17:40:48 ... how resource=true violates herd privacy, the only use case presented are when dids represent a resource 17:40:54 ... it is for discerning human resources from digital resources 17:41:01 ack agropper___ 17:41:14 q+ to ask what breaks if human resources on my did-method set resource=true 17:41:19 sorry, Amy, the pressure to move quickly makes it hard to talk slowly 17:41:32 agropper: [??] from my perspective the efficiency of the process is not the issue at the DID COre level 17:41:42 ... moving everything behidn the service endpoint should be where DID Core puts the demarkation point 17:41:48 q+ to explain how we can achieve the function of resource=true without it 17:41:52 ... and then we should be working on more efficient authz methods if that is where the bottleneck shows up 17:41:57 ack manu 17:41:57 manu, you wanted to ask Drummond again -- he didn't answer my question -- can it be in the DID spec registry? :) 17:41:58 to say why allowing resource=true causes trouble for herd privacy: it separates one herd into two... one that is known to be for digital resources, and the other that is unknown (but smaller in size, not including those things that are *known* to be digital resources) 17:42:01 q+ to address that there are thousands of use cases where DID URLs will distinguish information resources. resource=true is one that needs to be in DID core because it addresses resources in a VDR. 17:42:24 manu: resource=true I'm not hearing.. I heard joe when he said that the use case that was presented was to make distinct human resources from nonhuman resources, yes that was presented and that clearly cuts it between two things we don't want to cut it between 17:42:28 ... but I don't think that' sactually the use case 17:42:38 ... you can have a human actor put resource=true just as well as you can a digital resource or an iot resource 17:42:42 ... I don't think the actual use cases make that distinction 17:42:51 ... i still don't see the difference 17:42:53 q? 17:43:00 ... I didn't hear an anser to my question that would anyone object if we put resource=true in the Registries 17:43:07 ... the people that want it would still be ablet o use it 17:43:13 ... that seems to be the compromise position 17:43:20 ... if we go on the route we're on right now we'll see objectoins 17:43:26 ... we're going to have to decide whether to take it out 17:43:33 ... it'll be clear we don't have consensus to keep it in 17:43:46 ... the only way it ends up staing in the spec is if we get consensus and it doens't seem like we are converging 17:43:52 ... who is going to object if we put it in the Registries? 17:44:02 q+, could someone give me a high-level explaination of resource = true? 17:44:03 ... if there are objectoins from that side, we'll have to see what has the fewest objections 17:44:08 ... I don't see people changing their positoin on the call 17:44:12 ... I see people continuing the current position 17:44:23 ... we're headed towards what's going to get the lesat number of objections 17:44:43 ack dbuc 17:44:45 ... It's important to hear clear answers from joe as to why this is any different from any other feature, and from drummond or anyone are you going to formally object if it's in the registries and then why 17:44:49 I'm on the queue to address Manu's question 17:45:24 dbuc: types being eneralised in the sense of there being a concept in the top level DID spe cis good. There are drawbacks that come with it. If it's generalised across the methods they can interoperate. If it doesn't happne that's cool, but different methods might pick different types 17:45:36 ... with service endpoints in the DID doc, I can still make what i want to make 17:45:41 dlongley: thx! 17:45:45 0. All DID Methods must include "resource=true" on the surface of all DID Documents, eliminating its utility, but preserving herd privacy. 17:45:45 1. If I resolve & dereference every DID I encounter and can see *without decrypting anything* "these DIDs say resource=true, and those don't", then I can focus further observations and correlative efforts on the sub-group I care about. 17:45:46 2. If everything that doesn't care about herd privacy turns it off, they radically shrink the size of the "privacy" herd, radically reducing that herd privacy, potentially to zero. 17:45:46 3. Bad actors (including national entities working for *their* good, which may not be universal) will request all sorts of things through all sorts of disguises and anything that is on the "visible" surface changes the shape available for attack 17:45:46 4. Pieces of this are similarly possible with TLS/SSL re TCP/IP traffic, which (lacking VPN) *does* expose the endpoints of those connections which *can* be an exposure point. See the analysis of American Revolutionary postal correspondence that discovered the network of conspirators for an example. 17:45:53 ... my question about this resource=true, what would this being there or not being there imperil about a use case like that? 17:45:56 ... is there something it does? 17:46:01 ack rgrant_ 17:46:01 rgrant_, you wanted to ask what breaks if human resources on my did-method set resource=true 17:46:04 ... we might only need service endopints and typing at some layer? am I wrong? 17:46:29 rgrant: the DID method I'm working on is great for long term DIDs that should not be controlled by other entities, and humans who want maximum privacy 17:46:35 ... we pick options that maximise herd privacy 17:46:48 ... if it didn't break anything we'd set resource=true and if that screws up anyone elses library, tell me how it's going to break my experience 17:46:51 Camouflage is great for herd privacy. 17:46:55 ack JoeAndrieu 17:46:55 JoeAndrieu, you wanted to explain how we can achieve the function of resource=true without it 17:46:58 ... if it doesn't help herd privacy, I'm going to pick the most private option 17:47:09 JoeAndrieu: I feel like this was ramrodded in and doens't solve th eunderlying use case 17:47:20 ... there's a willingness on behalf of the chairs and editors ot pu tany feature in because somebody wants it 17:47:31 ... if there isnt' a good use case that isn't privacy impacting it ishouldn't be in the document 17:47:32 ... we don't need it 17:47:37 q? 17:47:41 Nope, disagree with what Joe is saying -- this wasn't ramrodded -- we merge things per our process. 17:47:44 ... and of the reasons is there was a conflation by brent between resolution and dereferencing 17:47:52 ... method specs are already able to define how we dereference 17:47:59 Drummond: can you tell me where this being in/out breaks the use case of finding a typed DID in a registry, then following a typed service endpoint to a resource? 17:48:01 ack drummond 17:48:01 drummond, you wanted to address that there are thousands of use cases where DID URLs will distinguish information resources. resource=true is one that needs to be in DID core 17:48:02 ... you can take a DID, resolve to a DID doc, and dereference according ot th emethod, and get a resource 17:48:05 ... because it addresses resources in a VDR. 17:48:05 ... yo udon't need resource=true 17:48:15 drummond: I strongly disagree with what joe just said 17:48:25 I feel like I am agreeing with Joe, and it kinda feels weird 17:48:32 ;) 17:48:37 ... there are obviously ways to doing it. The number on ereason to have resource=true in DID core is so that any method that wants to make resources available directly out of VDR has a way of doing it 17:48:47 ... is evernym going to object if that ends up in the registries? probably not 17:49:11 q? 17:49:11 ... but I would consider it a disservice to the adoption of DIDs an dDID URLs if don't point ou ta standard way to return a resource and a standard param that any DID method can use to do that 17:49:11 Drummond: could this be standardized via the Resolution spec? 17:49:33 Perhaps I just don't get it, I might plead ignorance here 17:49:33 ... the DID itself and associated DID doc for herd privacy, when you add the parameter resource=true and any DID method can add anything they want, DIDs are the root of DID URLs which will have millions of uses 17:49:36 q+ to thank Drummond and note that I don't think we're really preventing bad things from happening here. 17:49:42 ... all we're saying is there's one use of a parameter that will allow you to return a resource from a VDR 17:50:03 ... I believe the universality of the value of that parameter or any kind of resource you might want to return, is the reason for utility's sake to put that in DID Core 17:50:37 ivan: when I looked through the slides, there was the reference to this long appendix which seems to be also hanging on the same discussion 17:50:39 ack manu 17:50:39 manu, you wanted to thank Drummond and note that I don't think we're really preventing bad things from happening here. 17:50:52 manu: thank you drummond, that is helpful to knwo evernym is not going to object. 17:50:58 ... I'm just stating my opinion, not as an editor 17:51:10 ... It's heartening to hear everyone is more or less on the same page, just disagreeing about details. I know some of you don't think they are details 17:51:24 ... I don't know if we have enough to write a definition of herd privacy right now, but feels like we're all going for the same thing 17:51:25 q? 17:51:26 q+ to say, this all seems to be what goes in DID core and what doesn't, it isn't about preventing any sort of behavior -- that's not a thing a spec can do anyway, this is about what is encouraged in the core specification both as features to support and the accepted "right way" to do things 17:51:31 @Ivan - I think the appendix topic is mostly about a separate issue, not herd privacy, so it may be that it warrants another special topic call 17:51:40 Type makes sense, but I don't get this prop, to be honest 17:51:47 ... The challenge I have with this entire discussion, and the same thing with type, this is a criticism of the arguments to not pu tthis in did core, if these are useful features people are going to use them anyway 17:52:00 q+ by adding it to the core, we encourage it. THAT's the problem 17:52:06 ... I think we should write about it in the spec, but that this keeps coming up and things like type and resource=true and these other things get kicked out of the spec is not going to do anything to prevent poeple from using it 17:52:08 q+ to say by adding it to the core, we encourage it. THAT's the problem 17:52:10 q? 17:52:17 ... the only thing that is going to prevent that is if there are compelling arguments made for why ou should not use these features 17:52:37 ... I still don't know as a person needing to implement the spec what a dangerous feature is and what isn't when it comes to herd privacy 17:52:42 ... all I know is that adding more things hurts herd privacy 17:52:51 ... next steps here are calling for consensus to keep tin the spec 17:52:55 ... I expect people will push back on that 17:53:07 ... and the fallback positon is to put it in DID spec registries, and it's going to change any implementer decision 17:53:11 q+ to say this call was not just to be about resource=true 17:53:12 ... the people tha twanted it are going to use it anyway 17:53:17 q? 17:53:19 ... so we haven't accomplished anything other than move the text from one place to another 17:53:21 ... that's my concern 17:53:24 ack dlongley 17:53:24 dlongley, you wanted to say, this all seems to be what goes in DID core and what doesn't, it isn't about preventing any sort of behavior -- that's not a thing a spec can do anyway, 17:53:27 ... this is about what is encouraged in the core specification both as features to support and the accepted "right way" to do things 17:53:35 dlongley: all of this comes down to philosphy around what goes into DID core and what dosen't 17:53:44 This feels like DID Outer Solar System 17:53:48 ... a lot of what manu said is true about no matter what we do we're not going to prevent behaviour. but nobody is arguing that 17:53:52 ... no spec can stop people from doing this 17:53:55 I agree with Manu. I believe we've actually weakened the DID Core Specification by removing a universally useful feature. 17:53:58 dbuc, the Kupier Belt of DIDs. 17:54:05 ... what this is about is whatever features we put into DID core we're announcing that this is something your DID methdo should support, and this is the right way to do it 17:54:15 q+ need to know what breaks 17:54:19 ... anything we put in DID core is encouraging certain sets of eatures to be implemented by people who want to particpate in this ecosystem 17:54:29 q 17:54:35 ... If there are sets of things that people feel like will cause problems with privacy and security, we have a place to put those sorts of features, and that is in the registries 17:54:47 ... it doesn' thave to go in core to encourage or coerce all did method authors to support these sorts of features 17:55:00 ... we have th emechanisms we need, we can push things to the registries when they aren't common features that everyone feels comfortable with 17:55:03 q+ My criteria is if the feature add content the DID Document as defined for DID Core. if it is a feature that is beyond proving control, I may object. 17:55:09 ... if we can adopt that policy we can get through this and have a solution 17:55:12 q? 17:55:24 q+ to say 'My criteria is if the feature add content the DID Document as defined for DID Core. if it is a feature that is beyond proving control, I may object. 17:55:32 ivan: how do the editors feel? do they have something to go away with, or not? 17:55:59 DID Sun Core: Keys, Endpoints - DID Rocky Planet Methods: Typing, indexing - DID Outer Rim Resolution Middleware: resource fetching and advanced transforms 17:56:10 I think it is more than resource=true. We need to define the principle. 17:56:17 JoeAndrieu: this call was not to be about resource=true 17:56:29 ... there's a fundamental to get agreement on. What does it mean to have herd privacy? I'm sad we didn't get that 17:56:47 +1 JoeAndrieu, I think this needs a lot more discussion 17:56:49 manu: two proposals for each point of view. I'm trying to focus on resource=true as something concrete 17:56:56 ... any modifications to either of those? 17:57:00 q? 17:57:03 ack JoeAndrieu 17:57:03 JoeAndrieu, you wanted to say by adding it to the core, we encourage it. THAT's the problem and to say this call was not just to be about resource=true 17:57:10 ack need 17:57:10 need, you wanted to know what breaks 17:57:15 looks more like straw poll than proposals? 17:57:25 Digital Contract Design has applied for W3C membership, and if a vote is taken would like to vote. 17:57:37 ack ChristopherA 17:57:37 ChristopherA, you wanted to say 'My criteria is if the feature add content the DID Document as defined for DID Core. if it is a feature that is beyond proving control, I may 17:57:40 ... object. 17:57:41 ChristopherA: I think resource=true is a red herring of a larger problem 17:57:44 0 on both - I am too ignorant on this topic to vote 17:57:52 PROPOSAL: Keep resource=true in the DID Core specification. 17:57:54 q? 17:58:07 JoeAndrieu: the second one is not an issue, unless you're removing it from DID Core, I'd like to restate it 17:58:24 PROPOSAL: Keep resource=true in the DID Core specification. 17:58:29 +1 17:58:29 0 - I am too ignorant on this topic 17:58:34 -1 17:58:34 -1 17:58:35 0 17:58:35 -1 17:58:35 -1 17:58:36 -0.25 17:58:41 -0.5 17:58:44 -0.5 17:58:53 0 17:58:55 -0.5 i to am ignorant 17:58:55 ivan: I have the impression that this will not make it 17:59:03 PROPOSAL: Move resource=true from DID Core to the DID Spec Registries (as an extension). 17:59:05 0 17:59:06 +1 17:59:06 0 17:59:07 +1 17:59:08 0 17:59:09 1 17:59:09 +0.75 17:59:11 0 17:59:12 +0.5 17:59:14 +0.5 17:59:15 +0.5 17:59:19 +0.5 17:59:27 0 i to am ignorant 17:59:30 RESOLVED: Move resource=true from DID Core to the DID Spec Registries (as an extension). 18:00:05 manu: we'll need to talk again, editors 18:00:08 Does this solve JoeAndrieu 's, agropper___ 's and ChristopherA 's concerns? 18:00:15 ... in the Registries folks that want it can do what they want 18:00:32 Markus, it does not. 18:00:37 ivan: closing remark: I would like to see where this full discussion leads as far as the whole spec is concerned. Ihave heard several times that resource=true is one specific thing that triggers this discussion 18:00:45 ... We have to drive the document towards CR and that worries me 18:00:53 I like your definition earlier is that it is about control. 18:00:53 ... I would like to see specific change proposals if we have one to move ahead 18:00:58 i think if there were more decentralized registry technologies out there ... a lot of these issues would go away ... because people could post what they wanted over there using VCs... and DIDs could be left alone to do what they do best. 18:01:02 ... thank you everyone for coming. 18:01:09 +1 to dlongley 18:01:29 rrsagent, draft minutes 18:01:29 I have made the request to generate https://www.w3.org/2021/01/14-did-topic-minutes.html ivan 20:30:32 Zakim has left #did-topic