DID WG Telco — Minutes

Date: 2020-10-27

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Brent Zundel, Justin Richer, Amy Guy, Drummond Reed, Wayne Chang, Adrian Gropper, Dave Longley, Shigeya Suzuki, Kyle Den Hartog, Tobias Looker, Jonathan Holt, Daniel Buchner, Joe Andrieu, Orie Steele, Dmitri Zagidulin

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Amy Guy

Content:

1. Agenda Review, Introductions, Re-introductions

Daniel Burnett: agenda summary… core of the meeting today is discussion on the type property
… if there’s time left, core issues
… any requests for changes or additions?
… nobody new, not doing intros

2. Special Topic Call

Daniel Burnett: the special topic call is Thursday at noon Eastern
… 9am Pacific… some mysterious time in europe
… 5pm or something in central europe
… the topic will be the abstract data model which may have a different name by then

Drummond Reed: this is the last call ever we will have about this

3. Face to Face Meeting

Daniel Burnett: in case you forgot, our virtual face to face meeting is next week
… monday through thursday
… we will not be having our usual DID WG call
… we’ll send a reminder
… US elections are happening on Tuesday so I would encourage you to plan around that

Jonathan Holt: I wanted to talk about cbor and discuss an invited expert

Jonathan Holt: roger, thanks!

Daniel Burnett: I can give you 5 minutes before we get to the type property

Daniel Buchner: Requested agenda item: coordinating special topic call for equivalence props

4. IIW Report

Daniel Burnett: anyone who can give us really big items that everyone should know about
… from anyone who was there

Jonathan Holt: tobias’ presentation on the identity providers to credential providers using openID was brilliant. Love it.

Daniel Burnett: tobias, when you have a link that would be great

Adrian Gropper: The ZACAP and GNAP harmony session was useful.

Joe Andrieu: +1 for KERI and separately GNAP

Drummond Reed: the KERI was a 24 hour all KERI news channel, continuous sessions on that topic
… folks on this WG migh be aware it’s adjacent to what we’re doing

Tobias Looker: Thanks Jonathan, link here https://mattrglobal.github.io/oidc-client-bound-assertions-spec/

Drummond Reed: thought the interest in KERI was a lot higher than I expected
… had a session on the first day on the basics and we had 116 people
… we attracted all the wizards so hard to keep it at a low level
… probably ten follow on sessions overall. very keen interest in that aspect of what we’re doing

Adrian Gropper: We had a great session with a lot of people from oauth2 and gnap and zcap types represented
… dmitri took some notes and I think we made some progress

Daniel Burnett: any other highlights from IIW?

Daniel Buchner: Requested agenda item: coordinating special topic call for equivalence props

5. CBOR

Jonathan Holt: I haven’t received much feedback on the cddl or cbor section apart from from Orie
… I got feedback from Carsten Bormann who wrote the cddl and he got back to me quickly
… 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
… I’ve looked into the formal definition of what an abstract data model is

Drummond Reed: 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).

Jonathan Holt: I think the CDDL provides that set of possible values and types
… in the DID Core spec we can define the set of operations
… the task for me was lossless transformation between json and cbor
… I intended to do that, gave examples for all the different items in the registry
… 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
… I’ve provided I think a scaffolding for the abstract data model
… and highlighted a lot of redundancies in the verification methods that could e more elegantly represented to simplify the abstract data model
… And I’d like to make a request, Carsten is a real cbor expert and it would be appropriate for us to invite him
… he participates in W3C standards

Justin Richer: Second the recommendation of bringing carsten in to comment on the cbor stuff
… he’s been the driving force behind cbor and cose

Daniel Burnett: would one of you be willing to contact him and have him reach out to the chairs?
… we should probably have him come and join us one meeting first and then we’ll see where to go from there
… we could potentially find time during the face to face if it’s next week, otherwise it’ll be after that

Jonathan Holt: sure thing

Daniel Burnett: questions?

Drummond Reed: +1 to inviting Carsten in.

6. Type property

Daniel Burnett: https://github.com/w3c/did-core/pull/410

Manu Sporny: at a high level the type discussion has basically turned into a question around the privacy implications of the type property
… initially the intent of the type property was to be able to express things such as the type of thing the DID subject represents
… 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

Dave Longley: or an insulin pump <– potential non-person privacy violation

Manu Sporny: I believe there have been a number of use cases outlined, I think 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
… I’ve spoken with a couple of people that have strong opinions about the usage of type
… 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
… I don’t think we’ve heard quite enough from the folks concerned about use of type
… Joe has good thoughts on the topic
… What potential compromise positions the group could get behind?
… There have been a number of resolutions we’ve taken on this topic
… THe first was consensus to add text to the spec to warn about how dangerous the use of type can be
… Amy has already written a PR expressing how use of type could be dangerous

