21:54:32 RRSAgent has joined #did 21:54:32 logging to https://www.w3.org/2020/10/27-did-irc 21:54:39 zakim, start the meeting 21:54:39 RRSAgent, make logs Public 21:54:41 please title this meeting ("meeting: ..."), burn 21:56:21 present+ 21:56:34 present+ 21:58:56 justin_r has joined #did 22:00:22 present+ 22:00:53 drummond has joined #did 22:01:08 present+ 22:01:14 present+ 22:01:25 scribe+ 22:01:41 Topic: Agenda Review, Introductions, Re-introductions 22:02:12 agropper has joined #did 22:02:19 burn: agenda summary... core of the meeting today is discussion on the type property 22:02:24 ... if there's time left, core issues 22:02:25 present+ 22:02:31 ... any requests for changes or additions? 22:02:36 present+ 22:02:45 ... nobody new, not doing intros 22:02:50 Topic: Special Topic Call 22:03:00 burn: the special topic call is Thursday at noon Eastern 22:03:11 ... 9am Pacific... some mysterious time in europe 22:03:20 shigeya has joined #did 22:03:22 ... 5pm or something in central europe 22:03:31 present+ 22:03:31 ... the topic will be the abstract data model which may have a different name by then 22:03:43 drummond: this is the last call ever we will have about this 22:03:46 /me I may not be able to make the Thursday call fwiw. 22:03:49 kdenhartog has joined #did 22:03:51 tplooker has joined #did 22:03:54 jonathan_holt has joined #did 22:03:59 present+ 22:04:01 present+ 22:04:06 present+ 22:04:18 Topic: Face to Face Meeting 22:04:20 present+ jonathan_holt 22:04:24 abstract data MUDel 22:04:29 burn: in case you forgot, our virtual face to face meeting is next week 22:04:35 ... monday through thursday 22:04:40 ... we will not be having our usual DID WG call 22:04:48 ... we'll send a reminder 22:05:02 dbuc has joined #did 22:05:09 present+ 22:05:22 ... US elections are happening on Tuesday so I would encourage you to plan around that 22:06:05 JoeAndrieu has joined #did 22:06:08 q+ to add agenda item 22:06:20 present+ 22:06:30 ack jonathan_holt 22:06:30 jonathan_holt, you wanted to add agenda item 22:06:41 jonathan_holt: I wanted to talk about cbor and discuss an invited expert 22:06:56 roger, thanks! 22:06:56 burn: I can give you 5 minutes before we get to the type property 22:06:58 Requested agenda item: coordinating special topic call for equivalence props 22:07:07 Topic: IIW Report 22:07:22 burn: anyone who can give us really big items that everyone should know about 22:07:25 q+ 22:07:26 ... from anyone who was there 22:07:28 ack jonathan_holt 22:07:38 q+ 22:07:41 jonathan_holt: tobias' presentation on the identtiy providers to credential providers using openID was brilliant. Love it. 22:07:51 ack drummond 22:07:52 burn: tobias, when you have a link that would be great 22:07:54 The ZACAP and GNAP harmony session was useful. 22:08:01 q? 22:08:07 +1 for KERI and separately GNAP 22:08:12 drummond: the KERI was a 24 hour all KERI news channel, continuous sessions on that topic 22:08:20 ... folks on this WG migh be aware it's adjacent to what we're doing 22:08:25 Thanks Jonathan, link here https://mattrglobal.github.io/oidc-client-bound-assertions-spec/ 22:08:31 ... thought the interest in KERI was a lot higher than I expected 22:08:34 q? 22:08:46 ... had a session on the first day on the basics and we had 116 people 22:08:53 q+ 22:08:55 ... we attracted all the wizards so hard to keep it at a low level 22:09:05 ... probably ten follow on sessions overall. very keen interest in that aspect of what we're doing 22:09:06 ack agropper 22:09:11 Orie has joined #did 22:09:14 present+ 22:09:41 agropper: We had a great session with a lot of people from oauth2 and gnap and zcap types represented 22:09:46 ... dmitri took some notes and I think we made some progress 22:10:04 burn: any other highlights from IIW? 22:10:22 Requested agenda item: coordinating special topic call for equivalence props 22:10:28 Topic: CBOR 22:10:43 jonathan_holt: I haven't received much feedback on the cddl or cbor section apart from from Orie 22:11:00 ... I got feedback from [??] who wrote the cddl and he got back to me quickly 22:11:22 ... some back and forth... in absence of an abstract data model, type definitions, it allows for a concrete, not a full ADM but it does provide some of what we need 22:11:32 ... I've looked into the formal definition of what an abstract data model is 22:11:36 I thought Markus would mention it but it turns out he can't make today's meeting, but he held a wonderful session on DID document representations. It was in many ways a preview of what we might be discussing on Thursday's special topic call on the ADM (abstract data model). 22:11:40 ... I think the CDDL provides that set of possible values and types 22:11:44 s/[??]/Carsten Bormann/ 22:11:45 ... in the DID Core spec we can define the set of operations 22:11:53 ... the task for me was lossless transformation between json and cbor 22:12:05 ... I intended to do that, gave examples for allthe different items in the registry 22:12:27 ... Carsten did find a typo in my regex. He's hoping to have the ABNF rules in CDDL so I wont need to do the regex 22:12:35 ... I've provided I think a scaffolding for the abstract data model 22:12:51 ... and highlighted a lot of redundancies in the verification methods that could e more elegantly represented to simplify the abstract data model 22:13:04 ... And I'd like to make a request, Carsten is a real cbor export and it would be appropriate for us to invite him 22:13:08 q+ 22:13:11 ... he participates in W3C standards 22:13:14 ack justin_r 22:13:24 justin_r: Second the recommendation of bringing carsten in to comment on the cbor stuff 22:13:32 s/cbor expert/cbor expert/ 22:13:33 ... he's been the driving force behind cbor and cose 22:13:55 burn: would one of you be willing to contact him and have him reach out to the chairs? 22:14:05 ... we should probably have him come and join us one meeting first and then we'll see where to go from there 22:14:15 ... we could potentially fnd time during the face to face if it's next week, otherwise it'll be after that 22:14:17 jonathan_holt: sure thing 22:14:24 burn: questions? 22:14:33 +1 to inviting Carsten in. 22:14:35 Topic: Type property 22:14:47 https://github.com/w3c/did-core/pull/410 22:14:49 s/cbor export/cbor expert/ 22:15:16 manu: at a high level the type discussion has basically turned into a question around the privacy implications of the type property 22:15:30 ... initially the intent of the type propery was to be able to express things such as the type of thing the DID subject represents 22:16:13 ... Fundamentally type is used to express whether the thing is an organisation, an information resource like a revocation list, and in some cases a lot of the concern is around type being used to express the DID subject as a person or a police officer or a protestor or things that could potentially be privacy violations or have privacy implications 22:16:35 or an insulin pump <-- potential non-person privacy violation 22:16:37 ... I believe there have een a number of use cases outlined, Ithink what we're going to try to do today is dig in deeper into the concerns around privacy and if there are concrete proposals that the group could get behind 22:17:03 ... I've spoken with a couple of people that have strong opinions about the usage of type 22:17:32 ... From the folks that have a pro-type position, we need to be able to express revocation lists on DID ledger,s if you feel we haven't discussed that enough please feel free to make any points the group hasnt' heard yet 22:17:41 ... I don't think we've heard quite enough from the folks concerned about use of type 22:17:45 ... Joe has good thoughts on the topic 22:17:59 ... What potential compromise positions the group could get behind? 22:18:03 q+ 22:18:10 ... There have been a number of resolutions we've taken on this topic 22:18:28 ... THe first was consensus to add text to the spec to warn about how dangerous the use of type can be 22:18:43 ... Amy has already written a PR expressing how use of type could be dangerous 22:18:44 ack JoeAndrieu 22:19:01 JoeAndrieu: I can appreciate the value that some of the advocates of type see in the feature 22:19:11 ... what I'm struggling with is why it should be a core property 22:19:19 ... today, any method can provide a type value, although I don't think there should be 22:19:27 ... My issue is that it shouldnt' be a core property 22:19:42 ... since we can already do it today with the current spec I think the burden is on demonstrating that adding type as a core property is worth the tradeoff 22:19:52 ... which comes down to for individuals this is a potential privacy leak that could cause human rights harms 22:20:11 ... I can expand on that, but hopefully it's clear that if people use type to identify protective classes then it can be used to discriminate 22:20:12 Why would they? 22:20:16 ... I'm opposed to that 22:20:34 q? 22:20:49 q+ to note that `type` already exists in JSON-LD Context for things like key types... what should we do with that? 22:20:50 ... Once you say it's a person or it's not you are making an affirmative statemten about an entity, binding it to some entity 22:21:02 ... to me it's an architecturual problem that threatens the usability of DIDs worldwide 22:21:21 ... DIDs are an opportunity to have a globally verifiable demonstration of controlling a particular identifier without reliance on a third party. that's what's new and different 22:21:28 ... we don't need a lot of features that folks want for convienience 22:21:42 I'm afraid 'type' will become a place for pet names by default. 22:21:55 ... There is a movement to create DIDs that are created and biometrically bound to individuals such that everyone on the planet will only ever have one, not two, DIDs 22:22:07 ... I do not want to support a system that does that. That's what we are here to fight against 22:22:16 I agree that that's scary from a privacy perspective. 22:22:26 Joe is referring to the DID Alliance and GADI. Which IMHO is a complete perversion of what DIDs are for. 22:22:32 ... My fear is regulators in europe wille valuate what these guys in the DID alliance are doing, and read the DID spec, and see that DIDs are about creatin ga permanent directory of everyone and everything in such a way that DIDs are non gdpr compliant 22:22:42 ... which means we could not use DIDs for human beings in a european juristiction 22:22:45 ack manu 22:22:45 manu, you wanted to note that `type` already exists in JSON-LD Context for things like key types... what should we do with that? 22:23:03 manu: without editor hat on, I'm concerned about the privacy implications associated with type. It can be used for some fairly terrible things 22:23:16 ... I'm trying to square that with the fact we use type for other things - key type exists, we use it in other places 22:23:20 ... it's a natural thing that exists in JSON-LD 22:23:24 q+ 22:23:30 ... I'm trying to figure out what set of normative text we would put in the spec that everyone could agree to 22:23:40 Add text that no human types should be used in a DID Doc 22:23:43 ... banning type oturight would be problematic becuase then we have to search for what are we going to use to express key types and service types 22:23:44 q+ 22:23:45 q 22:23:46 ... theyre at a lower layer 22:23:48 q+ no one is proposing to ban type outright 22:23:50 +1 to doing what we can in the DID spec to help avoid creating GDPR concerns 22:23:55 Or dog types, because I like them even more most of the time 22:24:00 ... some language that might be proposed is you must not use type at the top level to be associated with the DID subject 22:24:06 ... but then you ban the ability for any did method to use it 22:24:20 ... the only thing I can see right now we may get consensus around is you should not use type to express the type of the DID subjet in the DID document 22:24:30 ... that would send a stron gmessage while allowing DID methods to override it 22:24:32 Orie, the bad guys will clearly mark themselves as criminals, for easy arrest 22:24:37 ... I'm interested if that would e acceptable to Joe 22:25:00 JoeAndrieu: I think so, manu, I'd like to see it in writing 22:25:03 q+ to ask about use for pet names 22:25:11 ... I was mentally addressing a different part that you started with - I'm not suggesting we ban type 22:25:17 ... I'm saying it should not be encouraged by being a core property 22:25:31 ... i would prefer to ban it, but because of other irrevokable decisions I odn't think it makes sense to try 22:25:38 ... the type for other parts in the graph is a different issue from the type of the subject 22:25:45 ack jonathan_holt 22:25:49 ... they dont' have privacy implicatios of the human referant 22:26:08 jonathan_holt: I can see why it's there but the challenge is the ethical error. IBM and the holocaust is a scary read and has direct implications 22:26:13 ... I'm not in support of it being a core property 22:26:23 ... we have the registries for those who feel they want to add it. And we have no way of enforcing it 22:26:26 service: [{type: "InsulinPumpPurchaseService", serviceEndpoint: "https://ihavediabetes.com"}] 22:26:32 ... you're the controller, you can change it, one day your'e a dog, one day you're an IoT device 22:26:35 q+ 22:26:37 ... these are assertions made by the DID controller 22:26:46 ack justin_r 22:26:49 q+ to mention, it's already a core property and put forward a concrete proposal to straw poll w/ the group. 22:26:51 ... there are other ways of doing this including proof of humannes in a verifiable credential that doesnt' belong in a DID core property 22:27:00 The systems that allow for things like NPM software packages to have DIDs and be internally typed as such, will just eat everything else 22:27:10 So in that sense, I guess I don't care 22:27:11 justin_r: echo what people hae been saying in chat - you can't prevent people from doing things you dont' liek with technology, that is the nature of technology, it's a tool in whoever's hands 22:27:18 q+ 22:27:29 ... that said, the focus on this specific property is potentially getting mired in the philosophy of what we would like to do with DID docments as a whole 22:27:54 ... this maybe a better fit for a discussion in the document on what you are allowed to express about the DID subject, with reasoning behind it, as opposed to tying it to a specific type property 22:28:05 ack agropper 22:28:05 agropper, you wanted to ask about use for pet names 22:28:06 ... then somebody comes up with something else named kindOf entity and puts the stuff you don't like in there 22:28:15 agropper: I want to speak against making type a core property 22:28:16 +1 to what justin just said... people will just start using "kind" :) 22:28:18 ***shrugs*** I guess I'll just take all your non-human typed DID use cases. 22:28:25 Thank you? 22:28:53 ... from the perspective that we try to put in some kind of language like the PR that was proposed, it's very hard to keep people from using type as ap lace to put a petname. That is a layer violation that is both unnecessary and would be very difficult, the temptation to use it for petnames, is huge 22:28:55 ack tplooker 22:28:57 dmitriz has joined #did 22:29:07 tplooker: I remain on the fence 22:29:16 q+ 22:29:18 q+ to speak to the larger point of DID document properties used to describe human subjects. 22:29:21 ... if we elect not to have this as a core propety we lose the opportunity to talk about sensible usage of it in the Core spec 22:29:26 present+ 22:29:26 q+ 22:29:30 ack manu 22:29:30 manu, you wanted to mention, it's already a core property and put forward a concrete proposal to straw poll w/ the group. 22:29:36 q+ to explain we can put whatever guidance in the spec we want 22:29:36 ... people will create their own property and there will be no guidence in DID core around how it should be used 22:29:43 q+ to explain pet name 22:29:45 +1 since we can't stop people -- so we should offer advice (speak against) doing certain things in the spec (which should also help people reading it to evaluate it from a GDPR perspective) 22:29:47 manu: type is already a core property 22:29:53 ... it is going to be impossible for us to not make type a core property 22:30:04 ... if we say type cannot be a core property we will break the typing system in the spec 22:30:10 ... we will no longer be able to express the type of key material 22:30:21 JoeAndrieu: no, that's a strawman that is not what's on the table 22:30:27 manu: I'm making a technical point 22:30:48 JoeAndrieu: type as a predicate of the subject I do not want and I do not believe it's in core properties 22:31:16 manu: trying to make sure everyone understands that is what is being said 22:31:25 q- 22:31:35 ack Orie 22:31:59 Orie: I hate to stir the pot, but someone did mention at IIW that one factor in enforcement characteristcs associated with compliance was this idea that if you claim to be a person then you're entitled to those rights 22:32:12 ... ther emight be a case where saying you're a person is the beginning to use SSI to assert your rights in a digital era 22:32:36 ack drummond 22:32:36 drummond, you wanted to speak to the larger point of DID document properties used to describe human subjects. 22:32:36 ... I'm not sure that in terms of protecting folks.. we may be closing a door that maybe useful for protecting some humans 22:33:10 drummond: I want to reinforce earlier, it's a larger point, that while it's imporatn we decide about type, it has beocme a lightning rod for any property of a DID doc that might be used to describe a human subject 22:33:28 ... there are an infinite number of such properties, we can all agree it's .. with open world we can never prevent that happening 22:33:43 q+ to PROPOSAL: DID Methods SHOULD NOT allow the expression of express type information for the DID Subject if the DID subject is not a non-person entity. 22:33:58 ... I've made the same arguement that tobias brought up earlier, if we dont' define it we wont' be able to provide strong guidence about its usage. I've revised that opinion to recognise that any property that could be used to desribe the did subject there are privacy issues if they are a human 22:34:02 ... that guidence we can and should provide in the spec 22:34:12 ... joe and I spent time covering what should be in that 22:34:17 ... it does blanket apply to all such properties 22:34:31 ack dbuc 22:34:33 ... we need to recognise the open world data model such that we need to provide that guidence about properties we don't define and are not registered but still have the same issues 22:34:52 dbuc: I dont think that human types are good at all, we banned it in ion. Humans don't need it 22:34:52 q+ to PROPOSAL: DID Methods SHOULD NOT allow the expression of type information for the DID Subject if the DID subject is not a non-person entity. 22:34:58 To Manu's proposal, my argument about pet names is not specific to human subjects. 22:35:01 ... non human types are fantastic 22:35:12 q+ 22:35:13 ... things like I want to redo npm and remove microsoft 22:35:23 ... You're not going to stop those use cases, we'll do them internal to the method 22:35:27 ... non human types will be supported 22:35:31 ack JoeAndrieu 22:35:31 JoeAndrieu, you wanted to explain we can put whatever guidance in the spec we want 22:35:33 ... it's your choice to give us those use cases 22:35:58 Directly in the eye 22:36:02 q? 22:36:05 in the faaaace 22:36:05 JoeAndrieu: it's an unfortunte argument tobials - we can put whatever guidence we want in. We don't need to have the property in order to have privacy and security guidence 22:36:06 ack agropper 22:36:06 agropper, you wanted to explain pet name 22:36:19 +1 to not needing a property to provide guidance -- that's what I was saying before, it's beyond just this one property 22:36:39 +1 to justin & joe (re guidance) 22:36:39 q- 22:36:42 agropper: the DIDs as they stand are not human friendly. They're not going to be squatted on because they're a favourite name, or if you want to have two you're going to have to out of band in whatever wallet you're going to have to label them somehow 22:37:03 q+ 22:37:05 ... if we put a type property in it will become the first place that methods and people n general will put in the petname, the human recognisable or valuable in the vanity sense relationship or identifier 22:37:13 ... I don't think we want to encourage that 22:37:19 ... that's a layer violation 22:37:20 Our scheme in ION is going to be based on a 4 byte type tag registry of all non-human types 22:37:35 ... And the pet name perspective applies to nonhuman subjects just as much 22:37:36 DID users will not have the ability to override that to add petnames 22:37:40 or any human types 22:37:51 first one will be software package 22:37:53 ... once we start encouraging people to self describe whatever the thing is we're just oening up a pandoras box of squatting and other elements that we really don't need to 22:37:58 and next is company 22:38:06 ... I'm not against manu's point, I'm not against subverting linked data 22:38:14 ack manu 22:38:14 manu, you wanted to PROPOSAL: DID Methods SHOULD NOT allow the expression of express type information for the DID Subject if the DID subject is not a non-person entity. and to 22:38:17 ... PROPOSAL: DID Methods SHOULD NOT allow the expression of type information for the DID Subject if the DID subject is not a non-person entity. 22:38:17 ... I don't think we want to draft language that refers to human subjects and type fro what I've heard so far 22:38:24 q+ to talk about the entire issue of DIDs for human subjects 22:38:31 manu: I'd like to see if this proposal is along the lines of what Joe was thinking 22:38:41 ^ 22:38:42 -1 poorly written 22:38:46 q+ 22:38:47 -1 22:38:54 q+ 22:38:54 -1 22:38:55 IS a human entity 22:38:58 ... please rewrite it so its better 22:39:01 -1 22:39:04 that language sounds odd 22:39:10 also, absence of it makes assumptions to the opposite being true 22:39:14 ack jonathan_holt 22:39:31 jonathan_holt: I understand dbuc's need for iot devices and there's a whole ecosystem where you need devices to talk to each other without having that as a vc 22:39:37 ... I don't think it belongs in the core spec, this is why we have extensions 22:39:39 q- 22:40:05 ack drummond 22:40:05 drummond, you wanted to talk about the entire issue of DIDs for human subjects 22:40:09 ... I think the privacy implications of this.. if we make it optional there will be regulation say a bank forces you to have a DID with a type property because they don't want to deal with a VC exchange - we're opening a pandora's box for major ethical and privacy concerns we need to htink thorugh before we allow that 22:40:41 drummond: I want to emphasise that in our perspective on this, pull us back from type to any property in a DID doc that would be used to describe a human.. problem we need to address in the DID spec is DIDs for humans 22:41:04 q+ brent to poll: PROPOSAL: DID Methods SHOULD NOT allow the expression of type information for the DID Subject. 22:41:10 I will use a DID that is highly correlated to me for Twitter and LinkedIn, but don't need a human type for it 22:41:16 Do we want to encourage pet names for things or documents in the core spec? 22:41:29 ... the privacy guidence we need to provide around that, I think applies to any property that would... we already are under the spotlight for providing a tool like that. At the asme time the european commission and their blockchain observatory group has sent positive ndications of SSI 22:41:34 ... as a tool for individual control of personal data 22:41:41 ... it's not a hopeless cause at all but we do need to be careful in drawing that line 22:41:48 ... this is not just a discussion around a type 22:41:53 ... I have been an advocate 22:42:03 ... because of the need to describe things that are not humans 22:42:17 if you need to prove you are a human, that can happen in VC/VP and the type property can be included in the DID subject section there. 22:42:20 ... the language I want to see and I'll help draft is about all the privacy issues with all of the concerns about DIDs and any properties used for a human subject 22:42:34 ack JoeAndrieu 22:42:51 JoeAndrieu: if we have type but say you can't use it to say type person, it becomes type person when it's not there 22:42:53 That's not true 22:42:57 ... 22:43:08 q? 22:43:12 ... if daniel is correct and all thes iot use cases and other methods are going to use type to distinguish between person and non persoon then the nonvalue becomes a filter to identify persons 22:43:22 ... I don't share drummond's conviction that DIDs are defactor or de jure PII 22:43:25 there are so many things that will have no type that it's ridiculously large anonymity set 22:43:36 ... I think there is a .. under gdpr IP address have been both 22:43:38 That assumes the enumeration of possible types is well known 22:43:44 Yeah +1 dbuc 22:43:46 ... it depends on the usage of those IP addresses and the linkability of the IP address to specific ndividuals 22:43:51 ... We have the same problem here 22:44:03 ... to the extent that we maintain a narrative that DIDs refer to specific individuals forever it will fall under gdpr 22:44:08 ... but we don't have to have that narrative 22:44:09 q+ dlongley to PROPOSAL: The DID spec should say that DID Documents should not express characteristics that are intrinsically bound to a person. 22:44:12 ack brent 22:44:12 brent, you wanted to poll: PROPOSAL: DID Methods SHOULD NOT allow the expression of type information for the DID Subject. 22:44:17 ... it should be about proving control of the identifier and not the individual 22:44:19 I don't agree with Joe's point that the absence of 'type' will mean the DID subject is a human. There are legions of use cases for all types of DID subjects that will not require a type property. 22:44:27 agree with JoeAndrieu absence will assume person. 22:44:27 brent: I'm goign to run a proposal to see where people stand on this 22:44:31 PROPOSAL: DID Methods SHOULD NOT allow the expression of type information for the DID Subject. 22:44:37 +1 22:44:37 +0.734 22:44:38 -1 22:44:40 -1 22:44:41 +1 22:44:42 -1 22:44:57 ~0 22:45:05 -0 22:45:07 ~0 22:45:08 -1 22:45:11 +0 22:45:14 0, depends how 22:45:15 q? 22:45:27 Note: the less scalable, more obscure methods are the ones you will hurt with this, game theoretically 22:45:30 ack dlongley 22:45:30 dlongley, you wanted to PROPOSAL: The DID spec should say that DID Documents should not express characteristics that are intrinsically bound to a person. 22:45:31 shigeya has joined #did 22:45:48 dlongley: I have another proposal,the problem seems to be due to an intrinsic bndng of a person 22:45:54 we already say that, actually 22:45:59 ... right now the information is not intrinsically bound to a person, public keys and things 22:46:00 Ooooh, very nice. 22:46:02 PROPOSAL: The DID spec should say that DID Documents should not express characteristics that are intrinsically bound to a person. 22:46:04 what does that mean? 22:46:05 +1 22:46:06 +1 22:46:10 +1 22:46:11 +1 22:46:14 +1 22:46:17 +1 we already say that, btw 22:46:18 +1 22:46:19 +1 22:46:19 +1 22:46:20 ~0 22:46:20 +1 22:46:25 drummond: that's a very elegant way of putting it 22:46:26 +0 22:46:32 q? 22:46:35 dmitriz: what does that mean? 22:46:42 q+ 22:46:45 0, not sure what this means 22:46:48 -1 22:46:49 dlongley: effectively means there's no way for you to unlink it from the person 22:46:56 ... the piece of information and the linkage int he DID doc is bound to you 22:47:01 ... there's no way to break the linkage 22:47:09 E.g you can't stop being a person but you could stop associating to a public key? 22:47:15 ... which is fundamentally different from expressing information that is oudn to you from some other informatin not in the DID doc 22:47:28 ... eg. if a VC goes away the DID doc with just the public key no longer links you 22:47:36 ... but if it has your personal name in the DID doc that's intrinsically linked to you 22:47:37 ack kdenhartog 22:47:54 @manu OMG, you actually said that! ;-) 22:47:54 I mean, you can, by just not using it 22:48:02 q+ to say why I'm the only -1 22:48:12 ack agropper 22:48:12 agropper, you wanted to say why I'm the only -1 22:48:19 human/non-human is better imo 22:48:21 kdenhartog: maybe we say DID subjects that are non information resources? should not allow type information for subjects that are non informatin resources. But could impact organisations 22:48:27 I still dont think it goes far enough though what about your name? Is that intrinsically bound? 22:48:30 -0 because I still don't quite understand. 22:48:42 JoeAndrieu, where do we say that proposal in the spec? 22:48:49 q? 22:48:55 agropper: I seem to be the only -1 so maybe I'm just misunderstanding.. I'm confused because Joe +1. My feeling is this has nothing to do with whether it's a human subject or a thing 22:49:00 @dlongley I'm looking for it 22:49:07 I quoted it in the issue 22:49:14 ... once we open up this pandoras box, which I don't see is necessary, I have no bojection with type being used for key material or other aspects of the DID doc, that would be great 22:49:22 ... I'm looking forward to the conversation around service endpoitns and mediators 22:49:44 dlongley -- maybe this? https://w3c.github.io/did-core/#authentication-and-verifiable-claims 22:49:47 ... and our ability, whether thething is a person or a thing, to use the control property of the DID doc in a broad way by doing the right thing around the service endpoitns as the extension or binding mechanism to the idnetifier 22:50:11 q? 22:50:11 ... and putting in a type as a core property violates .. that's too strong.. the ability for the controller of the DID doc to move discovery 22:50:17 ... to other layers of the protocols 22:50:38 q+ to ask Joe what we could say? 22:50:42 ack manu 22:50:42 manu, you wanted to ask Joe what we could say? 22:50:44 burn: we had al ot of +s. Not perfect but may be moving more in the direction that we need to 22:50:45 quoting DID spec: "The process of binding a DID to something in the real world, such as a person or a company, for example with credentials with the same subject as that DID, is out of scope for this specification. For more information, see the [VC-DATA-MODEL] instead."" 22:50:55 manu: I'm struggling to understand what we would say that would address Joe's concern that we could get consensus on 22:50:57 q+ 22:51:00 ... I feel like we've polled every variation 22:51:02 I think he doesn't want them in, so saying something isn't doing that 22:51:04 jonathan_holt, yeah, that doesn't seem to go as far as the proposal. 22:51:12 ... I think you're making good poitns> i think we do have agreement as a group about th dangers here 22:51:18 jonathan_holt, we shouldn't just say it's out of scope, we should say don't do it. 22:51:20 ... We need something concrete 22:51:50 JoeAndrieu: we don't need to put anything in the spec. We have an open world data model. Method providers can already use type. We can have another conversation about how to filter inappropriate registry entries 22:51:51 q+ 22:51:54 ack kdenhartog 22:52:00 ... The proposal is to add something that doesn't have consensus. The right process is to not add it 22:52:03 I think JoeAndrieu is conflating "add text to the spec" with "add the 'type' property to the spec" 22:52:06 REQUEST FROM EARLIER: can we schedule a special topic call for equivalence properties? 22:52:07 q+ but "@type": "type" exists in the JSON-LD context 22:52:12 q+ to note but "@type": "type" exists in the JSON-LD context 22:52:19 q? 22:52:22 kdenhartog: is there any way we could namespace reserve this using the context. So if you used a person then you're violating a protected term? is there any way to technically enforce that? 22:52:23 ack manu 22:52:23 manu, you wanted to note but "@type": "type" exists in the JSON-LD context 22:52:34 iPerson 22:52:35 isPerson: true 22:52:37 manu: no kyle, someone will create person2 or thePerson or RealPerson, becomes an endless game of whackamole 22:52:58 ... The thing I'm concerned about Joe is that if we put nthing in the DID core spec, the jsonld context still has type in there and we still use type in key types 22:53:01 JoeAndrieu said earlier he has no problem with that 22:53:21 ... I'm guessing you're saying that's fine to keep ti in the jsonld context, talk about type as it relates to key types i nthe spec, but dont' create a top level type property. Thta's my interpretation 22:53:21 q? 22:53:22 q? 22:53:52 JoeAndrieu: I don't feel that the context is the definitive statement about whta the properties are. It should be fixed if there isnt' a type specified at the top level. I'm not a jsonld expert to know how to do that 22:54:00 q+ 22:54:01 ... if we can't do that to me that would be a limitation of json ld, not of the spec 22:54:03 ack manu 22:54:18 Orie: is type a property of the ADM, which would make type a property of the DID subject? 22:54:48 q? 22:54:56 q+ 22:54:56 in my opinion it should not be. at the top level type should be the type of the did document, not the type of the did subject 22:55:02 ack dlongley 22:55:04 JoeAndrieu: no, it's a type of specific elements in the data model. We can scope all of that to the properties. By not scoping it to subject and having it everywhere we are inviting peole to put it in the subject. That's not in the spec, that's in the context, currently. The context should reflect the spec. I think the context is not aligned with the rest of the spec right now 22:55:16 dlongley: if someone puts type n a DID doc it will go in as a property in the ADM just based on how that entire thing works 22:55:21 ... we just don't need to say anything about it, is my read 22:55:30 q+ 22:56:05 burn: sounds like maybe there's some communication Joe should have with manu and/or Dave about the syntactic structuring and what it means for type to be a top level property, or its relationship with the ADM 22:56:08 q- 22:56:10 there's nothing to do -- we'd have to "ban" it ... and that is useless as many have stated, we just don't do anything special. 22:56:18 ... i think that might be good to check to make sure what you're asking for can be achieved 22:56:25 JoeAndrieu: I am not proposing that type be banned 22:56:30 q+ 22:56:31 ... i'd prefer it, but it's not viable 22:56:33 q+ 22:56:39 JoeAndrieu can you make a proposal? 22:56:42 ... I'm not saying the context needs to say you cannot use type for the subject but here use it everywhere else 22:56:46 ... THe spec is what I'm concerned about 22:56:58 ... how closely the context provides a programmatic interface to the spec its a jsonld question 22:57:05 ... if the contxt doesnt' do anything about it, we're fine, other people can add it 22:57:07 ack kdenhartog 22:57:41 kdenhartog: we had had a similar discussion in the ADM about the @context property and how if it's related to a specific representatin that maybe we should be removing them as core properties. That may fall in that discussion as well, if it's a property just for jsonld aspects 22:57:44 ack drummond 22:57:44 +1 to Kyle 22:57:51 ... if we're using it to describe DID subject I don't think that holds 22:57:52 +1 kyle 22:58:13 drummond: regardless of whether type or other property that could be used to describe DID subject htat's a human is in did core or not I think we need same guidence about any property used to identify or describe a human 22:58:23 "type" is not syntax/representation specific 22:58:28 Before the call ends: 22:58:29 REQUEST FROM EARLIER: can we schedule a special topic call for equivalence properties? 22:58:30 ... Just reminding everyone of that, get ready for language in the spec that talks about that. It's one of thousands of properties that could be used. We have to provide guidence about that. 22:58:37 +1 to drummond 22:58:52 will do 22:58:55 thk 22:58:58 you 22:58:59 @Amy I am going to nominate you for Scribe of the Year. You are amazingly fast and accurate. 22:59:15 burn: manu, want to summarise? 22:59:23 Summary: ***pillow screaming*** 22:59:24 +1 Amy as scribe of the year 22:59:28 manu: i belive the current proposal from joe is don't say anything about type in the top layer of the spec 22:59:35 JoeAndrieu: we can have guidence! 22:59:35 Joe said: JoeAndrieu Orie, my proposal is we don't *add* type to the core properties. 22:59:41 ... I'm saying don't put it in core properties 22:59:55 +1 to drummond, we need to explore the potential implications of our technology 22:59:59 Joe's proposal: don't merge the PR and add some additional privacy guidance text? 23:00:00 No serious methods will even allow it 23:00:03 manu: I don't know how to do that 23:00:09 JoeAndrieu: Just don't accept this PR it's very simple 23:00:18 manu: it doesn't align with don't put it in core properties 23:00:23 I will personally file Issues on their Method repos to wag a finger at them 23:00:23 JoeAndrieu: it's in the context, not the spec 23:00:31 manu: the ADM doesn't allow this 23:00:36 I think this is caused by the confusing nature of the ADM 23:00:45 I don't think it is in the spec, only JSON-LD 23:00:47 +1 orie :) 23:00:47 burn: there's a clear nonunderstanding right now. You need to talk about that specifically 23:00:48 I will strongly defend that the use of 'type' in the Appendix draft was NOT a privacy violation. It was a conscious assertion by a DID controller in her own DID document. 23:00:52 clearly its not obvious that aribitrary properties are preserved. 23:00:55 ... thanks everyone! 23:00:57 +1 Orie 23:01:02 not seeing type here: https://w3c.github.io/did-core/#core-properties 23:01:03 Joe is opposed to that usage. I am not. 23:01:13 +1 to Orie 23:01:17 ... Reminder, face to face next week, no standard meeting 23:01:22 also +1 to what brent just said. it's not in that section 23:01:32 "preserve by default" hasn't fully sunken in yet. 23:01:55 or rather, we don't scope properties in DID Core 23:02:01 I mean, we kinda do 23:02:05 but type isn't one of them. 23:02:07 rrsagent, draft minutes 23:02:07 I have made the request to generate https://www.w3.org/2020/10/27-did-minutes.html burn 23:41:53 jonathan_holt has joined #did