DID WG Telco — Minutes
Date: 2020-08-25
See also the Agenda and the IRC Log
Attendees
Present: Daniel Burnett, Brent Zundel, Wayne Chang, Orie Steele, Dave Longley, Manu Sporny, Drummond Reed, Markus Sabadello, Dmitri Zagidulin, Adrian Gropper, Amy Guy, Kaliya Young, Kyle Den Hartog, Daniel Buchner, Jonathan Holt, Pamela Dingle, Justin Richer
Regrets:
Guests:
Chair: Brent Zundel
Scribe(s): Drummond Reed, Manu Sporny, Daniel Buchner
Content:
Brent Zundel: skipping intros for today
… next topic call - noon Eastern Time on Thursday - will cover service endpoints
… 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
… goal is to get to CR
… anyone who has issues with those dates, please tell the chairs
1. DID spec review
Brent Zundel: we want the spec to be reviewed by external groups - CCG, DIF, other groups
2. Link Relations
Brent Zundel: Drummond will present a few diagrams and properties
Drummond Reed: presenting about appendices
… What does a DID identify? - the first one
… Sidestepping question of what is an information resource, and what isn’t
… 3 possible answers: DID subject as a resource, DID Document as a resource, or both
… DID identifies DID Subject and resolves the DID Document (diagram of Controller pointing to DID Document and the DID Subject)
Manu Sporny: +1 to this diagram
Manu Sporny: I like it
Orie Steele: +1 to this diagram
Dave Longley: that’s just a different resolver
Daniel Burnett: The method needs to define what happens
Daniel Buchner: People asking what is identified if there is a fork
Dave Longley: “what if resolver A returns X and resolver B returns Y” <– pick your favorite resolver, that’s what.
Markus Sabadello: The issue of forking has been discussed in the past, e.g. here: https://github.com/w3c-ccg/did-resolution/issues/43
Manu Sporny: this is the right level of abstraction, regardless of these nuanced issues
Kyle Den Hartog: For what it’s worth, I agree I like the diagram so +1 to what’s being proposed here.
Dave Longley: +1 to diagram
Manu Sporny: kyle, the high level answer is the same as what happens when you have two documents describing the same subject.
Manu Sporny: same as copy-paste same document on web, kyle – not an issue…
Manu Sporny: modify one document,
Wayne Chang: the fetch could be subject to many different routes/constraints for how one gets the DID Doc data
Jonathan Holt: DID resolves to the DID Document, and is under the control of the Controller
Manu Sporny: -1 to that
Drummond Reed: let’s take it out back
Orie Steele: don’t worry about forking
Manu Sporny: +1 to what Orie just said
Markus Sabadello: 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
Kyle Den Hartog: agrees with Orie, this diagram addresses my concerns
Drummond Reed: if you want to know what resource is being ID’d/described, you’d need a type property
Adrian Gropper: resource = subject?
Manu Sporny: +1 to that
Drummond Reed: May not require a separate prop if it can be done in the DID Doc
Daniel Buchner: is this the idea that type field can flag to say this can be a type of entity, like company, device, etc?
Drummond Reed: yes
… type is an opportunity to say “this is the type of DID Subject being identified”, person, software, AI, company, etc.
Daniel Buchner: Are you saying we work those concepts into the DID Doc?
Drummond Reed: This is proposing removing PR for representation
Kyle Den Hartog: Do we remember why we removed it?
Drummond Reed: add a type property, remove representation property
Manu Sporny: yes, because people didn’t understand it’s purpose :P
Manu Sporny: +1 for type property
Drummond Reed: DID Doc can assert an asymmetrical alias to another URI that may deference to another description of the DID Subject
… ‘aka’ does not apply to a full graph merge between the two
… Could also do a seeAlso prop, which implies you could merge the full graph merge of the two resources
Daniel Buchner: +1 for type prop (from Daniel)
Drummond Reed: seeAlso means you have another ID for the DID Subject that is an equiv ID, and asserts owl:sameAs relationship
Manu Sporny: don’t thing that part is true
… semantics aren’t the same as owl:sameAs
Daniel Buchner: same same, but different, but still not the sameAs
Manu Sporny: could be added to the registry later
Kyle Den Hartog: should type be MUST or SHOULD?
Drummond Reed: I see it as a MAY
Kyle Den Hartog: 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?
Drummond Reed: JSON-LD would be one way of interpreting, but doesn’t have to be that way, imo
Kyle Den Hartog: Cool thanks
Justin Richer: +1 to not making any properties json-ld specific
Manu Sporny: +1 to what jonathan_holt said
Jonathan Holt: what we’re trying to do is create subject-object relationship, and could be punted to VCs
Dave Longley: type should be or map to a globally unambiguous identifier itself (so a URI)
Drummond Reed: most can be punted to VCs, but there are things that make sense to be in the DID Doc
… if you need type/descriptive info to be private, do elsewhere
Manu Sporny: we don’t need to make type JSON-LD specific
Kyle Den Hartog: +1 to not making it JSON-LD specific and making sure it’s compatible with JSON-LD
Pamela Dingle: Looking for what description means
Manu Sporny: yes, sameAs can be completely fraudulent
Manu Sporny: you’d need a bidirectional link for it to not be fraudulent
Pamela Dingle: sameAs is or is not validate?
Jonathan Holt: oh, snap. good point!
Manu Sporny:
A sameAs B ... AND ... B sameAs A
<— not fraudulent
Manu Sporny:
A sameAs B
<– could be fraudulent
Drummond Reed: many security issues, agreed
Brent Zundel: watch for PRs, pounce on them like a mountain lion
Jonathan Holt:
did:method:id --> same_as --> did:method:sitoshi
Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
3. Core Issues status check
Brent Zundel: https://github.com/w3c/did-core/issues/85
Brent Zundel: https://github.com/w3c/did-core/issues/163
Brent Zundel: https://github.com/w3c/did-core/issues/119
Brent Zundel: https://github.com/w3c/did-core/issues/105
Brent Zundel: https://github.com/w3c/did-core/issues/329
Brent Zundel: https://github.com/w3c/did-core/issues/33
Dave Longley: this is “owl:sameAs”
Dave Longley: or any variant of that
Brent Zundel: https://github.com/w3c/did-core/issues/58
Brent Zundel: https://github.com/w3c/did-core/issues/72
Brent Zundel: https://github.com/w3c/did-core/issues/325
Manu Sporny: mike said secpR1 doesn’t need to be 32 bytes long
Brent Zundel: marking pending close
Brent Zundel: https://github.com/w3c/did-core/issues/118
dan: correct, do closer to CR
Brent Zundel: https://github.com/w3c/did-core/issues/269
Kyle Den Hartog: PR exists, considering closing pending the Appendix work
Brent Zundel: https://github.com/w3c/did-core/issues/240
Orie Steele: think we resolved this by saying a firm “Not really”
… consensus seems to be don’t add any specific JWK restrictions
Manu Sporny: I think we have a resolution about not adding private data in DID Doc
Brent Zundel: https://github.com/w3c/did-core/issues/356
Orie Steele: think we’re making progress by removing pub key PEM
Brent Zundel: do we need a normative statement via PR?
Orie Steele: will review, but would be wise to say you can’t put both in a verification menthod
Brent Zundel: https://github.com/w3c/did-core/issues/337
Orie Steele: URL params do not get reflected in the DID Doc
Daniel Buchner: should probably be output in resolution metadata
Orie Steele: should add more explicit text in the DID Parameters portion of the spec
Brent Zundel: https://github.com/w3c/did-core/issues/137
Markus Sabadello: 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
… recommends waiting to make a normative ref to the IETF specification
Brent Zundel: think we should mark as non-normative until we can mark as normative
Brent Zundel: https://github.com/w3c/did-core/issues/261
Markus Sabadello: ‘client’ used in many different ways in the spec. Seems case-specific, but there are ways to clarify these refs
Brent Zundel: thanks daniel for his scribe job