Joe Andrieu: I can appreciate the value that some of the advocates of type see in the feature
… what I’m struggling with is why it should be a core property
… today, any method can provide a type value, although I don’t think there should be
… My issue is that it shouldn’t be a core property
… 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
… which comes down to for individuals this is a potential privacy leak that could cause human rights harms
… 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

Daniel Buchner: Why would they?

Joe Andrieu: I’m opposed to that
… Once you say it’s a person or it’s not you are making an affirmative statement about an entity, binding it to some entity
… to me it’s an architectural problem that threatens the usability of DIDs worldwide
… 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
… we don’t need a lot of features that folks want for convenience

Adrian Gropper: I’m afraid ‘type’ will become a place for pet names by default.

Joe Andrieu: 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
… I do not want to support a system that does that. That’s what we are here to fight against

Manu Sporny: I agree that that’s scary from a privacy perspective.

Drummond Reed: Joe is referring to the DID Alliance and GADI. Which IMHO is a complete perversion of what DIDs are for.

Joe Andrieu: My fear is regulators in Europe will evaluate what these guys in the DID alliance are doing, and read the DID spec, and see that DIDs are about creating a permanent directory of everyone and everything in such a way that DIDs are non GDPR compliant
… which means we could not use DIDs for human beings in a European juristiction

Manu Sporny: without editor hat on, I’m concerned about the privacy implications associated with type. It can be used for some fairly terrible things
… I’m trying to square that with the fact we use type for other things — key type exists, we use it in other places
… it’s a natural thing that exists in JSON-LD
… I’m trying to figure out what set of normative text we would put in the spec that everyone could agree to

Daniel Buchner: Add text that no human types should be used in a DID Doc

Manu Sporny: banning type outright would be problematic because then we have to search for what are we going to use to express key types and service types

Justin Richer: q

Manu Sporny: they’re at a lower layer

Dave Longley: +1 to doing what we can in the DID spec to help avoid creating GDPR concerns

Daniel Buchner: Or dog types, because I like them even more most of the time

Manu Sporny: some language that might be proposed is ‘you must not use type at the top level to be associated with the DID subject’
… but then you ban the ability for any did method to use it
… 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 subject in the DID document
… that would send a strong message while allowing DID methods to override it

Daniel Buchner: Orie, the bad guys will clearly mark themselves as criminals, for easy arrest

Manu Sporny: I’m interested if that would e acceptable to Joe

Joe Andrieu: I think so, manu, I’d like to see it in writing
… I was mentally addressing a different part that you started with — I’m not suggesting we ban type
… I’m saying it should not be encouraged by being a core property
… i would prefer to ban it, but because of other irrevocable decisions I don’t think it makes sense to try
… the type for other parts in the graph is a different issue from the type of the subject
… they dont’ have privacy implications of the human referent

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
… I’m not in support of it being a core property
… we have the registries for those who feel they want to add it. And we have no way of enforcing it

Dave Longley: service: [{type: "InsulinPumpPurchaseService", serviceEndpoint: "https://ihavediabetes.com"}]

Jonathan Holt: you’re the controller, you can change it, one day your’e a dog, one day you’re an IoT device
… these are assertions made by the DID controller
… there are other ways of doing this including proof of humans in a verifiable credential that doesn’t belong in a DID core property

Daniel Buchner: The systems that allow for things like NPM software packages to have DIDs and be internally typed as such, will just eat everything else. So in that sense, I guess I don’t care

Justin Richer: echo what people have been saying in chat — you can’t prevent people from doing things you don’t like with technology, that is the nature of technology, it’s a tool in whoever’s hands
… that said, the focus on this specific property is potentially getting mired in the philosophy of what we would like to do with DID documents as a whole
… 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
… then somebody comes up with something else named kindOf entity and puts the stuff you don’t like in there

Adrian Gropper: I want to speak against making type a core property

Orie Steele: +1 to what justin just said… people will just start using “kind” :)

Daniel Buchner: shrugs I guess I’ll just take all your non-human typed DID use cases.

Daniel Buchner: Thank you?

Adrian Gropper: 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 a place to put a pet name. That is a layer violation that is both unnecessary and would be very difficult, the temptation to use it for petnames, is huge

Tobias Looker: I remain on the fence
… if we elect not to have this as a core property we lose the opportunity to talk about sensible usage of it in the Core spec
… people will create their own property and there will be no guidance in DID core around how it should be used

Dave Longley: +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)

