14:29:11 <RRSAgent> RRSAgent has joined #did
14:29:11 <RRSAgent> logging to https://www.w3.org/2020/10/06-did-irc
14:29:14 <Zakim> RRSAgent, make logs Public
14:29:15 <Zakim> please title this meeting ("meeting: ..."), ivan
14:29:27 <ivan> Meeting: DID WG Telco
14:53:38 <burn> burn has joined #did
15:00:10 <jonathan_holt> jonathan_holt has joined #did
15:00:36 <justin_r> justin_r has joined #did
15:00:40 <jonathan_holt> present+ jonathan_holt
15:00:51 <agropper> agropper has joined #did
15:00:51 <wayne> present+
15:01:19 <Eugeniu_Rusu> Eugeniu_Rusu has joined #did
15:01:27 <agropper> present+
15:01:40 <dlongley> present+
15:01:43 <ivan> present+
15:01:44 <justin_r> present+
15:01:44 <phila> phila has joined #did
15:01:54 <dbuc> dbuc has joined #did
15:02:00 <ivan> present+ dlongley
15:02:08 <phila> present
15:02:14 <phila> present+
15:02:27 <ivan> present+ phila
15:03:26 <ivan> present+ chriswinc
15:03:52 <ivan> present+ manu
15:03:58 <ivan> present+ dmitriz
15:04:27 <ivan> present+ dbuc
15:04:36 <JoeAndrieu> JoeAndrieu has joined #did
15:04:52 <ivan> Agenda: https://www.w3.org/mid/00000000000090c1da05b101e7bb@google.com
15:05:40 <ivan> present+ identitywoman
15:05:45 <dbuc> present+
15:05:52 <JoeAndrieu> present+
15:06:00 <justin_r> scribe+
15:06:05 <brent> brent has joined #did
15:06:08 <chriswinc> chriswinc has joined #did
15:06:12 <brent> present+
15:06:12 <manu> present+
15:06:15 <drummond> drummond has joined #did
15:06:18 <chriswinc> present+
15:06:21 <drummond> present+
15:06:29 <ivan> chair: brent
15:06:47 <justin_r> brent: 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
15:07:02 <jonathan_holt> q+
15:07:03 <justin_r> ... anticipate the "type" will take the bulk of the meeting, issue check will fill up bulk.
15:07:08 <brent> ack jonathan_holt
15:07:13 <ivan> present+ rhiaro
15:07:14 <justin_r> s/up bulk/up remainder/
15:07:21 <ivan> present+ pam
15:07:28 <justin_r> jonathan_holt: brought up CBOR PR, would love feedback
15:07:41 <ivan> present+ drummond
15:07:41 <justin_r> brent: we'll give 5 min to show off PR's and get feedback
15:08:09 <justin_r> brent: introductions --- no, we know each other
15:08:16 <Orie> Orie has joined #did
15:08:20 <Orie> present+
15:08:23 <brent> https://github.com/w3c/wot/issues/932
15:08:24 <justin_r> brent: next week we'll be joined by WoT WG
15:08:43 <justin_r> ... they've created an issue, they want to talk to us about 2 topics
15:08:48 <Eugeniu_Rusu> present+
15:08:51 <justin_r> ... will occur as part of our regular meeting next week
15:09:11 <justin_r> brent: next special topic call is Thursday. Continuing Abstract Data Model / Producing Consuming Rules / Unregistered Properties conversation
15:09:20 <justin_r> ... last meeting was really productive, lots of "oh that's what you mean" comments
15:09:30 <justin_r> ... hope to come to resolution soon. Be there, Thurs, Noon ET
15:09:41 <brent> https://github.com/w3ctag/design-reviews/issues/556#issuecomment-702629028
15:09:48 <ivan> Topic: TAG Review
15:10:03 <justin_r> brent: TAG review, we requested a design review, this comment was raised on request for feedback
15:10:23 <justin_r> ... highlights importance of privacy & getting privacy/security questionnaire done
15:10:42 <justin_r> ... summary: I believe this spec triggers many human rights concerns
15:11:05 <justin_r> ... group should be aware this comment represents reaction to our work we should anticipate
15:11:11 <justin_r> ... in the future
15:11:14 <pam> pam has joined #did
15:11:20 <pam> present +
15:11:21 <drummond> Definitely agree "it anticipates a reaction to our work that we might hear again"
15:11:28 <justin_r> ... we've invited the TAG to join us, we expect this to come up again
15:11:31 <manu> I'll note that a China-like social credit system exists w/o DIDs today.
15:11:42 <drummond> Good point, Manu
15:11:46 <brent> https://github.com/w3c/did-core/pull/407
15:11:53 <ivan> Topic: PR 407
15:11:55 <justin_r> brent: PR 407; PR has some review but not a lot
15:12:05 <manu> 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.
15:12:09 <justin_r> ... we're gonna merge it
15:12:13 <dezell> dezell has joined #did
15:12:17 <dezell> present+
15:12:22 <justin_r> ... bring up any concerns in the PR
15:12:30 <ivan> Topic: CBOR PR
15:12:51 <justin_r> jonathan_holt: as requested, a list a 5 items to fix in CBOR to be included as part of spec
15:12:52 <Orie> https://github.com/w3c/did-core/pull/420
15:13:03 <manu> https://github.com/w3c/did-spec-registries/pull/138
15:13:07 <justin_r> ... big question was "what flavor of CBOR". We picked Vanilla.
15:13:26 <justin_r> ... transforming/transcoding through different serializations is challenging. Feedback from ACE (in IETF)
15:13:47 <justin_r> ... lots of conversation from Jim Schaad, who just passed away over the weekend
15:13:53 <ivan> present+ markus
15:13:55 <manu> :((((
15:14:05 <markus_sabadello> markus_sabadello has joined #did
15:14:08 <markus_sabadello> present+
15:14:19 <justin_r> ... looking for more feedback from ACE, guidance in CBOR specs
15:14:26 <dbuc> Sorry to hear your acquaintance passed away, Jonathan
15:14:46 <justin_r> ... settled on CDDL for description
15:15:03 <justin_r> ... allows for specific guidance of representations in CBOR
15:15:32 <justin_r> ... JSON is a subset of CBOR so CDDL works for JSON as well
15:15:50 <justin_r> ... some missing items (byte streams), but 80% solution
15:16:00 <justin_r> ... need more concrete representations
15:16:10 <justin_r> ... to support lossless conversion between JSON and CBOR
15:16:26 <justin_r> ... "reach goal" is to leverage CDDL as our abstract data model
15:16:35 <justin_r> ... to facilitate transformations between representations
15:16:57 <justin_r> q+
15:17:16 <Orie> +1 to CDDL for CBOR.
15:17:21 <manu> scribe+
15:17:37 <justin_r> q-
15:17:46 <justin_r> ... hoping that CDDL is in running for abstract data model
15:17:49 <agropper_> agropper_ has joined #did
15:18:06 <justin_r> ... hoping this is discussed at special call (th)
15:18:11 <jonathan_holt> q+
15:18:13 <justin_r> brent: lots of work, deserves our attention
15:18:24 <jonathan_holt> q-
15:18:27 <ivan> Topic: the type property
15:18:32 <brent> https://github.com/w3c/did-core/pull/410
15:19:06 <manu> q+ to ask if we have a determination on the process issue?
15:19:08 <justin_r> brent: type property; plan is to open the queue; believe we are approaching the possibility of consensus
15:19:19 <justin_r> ... but leave it to folks to get on the queue and take us there
15:19:36 <justin_r> manu: process violation?
15:19:37 <manu> q-
15:20:02 <justin_r> brent: suggestion that introduction of "type" property was a process violation, chairs met with individual and walked through the timeline
15:20:24 <justin_r> ... meeting minutes weren't clear how the "type" and "representation" wasn't clear
15:20:25 <agropper_> q+
15:20:46 <justin_r> ... no way to see from minutes that there was a transition; understandable assertion that's been addressed
15:20:50 <manu> +1 thanks to the Chairs for having that conversation -- that's my memory of what happened as well.
15:21:07 <brent> ack agropper_
15:21:20 <justin_r> agropper_: I've been unable to understand why "type" is not doable in other ways
15:21:41 <drummond> q+
15:21:41 <justin_r> ... may not understand enough about linked data architectures, is there an explanation?
15:21:53 <brent> ack drummond
15:22:24 <justin_r> drummond: type is used in linked data as it's used in RDF; don't see it as inextricably linked to the data format
15:22:35 <agropper_> then who needs it?
15:22:40 <justin_r> ... as proposed in the abstract data model, it's a property of the DID subject
15:22:58 <justin_r> ... classic semantic web regardless of representation
15:22:58 <agropper_> it doesn't
15:22:59 <ivan> present+ danielhardman
15:23:07 <brent> q+ to describe issue 199
15:23:22 <brent> ack brent
15:23:22 <Zakim> brent, you wanted to describe issue 199
15:23:38 <justin_r> brent: history and groundwork, issue 199 raised the question "what can a DID identify"
15:23:54 <manu> q+ to describe the current options that seem to be on the table.
15:23:55 <agropper_> I just don't get who needs 'type' for what
15:24:09 <justin_r> ... can we include that as part of the DID document; can the doc identify a schema but also provide the schema?
15:24:29 <drummond> q+ to summarize the issues if that's helpful
15:24:29 <Orie> agropper some people want to know if did:example:123 is a Book, Person, Inmate, or Car.
15:24:30 <justin_r> ... turned into "content", later "representation", and now "type" describes "what other thing is in the DID Doc"
15:24:36 <manu> q- later
15:24:44 <brent> ack drummond
15:24:46 <Zakim> drummond, you wanted to summarize the issues if that's helpful
15:25:06 <justin_r> drummond: manu: no you first
15:25:08 <Daniel_Hardman> Daniel_Hardman has joined #did
15:25:19 <justin_r> manu: drummond: no you first
15:26:00 <pam> This summary is very helpful - thanks Drummond
15:26:18 <justin_r> drummond: 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
15:26:46 <justin_r> ... all artifacts in Indy should uniformly have DIDs and to distinguish between them by logical type
15:26:51 <Orie> ION has a similar concept: https://github.com/decentralized-identity/ion/issues/77
15:27:14 <brent> q?
15:27:23 <brent> ack manu
15:27:23 <Zakim> manu, you wanted to describe the current options that seem to be on the table.
15:27:27 <agropper_> q+
15:27:27 <justin_r> ... DID identifies a subject, "type" identifies the type of object; privacy issue when a person
15:27:46 <justin_r> manu: there are three main approaches we could take, concerned we won't get consensus on any of them
15:28:09 <Daniel_Hardman> q+
15:28:17 <justin_r> ... could add type as a property; type tells you what the subject is (person, schema, something else)
15:28:42 <justin_r> ... could add type as metadata; talking about the DID document, not the subject
15:28:59 <justin_r> ... could make DID docs VC's (but we have strong arguments against that)
15:29:09 <justin_r> ... haven't been able to find any proposal that'll pass w/o -1's
15:29:14 <wayne> q+
15:29:18 <brent> ack agropper_
15:29:34 <pam> q+
15:29:48 <justin_r> agropper_: if I understand drummond's explanation: per service endpoints, DID document has to have things that depend on control
15:30:01 <justin_r> ... or else they should go elsewhere (keys for example)
15:30:16 <justin_r> ... because there's a privacy risk, do we see "type" as something that's a control issue?
15:30:22 <phila> q+
15:30:28 <Orie> Can the did controller change the type of a did subject?
15:30:35 <justin_r> ... once we start seeing "type" will search engines start associating other things?
15:30:35 <manu> q+ to assert that type for metadata has the same privacy issues as type associated w/ did subject.
15:30:44 <dbuc> Gosh, hopefully, that sounds amazing
15:30:55 <Orie> See https://schema.org/Person
15:30:56 <JoeAndrieu> q+ to outline how type's subject shifted from #199 to #410
15:30:57 <justin_r> ... and assemble other properties associated with the DID that weren't included intentionally by the controller, and linked externally
15:30:57 <manu> q+ to ask Joe why he believes the privacy implications are different.
15:31:01 <brent> ack Daniel_Hardman
15:31:12 <dbuc> like, what if we could have NPM, but without microsoft owning all your ability to access a code registry
15:31:16 <wayne> q-
15:31:27 <justin_r> Daniel_Hardman: have been observing from afar; could someone summarize why we abandoned "content" or "representation"?
15:31:40 <justin_r> ... seems that "type" inside of one of these would trivially solve these issues
15:31:55 <brent> ack pam
15:32:13 <justin_r> pam: cralwers gonna crawl
15:32:34 <justin_r> ... there's goign to be enough intelligence to label things after the fact anyway
15:32:38 <identitywoman_> identitywoman_ has joined #did
15:32:46 <drummond> q+ to answer Daniel's question about why we moved from the 'representation' property to the 'type' property
15:32:49 <ivan> s/goign/going/
15:32:49 <identitywoman_> present+
15:32:51 <justin_r> ... what's the cardinality of "type"? is there an assumption that a doc can have only one type?
15:32:56 <justin_r> drummond: proposal is array
15:32:59 <justin_r> pam: thanks
15:33:01 <brent> ack phila
15:33:23 <justin_r> phila: crawlers will work out what the did identifies whether you tell them or not
15:33:36 <identitywoman_> Sorry about not being on mute at the beginning (I was talking to folks at Harvard about a presentation I'm giving to a graduate seminar next week)
15:33:40 <dbuc> I mean...just...err...don't tell them if you don't want to
15:33:43 <justin_r> ... one representation is JSONLD which is based on the open world assumption, anybody can say anything about anyone
15:33:51 <justin_r> ... just because we dont' say "put the type in here" doesn't mean you can't
15:34:04 <dbuc> q+
15:34:14 <justin_r> ... the idea that we can stop people putting data in there is not grounded in reality
15:34:18 <brent> ack manu
15:34:18 <Zakim> manu, you wanted to assert that type for metadata has the same privacy issues as type associated w/ did subject. and to ask Joe why he believes the privacy implications are
15:34:21 <Zakim> ... different.
15:34:22 <Orie> +1 to what Phil is saying...
15:34:25 <justin_r> manu: +1 to phila
15:34:37 <justin_r> ... privacy problem exists no matter where we put this
15:34:37 <dbuc> q-
15:34:50 <jonathan_holt> q+
15:35:25 <justin_r> ... question for JoeAndrieu, surprised to see you're ok with it in metadata but not document
15:35:31 <justin_r> ... could you explain the difference?
15:35:38 <brent> ack JoeAndrieu
15:35:38 <Zakim> JoeAndrieu, you wanted to outline how type's subject shifted from #199 to #410
15:35:55 <justin_r> JoeAndrieu: distinction between the metadata vs. the document raises the concern
15:36:19 <justin_r> ... 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
15:36:30 <justin_r> ... in writing it up, it became about the subject
15:36:35 <Orie> I personally don't think the RDF concept of "type" is a problem.
15:36:39 <justin_r> ... statements in the metadata are about the subject of the document
15:36:46 <manu> q+ to note that it *is* about the subject of the document?
15:36:55 <justin_r> ... it has to be about the document and not about the subject
15:37:14 <brent> ack drummond
15:37:15 <Zakim> drummond, you wanted to answer Daniel's question about why we moved from the 'representation' property to the 'type' property
15:37:41 <justin_r> drummond: 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
15:38:26 <justin_r> ... 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
15:38:33 <agropper_> q+
15:38:53 <justin_r> ... if what you're describing isn't logical (org, person, "not on the internet"), that's different
15:39:00 <dbuc> q+
15:39:03 <justin_r> ... type describes the DID subject no matter where it goes
15:39:45 <justin_r> ... I don't think we solve privacy problems by restricting this; it's going to happen
15:39:57 <brent> q?
15:39:59 <JoeAndrieu> q+ to talk about why the open world data model is exactly why we don't need "type" in the DID Document and that type in the meta-document is the better solution to the issue raised in #199
15:39:59 <justin_r> ... advocating that we make it very clear what the guidelines are when the DID identifies a person
15:40:17 <Orie> people will just use services or public key identifiers if we don't allow them type.... it will lead to more fingerprinting not less.
15:40:27 <brent> ack jonathan_holt
15:40:28 <justin_r> ... removing type feels like taking away massive functionality that we have uses for that will happen anyway
15:40:52 <justin_r> jonathan_holt: i'm on the fence, mostly the challen is that it's an attempt at a logical restraint with no enforcement
15:40:58 <justin_r> ... did author can change type over time
15:41:03 <dbuc> "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
15:41:16 <Orie> type could also be set by the did method, such as in the case of a registry of inmates.
15:41:37 <drummond> LOL Justin
15:41:44 <justin_r> ... great power becomes great responsibility
15:41:50 <brent> ack manu
15:41:50 <Zakim> manu, you wanted to note that it *is* about the subject of the document?
15:42:15 <justin_r> manu: I don't understand what moving the type out of the document will do to solve privacy
15:42:20 <dbuc> Because Manu, Google making one more HTTP request is impossible for any non-god entity to do
15:42:40 <justin_r> ... use case comes with did subject being the schema; using metadata doesn't solve the use case or address privacy concerns
15:42:47 <drummond> q+ to talk about the myriad use cases for a DID identifying a logical thing
15:42:58 <justin_r> ... don't understand it's different, open world lets you say anything, registry lets you extend
15:43:24 <Orie> +1 to defining `type` as a property of did subjects, and warning about the danger
15:43:25 <justin_r> ... 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
15:43:32 <burn> manu, what about the cut and paste cult that doesn't read specs?
15:43:36 <justin_r> q+ to talk about internal discussion vs. extensions
15:43:36 <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.
15:43:43 <brent> ack agropper_
15:44:19 <justin_r> agropper_: 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?
15:44:28 <brent> ack dbuc
15:44:42 <Orie> agropper in an open world model, type can be anything, so anything is possible.
15:45:08 <justin_r> dbuc: on alternatives: we spent a lot of time on economic game theory; will probably be a power-law thing over time here
15:45:09 <manu> q+ to try some proposals.
15:45:51 <justin_r> ... eg decentrialized MPM, you'd need enough people involved there to get it to work, that's hard to scale
15:46:01 <brent> q+ to throw another proposal in the mix.
15:46:16 <justin_r> ... if I can scan to get something like 5% are "code modules" that's a huge win
15:46:26 <justin_r> ... you don't have to include "type"
15:46:30 <brent> ack JoeAndrieu
15:46:30 <Zakim> JoeAndrieu, you wanted to talk about why the open world data model is exactly why we don't need "type" in the DID Document and that type in the meta-document is the better solution
15:46:32 <drummond> +1 to Manu's proposal
15:46:33 <Zakim> ... to the issue raised in #199
15:46:38 <justin_r> ... there are ways to preserve privacy without losing the functionality
15:47:00 <justin_r> JoeAndrieu: i'm amazed that people are using open world to talk about privacy violations
15:47:19 <dbuc> Manu: go even stronger to prohibit normatively compatible use of human types
15:47:29 <justin_r> ... 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
15:47:42 <dbuc> hmm
15:47:50 <justin_r> ... there are lots of offensive terms we can go in the document but we aren't
15:47:50 <brent> ack drummond
15:47:50 <Zakim> drummond, you wanted to talk about the myriad use cases for a DID identifying a logical thing
15:48:26 <dbuc> code modules, public IOT devices, machines, devices, etc.
15:48:27 <justin_r> drummond: suggestion: there's a win when it's not a person, DIDs were never "just for people", they were for everything
15:48:45 <justin_r> ... this is the wrong place to legislate privacy
15:48:57 <Orie> +1 to not doing legal interpretation as spec text.
15:48:59 <justin_r> ... if we need to let's have a special topic call
15:49:28 <jonathan_holt> q+
15:49:30 <brent> ack justin_r
15:49:30 <Zakim> justin_r, you wanted to talk about internal discussion vs. extensions
15:49:32 <JoeAndrieu> no one is saying you can't have "type" just that it doesn't belong in the DID Document
15:49:32 <justin_r> ... i undersand the concerns but is this the right way to deal with this for identifiers that can be used for anything
15:49:46 <JoeAndrieu> as a Core Property, I mean
15:49:51 <manu> justin_r: Just wanted to bring up a point and counter-point for consideration on core spec.
15:50:22 <drummond> Joe, that runs contrary to all of the use cases we have for using 'type' for logical things
15:50:30 <manu> justin_r: Other specificcations, 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.
15:50:57 <manu> justin_r: 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.
15:51:04 <brent> ack manu
15:51:04 <Zakim> manu, you wanted to try some proposals.
15:51:14 <justin_r> manu: going to attempt some proposals
15:51:32 <justin_r> ... talk about how dangerous it is to talk about type of did subject (for people)
15:51:49 <justin_r> ... nothing to implement here
15:52:01 <justin_r> ... 2, must not expose type information that exposes did subject as a person
15:52:04 <ivan> q?
15:52:13 <justin_r> this is testable, we can scan for some things
15:52:24 <dbuc> Not just information resources
15:52:28 <justin_r> 3, you may expose information for non-person entities
15:52:31 <dbuc> non-human entities
15:52:36 <JoeAndrieu> +1 to Orie. It's not testable
15:52:47 <justin_r> ... none of these propose that we define "type", just a framework w/in which to operate
15:52:51 <dlongley> q+
15:52:58 <dbuc> If you have a type table, it's testable to not include a person type
15:53:05 <brent> ack dlongley
15:53:17 <JoeAndrieu> open world means there isn't a type table
15:53:27 <justin_r> dlongley: 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"
15:53:38 <brent> +1 to dlongley's alteration
15:53:43 <JoeAndrieu> +1 to Dave's adjustment
15:54:12 <Daniel_Hardman> -1 to Dave's reworking
15:54:13 <Daniel_Hardman> q+
15:54:25 <agropper_> +1 to Dave's adjustment
15:54:32 <brent> ack Daniel_Hardman
15:54:42 <justin_r> Daniel_Hardman: I don't think there's any danger unless the did subject is a person
15:54:57 <justin_r> ... I don't want to lose that the danger is tied to the DID being a person
15:55:18 <justin_r> drummond: if it's not a person, that's ok
15:55:27 <justin_r> dlongley: I did some rewording here
15:55:28 <Orie> its dangerous for machines as well
15:55:34 <Daniel_Hardman> +1 to the version Dave just read
15:55:46 <Orie> knowing what something is, is the first step to taking it apart
15:55:48 <drummond> +1 to that version
15:55:51 <manu> PROPOSAL: 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.
15:55:53 <manu> +1
15:55:54 <dlongley> +1
15:55:55 <drummond> +1
15:55:56 <Orie> +1
15:55:57 <JoeAndrieu> +1
15:55:57 <dbuc> ***The year is 2144 - the robots argue they are people, and are angry about being in DID type fields  LOL
15:55:58 <Daniel_Hardman> +1
15:56:00 <brent> +1
15:56:01 <ivan> +1
15:56:01 <justin_r> +0
15:56:03 <agropper_> +1
15:56:06 <dbuc> +1
15:56:07 <rhiaro> +1
15:56:10 <markus_sabadello> +1
15:56:15 <jonathan_holt> 0
15:56:28 <pam> +1
15:56:29 <brent> RESOLVED: 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.
15:56:31 <phila> +1
15:56:39 <manu> q+
15:56:46 <manu> q+ to run next proposal.
15:56:49 <brent> q- later
15:57:07 <justin_r> 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?
15:57:11 <manu> q+ to note we need a special topic call for this.
15:57:14 <justin_r> ... assertion could be counter-verified
15:57:26 <justin_r> brent: problem is outlined in 199
15:57:45 <justin_r> ... boils down to: "if a schema is identified by a DID, when I resolve that DID I want to get that schema"
15:57:51 <dbuc> 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
15:58:00 <Orie> .... I think its more accuratly desriped as "should did subjects be capable of having RDF types"
15:58:02 <brent> q?
15:58:05 <JoeAndrieu> agreed, @rhiaro
15:58:06 <brent> ack jonathan_holt
15:58:09 <justin_r> manu: we need a special topic call
15:58:10 <brent> ack manu
15:58:10 <Zakim> manu, you wanted to run next proposal. and to note we need a special topic call for this.
15:58:15 <dbuc> If I can get a hint that 99% of DIDs are not Node packages, I can skip billions of HTTP requests
15:58:26 <brent> q-
15:58:35 <ivan> q+
15:58:44 <JoeAndrieu> that proposal isn't about the registry
15:58:46 <JoeAndrieu> -j
15:58:55 <brent> ack ivan
15:58:56 <justin_r> manu: can we get something to let us reject things from getting into the spec/registry
15:59:01 <Daniel_Hardman> +1 to the sentiment, but I want to talk about testability
15:59:38 <justin_r> brent: thank you for a fruitful discussion, special topic call would be good
15:59:50 <justin_r> brent: we've got a lot of issues
15:59:51 <drummond> Thank you Justin!
16:00:06 <justin_r> come to the special topic call!
16:00:32 <ivan> zakim, end meeting
16:00:32 <Zakim> As of this point the attendees have been jonathan_holt, wayne, agropper, dlongley, ivan, justin_r, phila, chriswinc, manu, dmitriz, dbuc, identitywoman, JoeAndrieu, brent,
16:00:35 <Zakim> ... drummond, rhiaro, pam, Orie, Eugeniu_Rusu, dezell, markus, markus_sabadello, danielhardman, identitywoman_
16:00:35 <Zakim> RRSAgent, please draft minutes
16:00:35 <RRSAgent> I have made the request to generate https://www.w3.org/2020/10/06-did-minutes.html Zakim
16:00:37 <Zakim> I am happy to have been of service, ivan; please remember to excuse RRSAgent.  Goodbye
16:00:41 <Zakim> Zakim has left #did
16:17:31 <ivan> rrsagent, bye
16:17:31 <RRSAgent> I see no action items