DID WG Telco — Minutes

Date: 2020-08-25

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

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