Manu Sporny: type is already a core property
… it is going to be impossible for us to not make type a core property
… if we say type cannot be a core property we will break the typing system in the spec
… we will no longer be able to express the type of key material

Joe Andrieu: no, that’s a strawman that is not what’s on the table

Manu Sporny: I’m making a technical point

Joe Andrieu: type as a predicate of the subject I do not want and I do not believe it’s in core properties

Manu Sporny: trying to make sure everyone understands that is what is being said

Orie Steele: I hate to stir the pot, but someone did mention at IIW that one factor in enforcement characteristics associated with compliance was this idea that if you claim to be a person then you’re entitled to those rights
… there might be a case where saying you’re a person is the beginning to use SSI to assert your rights in a digital era
… I’m not sure that in terms of protecting folks… we may be closing a door that maybe useful for protecting some humans

Drummond Reed: I want to reinforce earlier, it’s a larger point, that while it’s important we decide about type, it has become a lightning rod for any property of a DID doc that might be used to describe a human subject
… there are an infinite number of such properties, we can all agree it’s .. with open world we can never prevent that happening
… I’ve made the same argument that Tobias brought up earlier, if we don’t define it we won’t be able to provide strong guidance about its usage. I’ve revised that opinion to recognise that any property that could be used to describe the did subject there are privacy issues if they are a human
… that guidance we can and should provide in the spec
… joe and I spent time covering what should be in that
… it does blanket apply to all such properties
… we need to recognise the open world data model such that we need to provide that guidance about properties we don’t define and are not registered but still have the same issues

Daniel Buchner: I don’t think that human types are good at all, we banned it in ion. Humans don’t need it

Adrian Gropper: To Manu’s proposal, my argument about pet names is not specific to human subjects.

Daniel Buchner: non human types are fantastic
… things like I want to redo npm and remove microsoft
… You’re not going to stop those use cases, we’ll do them internal to the method
… non human types will be supported
… it’s your choice to give us those use cases

Daniel Buchner: Directly in the eye

Daniel Buchner: in the faaaace

Joe Andrieu: it’s an unfortunate argument tobias — we can put whatever guidance we want in. We don’t need to have the property in order to have privacy and security guidance

Justin Richer: +1 to not needing a property to provide guidance – that’s what I was saying before, it’s beyond just this one property

Dmitri Zagidulin: +1 to justin & joe (re guidance)

Adrian Gropper: 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
… 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
… I don’t think we want to encourage that
… that’s a layer violation

Daniel Buchner: Our scheme in ION is going to be based on a 4 byte type tag registry of all non-human types

Adrian Gropper: And the pet name perspective applies to nonhuman subjects just as much

Daniel Buchner: DID users will not have the ability to override that to add petnames or any human types; first one will be software package and next is company

Adrian Gropper: once we start encouraging people to self describe whatever the thing is we’re just opening up a pandora’s box of squatting and other elements that we really don’t need to
… I’m not against manu’s point, I’m not against subverting linked data
… I don’t think we want to draft language that refers to human subjects and type fro what I’ve heard so far

Manu Sporny: I’d like to see if this proposal is along the lines of what Joe was thinking

Amy Guy: ^

Jonathan Holt: -1 poorly written

Orie Steele: -1

Adrian Gropper: -1

Daniel Buchner: IS a human entity

Manu Sporny: please rewrite it so its better

Joe Andrieu: -1

Daniel Buchner: that language sounds odd

Jonathan Holt: also, absence of it makes assumptions to the opposite being true

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
… I don’t think it belongs in the core spec, this is why we have extensions
… 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 think through before we allow that

Drummond Reed: I want to emphasize 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

Daniel Buchner: I will use a DID that is highly correlated to me for Twitter and LinkedIn, but don’t need a human type for it

Adrian Gropper: Do we want to encourage pet names for things or documents in the core spec?

Drummond Reed: the privacy guidance 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 same time the european commission and their blockchain observatory group has sent positive indication of SSI
… as a tool for individual control of personal data
… it’s not a hopeless cause at all but we do need to be careful in drawing that line
… this is not just a discussion around a type
… I have been an advocate
… because of the need to describe things that are not humans

Jonathan Holt: 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.

Drummond Reed: 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

Joe Andrieu: if we have type but say you can’t use it to say type person, it becomes type person when it’s not there
… if daniel is correct and all these iot use cases and other methods are going to use type to distinguish between person and non person then the non-value becomes a filter to identify persons
… I don’t share drummond’s conviction that DIDs are de facto or de jure PII

Daniel Buchner: there are so many things that will have no type that it’s ridiculously large anonymity set

