21:59:10 <RRSAgent> RRSAgent has joined #did
21:59:10 <RRSAgent> logging to https://www.w3.org/2020/08/25-did-irc
21:59:21 <Zakim> Zakim has joined #did
21:59:24 <justin_r> justin_r has joined #did
21:59:25 <burn> rrsagent, draft minutes
21:59:25 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/25-did-minutes.html burn
22:00:12 <jonathan_holt> jonathan_holt has joined #did
22:00:26 <burn> present+
22:00:33 <markus_sabadello> markus_sabadello has joined #did
22:01:01 <brent> present+
22:01:06 <wayne> present+
22:02:40 <Orie> Orie has joined #did
22:03:03 <Orie> present+
22:03:29 <dlongley> present+
22:03:49 <manu> present+
22:03:51 <drummond> drummond has joined #did
22:03:58 <drummond> present+
22:04:08 <markus_sabadello> present+
22:04:12 <manu> rrsagent, make logs public
22:04:17 <manu> rrsagent, make minutes
22:04:17 <RRSAgent> I have made the request to generate https://www.w3.org/2020/08/25-did-minutes.html manu
22:04:27 <dmitriz> present+
22:04:39 <drummond> scribe+
22:04:43 <agropper> agropper has joined #did
22:05:03 <drummond> brent: skipping intros for today
22:05:05 <agropper> present+
22:05:21 <drummond> ...next topic call - noon Eastern Time on Thursday - will cover service endpoints
22:05:57 <rhiaro> present+
22:06:36 <drummond> ...based on sparsely-responded to poll, based on dates around TPAC, dates for virtual F2F Nov 2, 3, 4, 5, each day 3.5 hours including a half hour break
22:06:45 <drummond> ...goal is to get to CR
22:07:05 <drummond> ...anyone who has issues with those dates, please tell the chairs
22:07:27 <drummond> topic: DID spec review
22:07:57 <drummond> brent: we want the spec to be reviewed by external groups - CCG, DIF, other groups
22:08:00 <brent> q?
22:08:12 <manu> Meeting: DID WG Meeting (America-Asia)
22:08:22 <drummond> topic: Link Relations
22:08:39 <identitywoman> identitywoman has joined #did
22:08:40 <drummond> brent: Drummond will present a few diagrams and properties
22:08:47 <manu> scribe+
22:08:53 <kdenhartog> kdenhartog has joined #did
22:08:56 <kdenhartog> present+
22:09:13 <manu> scribe+ dbuc
22:09:15 <manu> scribe-
22:09:39 <dbuc> dbuc has joined #did
22:09:43 <dbuc> present+
22:10:03 <jonathan_holt> present+ jonathan_holt
22:10:47 <dbuc> Drummond presenting about appendices
22:11:04 <dbuc> What does a DID identify? - the first one
22:11:40 <dbuc> Sidestepping question of what is an information resource, and what isn't
22:12:12 <dbuc> 3 possible answers: DID subject as a resource, DID Document as a resource, or both
22:13:14 <dbuc> DID identifies DID Subject and resolves the DID Document (diagram of Controller pointing to DID Document and the DID Subject)
22:13:14 <manu> +1 to this diagram
22:13:14 <kdenhartog> q+
22:13:16 <manu> I like it
22:13:22 <manu> q+ to praise the diagram.
22:13:23 <wayne> q+
22:13:24 <Orie> +1 to this diagram
22:13:33 <jonathan_holt> q+
22:13:33 <brent> ack kdenhartog
22:13:59 <dlongley> that's just a different resolver
22:14:04 <Orie> q+  to kill the forking debate
22:14:06 <burn> The method needs to define what happens
22:14:08 <dbuc> People asking what is identified if there is a fork
22:14:14 <dbuc> q+
22:14:21 <dlongley> "what if resolver A returns X and resolver B returns Y" <-- pick your favorite resolver, that's what.
22:14:35 <markus_sabadello> The issue of forking has been discussed in the past, e.g. here: https://github.com/w3c-ccg/did-resolution/issues/43
22:14:39 <brent> ack manu
22:14:39 <Zakim> manu, you wanted to praise the diagram.
22:15:18 <markus_sabadello> q+
22:15:20 <dbuc> Manu says this is the right level of abstraction, regardless of these neuanced issues
22:15:20 <kdenhartog> For what it's worth, I agree I like the diagram so +1 to what's being proposed here.
22:15:22 <brent> ack wayne
22:15:26 <dlongley> +1 to diagram
22:15:38 <manu> kyle, the high level answer is the same as what happens when you have two documents describing the same subject.
22:15:52 <manu> same as copy-paste same document on web, kyle -- not an issue...
22:16:05 <manu> modify one document,
22:16:09 <brent> ack jonathan_holt
22:16:10 <dbuc> Wayne points out that the fetch could be subject to many different routes/constraints for how one gets the DID Doc data
22:16:49 <dbuc> Jonathan: DID resolves to the DID Document, and is under the control of the Controller
22:16:49 <manu> -1 to that
22:17:05 <dbuc> Drummond: let's take it out back
22:17:06 <pam> pam has joined #did
22:17:12 <brent> ack Orie
22:17:12 <Zakim> Orie, you wanted to kill the forking debate
22:17:26 <dbuc> Orie: don't worry about forking
22:17:47 <brent> ack dbuc
22:17:48 <manu> +1 to what Orie just said
22:17:56 <kdenhartog> q+
22:18:08 <pam> present+
22:18:16 <brent> ack markus_sabadello
22:19:29 <dbuc> Markus: if you want to be aligned with all the Web, info resources, and LD concepts, there may be issues here and there, but this conceptual framework works for the things we need, practically speaking
22:19:34 <brent> ack kdenhartog
22:20:00 <dbuc> Kyle: agrees with Orie, this diagram addresses my concerns
22:20:30 <dbuc> Drummond: if you want to know what resource is being ID'd/described, you'd need a type property
22:20:36 <dbuc> q+
22:21:03 <agropper> resource = subject?
22:21:23 <manu> +1 to that
22:21:28 <dbuc> Drummond: May not require a separate prop if it can be done in the DID Doc
22:21:30 <brent> ack dbuc
22:21:43 <manu> dbuc: is this the idea that type field can flag to say this can be a type of entity, like company, device, etc?
22:21:47 <manu> drummond: yes
22:22:08 <manu> drummond: type is an opportunity to say "this is the type of DID Subject being identified", person, software, AI, company, etc.
22:22:16 <manu> dbuc: Are you saying we work those concepts into the DID Doc?
22:22:27 <manu> drummond: This is proposing removing PR for representation
22:22:41 <kdenhartog> Do we remember why we removed it?
22:22:46 <manu> drummond: add a type property, remove representation property
22:22:49 <kdenhartog> q+
22:22:49 <dmitriz> q+
22:22:53 <manu> yes, because people didn't understand it's purpose :P
22:23:00 <kdenhartog> q-
22:23:16 <manu> +1 for type property
22:23:19 <dmitriz> q-
22:23:59 <dbuc> Drummond: DID Doc can assert an asymmetrical alias to another URI that may deference to another description of the DID Subject
22:24:23 <dbuc> Drummond: 'aka' does not apply to a full graph merge between the two
22:25:00 <dbuc> Drummond: Could also do a seeAlso prop, which implies you could merge the full graph merge of the two resources
22:25:37 <manu> q+
22:25:39 <dbuc> +1 for type prop (from Daniel)
22:25:45 <brent> ack manu
22:25:55 <kdenhartog> q+
22:26:37 <dbuc> Drummond: seeAlso means you have another ID for the DID Subject that is an equiv ID, and asserts owl:sameAs relationship
22:26:51 <dbuc> Manu: don't thing that part is true
22:27:12 <jonathan_holt> q+
22:27:14 <dbuc> Manu: semantics aren't the same as owl:sameAs
22:27:28 <dbuc> same same, but different, but still not the sameAs
22:27:42 <brent> ack kdenhartog
22:27:47 <dbuc> Manu: could be added to the registry later
22:27:54 <dbuc> Kyle: should type be MUST or SHOULD?
22:28:08 <dbuc> Drummond: I see it as a MAY
22:28:49 <dbuc> Kyle: does that cause issues if we have to assume a DID Doc is describing something in a different way than JSON-LD would with types?
22:29:01 <manu> q+
22:29:09 <pam> q+
22:29:19 <dbuc> Drummond: JSON-LD would be one way of interpreting, but doesn't have to be that way, imo
22:29:21 <manu> q+ to speak to type property in JSON-LD.
22:29:21 <kdenhartog> Cool thanks
22:29:29 <brent> ack jonathan_holt
22:29:31 <justin_r> +1 to not making any properties json-ld specific
22:29:34 <justin_r> present+
22:29:51 <manu> +1 to what jonathan_holt said
22:29:54 <dbuc> Jonathan: what we're trying to do is create subject-object relationship, and could be punted to VCs
22:30:03 <dlongley> type should be or map to a globally unambiguous identifier itself (so a URI)
22:30:20 <dbuc> Drummond: most can be punted to VCs, but there are things that make sense to be in the DID Doc
22:30:59 <brent> ack manu
22:30:59 <Zakim> manu, you wanted to speak to type property in JSON-LD.
22:30:59 <dbuc> Drummond: if you need type/descriptive info to be private, do elsewhere
22:31:16 <dbuc> Manu: we don't need to make type JSON-LD specific
22:31:31 <kdenhartog> +1 to not making it JSON-LD specific and making sure it's compatible with JSON-LD
22:31:56 <brent> ack pam
22:32:12 <dbuc> Pam: Looking for what description means
22:32:23 <manu> yes, sameAs can be completely fraudulent
22:32:31 <manu> you'd need a bidirectional link for it to not be fraudulent
22:32:32 <dbuc> Pam: sameAs is or is not validate?
22:32:44 <jonathan_holt> oh, snap.   good point!
22:32:49 <manu> A sameAs B ... AND ... B sameAs A <--- not fraudulent
22:33:00 <manu> A sameAs B <-- could be fraudulent
22:33:16 <dbuc> Drummond: many security issues, agreed
22:33:39 <dbuc> Brent: watch for PRs, pounce on them like a mountain lion
22:33:54 <jonathan_holt> did:method:id --> same_as --> did:method:sitoshi
22:34:01 <brent> https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
22:34:05 <drummond> topic: Core Issues status check
22:34:40 <brent> https://github.com/w3c/did-core/issues/85
22:35:49 <brent> https://github.com/w3c/did-core/issues/163
22:36:16 <brent> https://github.com/w3c/did-core/issues/119
22:37:41 <brent> https://github.com/w3c/did-core/issues/105
22:38:18 <brent> https://github.com/w3c/did-core/issues/329
22:38:20 <dlongley> q+
22:38:30 <brent> ack dlongley
22:38:55 <brent> https://github.com/w3c/did-core/issues/33
22:39:22 <dlongley> this is "owl:sameAs"
22:39:29 <dlongley> or any variant of that
22:41:02 <brent> https://github.com/w3c/did-core/issues/58
22:42:55 <brent> https://github.com/w3c/did-core/issues/72
22:44:45 <brent> https://github.com/w3c/did-core/issues/325
22:45:10 <dbuc> Manu: mike said secpR1 doesn't need to be 32 bytes long
22:45:20 <dbuc> Brent: marking pending close
22:45:35 <brent> https://github.com/w3c/did-core/issues/118
22:46:05 <dbuc> Dan: correct, do closer to CR
22:46:17 <brent> https://github.com/w3c/did-core/issues/269
22:46:39 <dbuc> Kyle: PR exists, considering closing pending the Appendix work
22:47:03 <brent> https://github.com/w3c/did-core/issues/240
22:47:35 <dbuc> Orie: think we resolved this by saying a firm "Not really"
22:48:05 <dbuc> Orie: consensus seems to be don't add any specific JWK restrictions
22:48:39 <dbuc> Manu: I think we have a resolution about not adding private data in DID Doc
22:48:51 <brent> https://github.com/w3c/did-core/issues/356
22:49:25 <dbuc> Orie: think we're making progress by removing pub key PEM
22:49:40 <dbuc> Brent: do we need a normative statement via PR?
22:50:02 <dbuc> Orie: will review, but would be wise to say you can't put both in a verification menthod
22:50:20 <brent> https://github.com/w3c/did-core/issues/337
22:52:05 <dbuc> Orie: URL params do not get reflected in the DID Doc
22:52:22 <dbuc> Daniel: should probably be output in resolution metadata
22:52:48 <dbuc> Orie: should add more explicit text in the DID Parameters portion of the spec
22:53:28 <brent> https://github.com/w3c/did-core/issues/137
22:54:29 <dbuc> Markus: there are five DID params in the spec today, others in the registries. Out of the five in Core, the hash link one references an IETF draft, and is about whether we can ref it in a normative way
22:55:19 <dbuc> Markus: recommends waiting to make a normative ref to the IETF specification
22:55:40 <dbuc> Brent: think we should mark as nonnormative until we can mark as normative
22:55:57 <brent> https://github.com/w3c/did-core/issues/261
22:57:14 <dbuc> Markus: 'client' used in many different ways in the spec. Seems case-specific, but there are ways to clarify these refs
22:58:15 <dbuc> Brent: thanks daniel for his crappy scribe job
22:58:22 <dbuc> ;)