DID WG Telco — Minutes

Date: 2020-10-06

See also the Agenda and the IRC Log

Attendees

Present: Jonathan Holt, Wayne Chang, Adrian Gropper, Dave Longley, Ivan Herman, Justin Richer, Phil Archer, Chris Winczewski, Manu Sporny, Dmitri Zagidulin, Daniel Buchner, Kaliya Young, Joe Andrieu, Brent Zundel, Drummond Reed, Amy Guy, Pamela Dingle, Orie Steele, Eugeniu Rusu, David Ezell, Markus Sabadello, Daniel Hardman

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Justin Richer, Manu Sporny

Content:

Brent Zundel: agenda review. WoT joint meeting, special topic call, point out a comment as part of TAG review, advertise a PR, jump into “type” property discussion
… anticipate the “type” will take the remainder of the meeting, issue check will fill up bulk.

Jonathan Holt: brought up CBOR PR, would love feedback

Brent Zundel: we’ll give 5 min to show off PR’s and get feedback
… introductions — no, we know each other

Brent Zundel: https://github.com/w3c/wot/issues/932

Brent Zundel: next week we’ll be joined by WoT WG
… they’ve created an issue, they want to talk to us about 2 topics
… will occur as part of our regular meeting next week
… next special topic call is Thursday. Continuing Abstract Data Model / Producing Consuming Rules / Unregistered Properties conversation
… last meeting was really productive, lots of “oh that’s what you mean” comments
… hope to come to resolution soon. Be there, Thurs, Noon ET

1. TAG Review comment

Brent Zundel: https://github.com/w3ctag/design-reviews/issues/556#issuecomment-702629028

Brent Zundel: TAG review, we requested a design review, this comment was raised on request for feedback
… highlights importance of privacy & getting privacy/security questionnaire done
… summary: I believe this spec triggers many human rights concerns
… group should be aware this comment represents reaction to our work we should anticipate
… in the future
… we’ve invited the TAG to join us, we expect this to come up again

Drummond Reed: Definitely agree “it anticipates a reaction to our work that we might hear again”

Manu Sporny: I’ll note that a China-like social credit system exists w/o DIDs today.

Manu Sporny: So it is being done today w/o DIDs – agree that we care about that, though and want to show how DIDs can be used in a way that doesn’t immediately lead to a social credit system.

Drummond Reed: Good point, Manu

2. PR 407 (Cleanup key representations)

Brent Zundel: https://github.com/w3c/did-core/pull/407

Brent Zundel: PR 407; PR has some review but not a lot
… we’re gonna merge it
… bring up any concerns in the PR

3. CBOR PR

Orie Steele: https://github.com/w3c/did-core/pull/420

Manu Sporny: https://github.com/w3c/did-spec-registries/pull/138

Jonathan Holt: as requested, a list a 5 items to fix in CBOR to be included as part of spec
… big question was “what flavor of CBOR”. We picked Vanilla.
… transforming/transcoding through different serializations is challenging. Feedback from ACE (in IETF)
… lots of conversation from Jim Schaad, who just passed away over the weekend