Joe Andrieu: I think there is a .. under GDPR IP address have been both

Tobias Looker: That assumes the enumeration of possible types is well known

Tobias Looker: Yeah +1 dbuc

Joe Andrieu: it depends on the usage of those IP addresses and the linkability of the IP address to specific individuals
… We have the same problem here
… to the extent that we maintain a narrative that DIDs refer to specific individuals forever it will fall under GDPR
… but we don’t have to have that narrative
… it should be about proving control of the identifier and not the individual

Drummond Reed: 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.

Jonathan Holt: agree with JoeAndrieu absence will assume person.

Brent Zundel: I’m going to run a proposal to see where people stand on this

Proposed resolution: DID Methods SHOULD NOT allow the expression of type information for the DID Subject. (Brent Zundel)

Adrian Gropper: +1

Manu Sporny: +0.734

Drummond Reed: -1

Orie Steele: -1

Joe Andrieu: +1

Daniel Buchner: -1

Justin Richer: ~0

Dmitri Zagidulin: -0

Tobias Looker: ~0

Kyle Den Hartog: -1

Amy Guy: +0

Jonathan Holt: 0, depends how

Daniel Buchner: Note: the less scalable, more obscure methods are the ones you will hurt with this, game theoretically

Dave Longley: I have another proposal,the problem seems to be due to an intrinsic binding of a person

Joe Andrieu: we already say that, actually

Dave Longley: right now the information is not intrinsically bound to a person, public keys and things

Drummond Reed: Ooooh, very nice.

Proposed resolution: The DID spec should say that DID Documents should not express characteristics that are intrinsically bound to a person. (Dave Longley)

Dmitri Zagidulin: what does that mean?

Manu Sporny: +1

Drummond Reed: +1

Dave Longley: +1

Amy Guy: +1

Daniel Buchner: +1

Joe Andrieu: +1 we already say that, btw

Tobias Looker: +1

Brent Zundel: +1

Kyle Den Hartog: +1

Justin Richer: ~0

Shigeya Suzuki: +1

Drummond Reed: that’s a very elegant way of putting it

Orie Steele: +0

Dmitri Zagidulin: what does that mean?

Jonathan Holt: 0, not sure what this means

Adrian Gropper: -1

Dave Longley: effectively means there’s no way for you to unlink it from the person
… the piece of information and the linkage int he DID doc is bound to you
… there’s no way to break the linkage

Tobias Looker: E.g you can’t stop being a person but you could stop associating to a public key?

Dave Longley: which is fundamentally different from expressing information that is bound to you from some other information not in the DID doc
… eg. if a VC goes away the DID doc with just the public key no longer links you
… but if it has your personal name in the DID doc that’s intrinsically linked to you

Drummond Reed: @manu OMG, you actually said that! ;-)

Daniel Buchner: I mean, you can, by just not using it

Daniel Buchner: human/non-human is better imo

Kyle Den Hartog: maybe we say DID subjects that are non information resources? should not allow type information for subjects that are non information resources. But could impact organisations

Tobias Looker: I still dont think it goes far enough though what about your name? Is that intrinsically bound?

Dmitri Zagidulin: -0 because I still don’t quite understand.

Dave Longley: JoeAndrieu, where do we say that proposal in the spec?

Adrian Gropper: 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

Joe Andrieu: @dlongley I’m looking for it

Joe Andrieu: I quoted it in the issue

Adrian Gropper: once we open up this pandora’s box, which I don’t see is necessary, I have no objections with type being used for key material or other aspects of the DID doc, that would be great
… I’m looking forward to the conversation around service endpoints and mediators

Manu Sporny: dlongley – maybe this? https://w3c.github.io/did-core/#authentication-and-verifiable-claims

Adrian Gropper: and our ability, whether the thing 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 endpoints as the extension or binding mechanism to the identifier
… 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
… to other layers of the protocols

Daniel Burnett: we had a lot of +s. Not perfect but may be moving more in the direction that we need to

Jonathan Holt: 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.””

Manu Sporny: I’m struggling to understand what we would say that would address Joe’s concern that we could get consensus on
… I feel like we’ve polled every variation

Daniel Buchner: I think he doesn’t want them in, so saying something isn’t doing that

Dave Longley: jonathan_holt, yeah, that doesn’t seem to go as far as the proposal.

Manu Sporny: I think you’re making good poitns> i think we do have agreement as a group about th dangers here

Dave Longley: jonathan_holt, we shouldn’t just say it’s out of scope, we should say don’t do it.

Manu Sporny: We need something concrete

Joe Andrieu: 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
… The proposal is to add something that doesn’t have consensus. The right process is to not add it

Justin Richer: I think JoeAndrieu is conflating “add text to the spec” with “add the ‘type’ property to the spec”

Daniel Buchner: REQUEST FROM EARLIER: can we schedule a special topic call for equivalence properties?

Kyle Den Hartog: 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?

Daniel Buchner: iPerson

Justin Richer: isPerson: true

Manu Sporny: no kyle, someone will create person2 or thePerson or RealPerson, becomes an endless game of whackamole
… The thing I’m concerned about Joe is that if we put nothing in the DID core spec, the jsonld context still has type in there and we still use type in key types

Dave Longley: JoeAndrieu said earlier he has no problem with that

Manu Sporny: 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 in the spec, but dont’ create a top level type property. That’s my interpretation

Joe Andrieu: I don’t feel that the context is the definitive statement about what the properties are. It should be fixed if there isn’t a type specified at the top level. I’m not a JSON-LD expert to know how to do that
… if we can’t do that to me that would be a limitation of JSON-LD, not of the spec

Orie Steele: is type a property of the ADM, which would make type a property of the DID subject?

Brent Zundel: 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

Joe Andrieu: 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 people 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.

Dave Longley: if someone puts type in a DID doc it will go in as a property in the ADM just based on how that entire thing works

Dave Longley: 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.

Dave Longley: we just don’t need to say anything about it, is my read

Daniel Burnett: 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
… i think that might be good to check to make sure what you’re asking for can be achieved

Joe Andrieu: I am not proposing that type be banned
… i’d prefer it, but it’s not viable

Orie Steele: JoeAndrieu can you make a proposal?

Joe Andrieu: I’m not saying the context needs to say you cannot use type for the subject but use it everywhere else
… THe spec is what I’m concerned about
… how closely the context provides a programmatic interface to the spec its a JSON-LD question
… if the contxt doesn’t do anything about it, we’re fine, other people can add it

Kyle Den Hartog: 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 JSON-LD aspects

Jonathan Holt: +1 to Kyle

Kyle Den Hartog: if we’re using it to describe DID subject I don’t think that holds

Adrian Gropper: +1 kyle

Drummond Reed: regardless of whether type or other property that could be used to describe DID subject that’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

Dave Longley: “type” is not syntax/representation specific

Daniel Buchner: Before the call ends:

Daniel Buchner: REQUEST FROM EARLIER: can we schedule a special topic call for equivalence properties?

Drummond Reed: 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.

Justin Richer: +1 to drummond

Drummond Reed: @Amy I am going to nominate you for Scribe of the Year. You are amazingly fast and accurate.

Daniel Burnett: manu, want to summarise?

Summary: **pillow screaming** (Daniel Buchner)

Adrian Gropper: +1 Amy as scribe of the year

Manu Sporny: i believe the current proposal from Joe is don’t say anything about type in the top layer of the spec

Joe Andrieu: we can have guidence!
… I’m saying don’t put it in core properties

Orie Steele: Joe said: JoeAndrieu Orie, my proposal is we don’t add type to the core properties.

Jonathan Holt: +1 to drummond, we need to explore the potential implications of our technology

Dave Longley: Joe’s proposal: don’t merge the PR and add some additional privacy guidance text?

Daniel Buchner: No serious methods will even allow it

Manu Sporny: I don’t know how to do that

Joe Andrieu: Just don’t accept this PR it’s very simple

Manu Sporny: it doesn’t align with don’t put it in core properties

Daniel Buchner: I will personally file Issues on their Method repos to wag a finger at them

Joe Andrieu: it’s in the context, not the spec

Manu Sporny: the ADM doesn’t allow this

Orie Steele: I think this is caused by the confusing nature of the ADM

Jonathan Holt: I don’t think it is in the spec, only JSON-LD

Dmitri Zagidulin: +1 orie :)

Daniel Burnett: there’s a clear nonunderstanding right now. You need to talk about that specifically
… thanks everyone!
… Reminder, face to face next week, no standard meeting

Brent Zundel: not seeing type here: https://w3c.github.io/did-core/#core-properties

Drummond Reed: 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.

Orie Steele: clearly its not obvious that aribitrary properties are preserved.

Dave Longley: +1 Orie

Drummond Reed: Joe is opposed to that usage. I am not.

Jonathan Holt: +1 to Orie

Dmitri Zagidulin: also +1 to what brent just said. it’s not in that section

Manu Sporny: “preserve by default” hasn’t fully sunken in yet.

Manu Sporny: or rather, we don’t scope properties in DID Core

Manu Sporny: I mean, we kinda do

Manu Sporny: but type isn’t one of them.