Manu Sporny: :((((

Daniel Buchner: Sorry to hear your acquaintance passed away, Jonathan

Jonathan Holt: looking for more feedback from ACE, guidance in CBOR specs
… settled on CDDL for description
… allows for specific guidance of representations in CBOR
… JSON is a subset of CBOR so CDDL works for JSON as well
… some missing items (byte streams), but 80% solution
… need more concrete representations
… to support lossless conversion between JSON and CBOR
… “reach goal” is to leverage CDDL as our abstract data model
… to facilitate transformations between representations

Orie Steele: +1 to CDDL for CBOR.

Jonathan Holt: hoping that CDDL is in running for abstract data model
… hoping this is discussed at special call (th)

Brent Zundel: lots of work, deserves our attention

4. the type property

Brent Zundel: https://github.com/w3c/did-core/pull/410

Brent Zundel: type property; plan is to open the queue; believe we are approaching the possibility of consensus
… but leave it to folks to get on the queue and take us there

Manu Sporny: was there a process violation?

Brent Zundel: suggestion that introduction of “type” property was a process violation, chairs met with individual and walked through the timeline
… meeting minutes weren’t clear how the “type” and “representation” wasn’t clear
… no way to see from minutes that there was a transition; understandable assertion that’s been addressed

Manu Sporny: +1 thanks to the Chairs for having that conversation – that’s my memory of what happened as well.

Adrian Gropper: I’ve been unable to understand why “type” is not doable in other ways
… may not understand enough about linked data architectures, is there an explanation?

Drummond Reed: type is used in linked data as it’s used in RDF; don’t see it as inextricably linked to the data format
… as proposed in the abstract data model, it’s a property of the DID subject
… classic semantic web regardless of representation

Adrian Gropper: then who needs it?

Adrian Gropper: it doesn’t

Adrian Gropper: I just don’t get who needs ‘type’ for what

Orie Steele: agropper some people want to know if did:example:123 is a Book, Person, Inmate, or Car.

Brent Zundel: history and groundwork, issue 199 raised the question “what can a DID identify”
… can we include that as part of the DID document; can the doc identify a schema but also provide the schema?
… turned into “content”, later “representation”, and now “type” describes “what other thing is in the DID Doc”

Drummond Reed: manu: no you first

Manu Sporny: drummond: no you first

Drummond Reed: motivation and objectives for the property: when the DID subject is a logical thing (a schema, a credential, a document), all logical objects should have DIDs
… all artifacts in Indy should uniformly have DIDs and to distinguish between them by logical type

Orie Steele: ION has a similar concept: https://github.com/decentralized-identity/ion/issues/77

Drummond Reed: DID identifies a subject, “type” identifies the type of object; privacy issue when a person

Pamela Dingle: This summary is very helpful - thanks Drummond

Manu Sporny: there are three main approaches we could take, concerned we won’t get consensus on any of them
… could add type as a property; type tells you what the subject is (person, schema, something else)
… could add type as metadata; talking about the DID document, not the subject
… could make DID docs VC’s (but we have strong arguments against that)
… haven’t been able to find any proposal that’ll pass w/o -1’s

Adrian Gropper: if I understand drummond’s explanation: per service endpoints, DID document has to have things that depend on control
… or else they should go elsewhere (keys for example)
… because there’s a privacy risk, do we see “type” as something that’s a control issue?
… once we start seeing “type” will search engines start associating other things?
… and assemble other properties associated with the DID that weren’t included intentionally by the controller, and linked externally

Orie Steele: Can the did controller change the type of a did subject?

Daniel Buchner: Gosh, hopefully, that sounds amazing

Orie Steele: See https://schema.org/Person

Daniel Buchner: like, what if we could have NPM, but without microsoft owning all your ability to access a code registry

Daniel Hardman: have been observing from afar; could someone summarize why we abandoned “content” or “representation”?
… seems that “type” inside of one of these would trivially solve these issues

Pamela Dingle: crawlers gonna crawl
… there’s going to be enough intelligence to label things after the fact anyway
… what’s the cardinality of “type”? is there an assumption that a doc can have only one type?

Drummond Reed: proposal is array

Pamela Dingle: thanks

Phil Archer: crawlers will work out what the did identifies whether you tell them or not

Daniel Buchner: I mean…just…err…don’t tell them if you don’t want to

Phil Archer: one representation is JSONLD which is based on the open world assumption, anybody can say anything about anyone
… just because we dont’ say “put the type in here” doesn’t mean you can’t
… the idea that we can stop people putting data in there is not grounded in reality

Orie Steele: +1 to what Phil is saying…

Manu Sporny: +1 to phila
… privacy problem exists no matter where we put this
… question for JoeAndrieu, surprised to see you’re ok with it in metadata but not document
… could you explain the difference?

Joe Andrieu: distinction between the metadata vs. the document raises the concern
… initial issue was “how do we embed extra information about the subject in the document”; introduction of “type” was about the document, not about the subject
… in writing it up, it became about the subject
… statements in the metadata are about the subject of the document
… it has to be about the document and not about the subject

Drummond Reed: if we don’t have “type” and talk about these considerations in the spec, it’s just going to go on the registry (as an extension) and we won’t be able tot alk about it
… if the “DID subject” is a logical thing (information resource, schema, document, etc) – there aren’t privacy issues; type of that thing is in the document
… if what you’re describing isn’t logical (org, person, “not on the internet”), that’s different
… type describes the DID subject no matter where it goes
… I don’t think we solve privacy problems by restricting this; it’s going to happen
… advocating that we make it very clear what the guidelines are when the DID identifies a person
… removing type feels like taking away massive functionality that we have uses for that will happen anyway

Orie Steele: I personally don’t think the RDF concept of “type” is a problem.

Orie Steele: people will just use services or public key identifiers if we don’t allow them type…. it will lead to more fingerprinting not less.

Orie Steele: type could also be set by the did method, such as in the case of a registry of inmates.

Jonathan Holt: i’m on the fence, mostly the challenge is that it’s an attempt at a logical restraint with no enforcement
… did author can change type over time

Daniel Buchner: “Digital identifier systems are scary, because could be used to identify things”, they said, as they tweeted and emailed from their centralized IDs linked to pictures of their faces and personal bios

Jonathan Holt: great power becomes great responsibility

Jonathan Holt: “One of the side effects of modern technology has been to place in the hands of those who control the machinery of government a range of coercive apparatus undreamed of by any ancient despotism.” Pallis, M. 1985. “Foreword.” In Chogyam Trungpa, Born in Tibet, 7–14. Boston and London: Shambhala.

Manu Sporny: I don’t understand what moving the type out of the document will do to solve privacy

Daniel Buchner: Because Manu, Google making one more HTTP request is impossible for any non-god entity to do

Manu Sporny: use case comes with did subject being the schema; using metadata doesn’t solve the use case or address privacy concerns
… don’t understand it’s different, open world lets you say anything, registry lets you extend

Orie Steele: +1 to defining type as a property of did subjects, and warning about the danger

Manu Sporny: if we really want to see how dangerous these properties are, we need to say it in the core spec because we’ll be more careful than others may be

Daniel Burnett: manu, what about the cut and paste cult that doesn’t read specs?

Adrian Gropper: from control perspective; as a subject might also have an agent (semi-autonomous); would subject and agent have a separate DID, would we use “type” to differentiate person from agent?

Orie Steele: agropper in an open world model, type can be anything, so anything is possible.

Daniel Buchner: on alternatives: we spent a lot of time on economic game theory; will probably be a power-law thing over time here
… eg decentralized NPM, you’d need enough people involved there to get it to work, that’s hard to scale
… if I can scan to get something like 5% are “code modules” that’s a huge win
… you don’t have to include “type”

Drummond Reed: +1 to Manu’s proposal

Daniel Buchner: there are ways to preserve privacy without losing the functionality

Joe Andrieu: i’m amazed that people are using open world to talk about privacy violations
… it’s great we can make statements about the subject; we should not enshrine saying things about the core subject; they can go somewhere else

Daniel Buchner: hmm

Joe Andrieu: there are lots of offensive terms we can go in the document but we aren’t

Daniel Buchner: Manu: go even stronger to prohibit normatively compatible use of human types

Daniel Buchner: code modules, public IOT devices, machines, devices, etc.

Drummond Reed: suggestion: there’s a win when it’s not a person, DIDs were never “just for people”, they were for everything
… this is the wrong place to legislate privacy

Orie Steele: +1 to not doing legal interpretation as spec text.

Drummond Reed: if we need to let’s have a special topic call
… i undersand the concerns but is this the right way to deal with this for identifiers that can be used for anything

Joe Andrieu: no one is saying you can’t have “type” just that it doesn’t belong in the DID Document

Joe Andrieu: as a Core Property, I mean

Drummond Reed: Joe, that runs contrary to all of the use cases we have for using ‘type’ for logical things

Justin Richer: Just wanted to bring up a point and counter-point for consideration on core spec.
… Other specifications, where we have explicitly taken potentially problematic items like this into the core specification so we can discuss issues with then, in some use cases, engineers read the definition, examples and implement it and not read any of the text that says why it’s a bad idea.
… I get the argument for wanting to have the discussion here - and that’s a valid argument - but I’m less convinced that it’s a practical argument due to the implementation platform – an engineer wanting to do something else.

Manu Sporny: going to attempt some proposals
… talk about how dangerous it is to talk about type of did subject (for people)
… nothing to implement here
… 2, must not expose type information that exposes did subject as a person

Justin Richer: this is testable, we can scan for some things

Daniel Buchner: Not just information resources

Justin Richer: 3, you may expose information for non-person entities

Daniel Buchner: non-human entities

Joe Andrieu: +1 to Orie. It’s not testable

Manu Sporny: none of these propose that we define “type”, just a framework w/in which to operate

Daniel Buchner: If you have a type table, it’s testable to not include a person type

Joe Andrieu: open world means there isn’t a type table

Dave Longley: if this is not going to be tied to an implementation, shouldn’t just be “type” but “any property that isn’t about using the DID”

Brent Zundel: +1 to dlongley’s alteration

Joe Andrieu: +1 to Dave’s adjustment

Daniel Hardman: -1 to Dave’s reworking

Adrian Gropper: +1 to Dave’s adjustment

Daniel Hardman: I don’t think there’s any danger unless the did subject is a person
… I don’t want to lose that the danger is tied to the DID being a person

Drummond Reed: if it’s not a person, that’s ok

Dave Longley: I did some rewording here

Orie Steele: its dangerous for machines as well

Daniel Hardman: +1 to the version Dave just read

Orie Steele: knowing what something is, is the first step to taking it apart

Drummond Reed: +1 to that version

Proposed resolution: Document how dangerous specifying properties such as the “type” of a DID subject, that are not related to expressing cryptographic material/verification methods related to using the DID, in a VDR can be for entities such as people. (Manu Sporny)

Manu Sporny: +1

Dave Longley: +1

Drummond Reed: +1

Orie Steele: +1

Joe Andrieu: +1

Daniel Buchner: ***The year is 2144 - the robots argue they are people, and are angry about being in DID type fields LOL

Daniel Hardman: +1

Brent Zundel: +1

Ivan Herman: +1

Justin Richer: +0

Adrian Gropper: +1

Daniel Buchner: +1

Amy Guy: +1

Markus Sabadello: +1

Jonathan Holt: 0

Pamela Dingle: +1

Resolution #1: Document how dangerous specifying properties such as the “type” of a DID subject, that are not related to expressing cryptographic material/verification methods related to using the DID, in a VDR can be for entities such as people.

Phil Archer: +1

Jonathan Holt: what are we trying to solve in the did document that we can’t solve in verifiable credentials? isn’t this an assertion?
… assertion could be counter-verified

Brent Zundel: problem is outlined in 199
… boils down to: “if a schema is identified by a DID, when I resolve that DID I want to get that schema”

Orie Steele: …. I think its more accurately described as “should did subjects be capable of having RDF types”

Daniel Buchner: Part of the utility is reducing the resource consumption required to do a full fetch against all DID personal datastores for info they may want to offer in relation to type

Joe Andrieu: agreed, @rhiaro

Manu Sporny: we need a special topic call

Daniel Buchner: If I can get a hint that 99% of DIDs are not Node packages, I can skip billions of HTTP requests

Joe Andrieu: that proposal isn’t about the registry

Manu Sporny: can we get something to let us reject things from getting into the spec/registry

Daniel Hardman: +1 to the sentiment, but I want to talk about testability

Brent Zundel: thank you for a fruitful discussion, special topic call would be good
… we’ve got a lot of issues

Drummond Reed: Thank you Justin!

Justin Richer: come to the special topic call!

5. Resolutions