DID Working Group Telco — Minutes

Date: 2019-10-15

See also the Agenda and the IRC Log

Attendees

Present: Brent Zundel, Ivan Herman, James Fishback, Michael Jones, Manu Sporny, Dave Longley, Phil Archer, Orie Steele, Ted Thibodeau Jr, Dmitri Zagidulin, Markus Sabadello, Kenneth Ebert, Alexander Hripak, Amy Guy, Justin Richer, Joe Andrieu, Ganesh Annan, Samuel Smith, Yancy Ribbens, Adrian Gropper, Drummond Reed, David Ezell, Kim Duffy, Michael Lodder

Regrets: Daniel Burnett

Guests:

Chair: Brent Zundel

Scribe(s): Kenneth Ebert

Content:

Phil Archer: F2f?

Brent Zundel: We can discuss what we have so far.
… Agenda items?
… Accept previous meeting minutes.

Michael Jones: Can we talk about #67?

Brent Zundel: Yes

1. Introductions

Orie Steele: I’m from Transmute

Justin Richer: New to this call, Justin Richter

Kenneth Ebert: Joel Hartshorn: Will be officially joining the group.

2. Face to Face

Brent Zundel: Last week of Jan in London.
… Arrangements are not finalized yet.

Drummond Reed: Will the sun be shining?

Michael Jones: I am trying to find MS space.
… I have not located any yet

3. meeting minutes

Brent Zundel: Please use IRC to queue

Manu Sporny: +1 to accept previous meetings minutes.

Drummond Reed: +1

Brent Zundel: Anyone opposed to accepting previous meeting minutes.
… Accepted.

Resolution #1: last week’s minutes accepted

Manu Sporny: +1 to take that out of our agenda line up :)

4. Assign unassigned issues

Manu Sporny: remaining unassigned issues were assigned to drummond and markus
… Orie, I assigned your issue to you.

Orie Steele: no objections

Drummond Reed: manu: I want to ask you about those editorial issues because I could not find the ones you assigned to me. We can discuss that offline.

5. issues

Brent Zundel: Let’s start with #5

5.1. context hosting #5

Manu Sporny: See Issue #5

Brent Zundel: Opinions?

Ivan Herman: There are two issues. Where and what URL.
… The usual place is w3.org/ns/…
… I propose we use the same method. The document can be stored elsewhere and have a redirect.

Manu Sporny: https://w3c.github.io/vc-data-model/#example-1-a-simple-example-of-a-verifiable-credential

Manu Sporny: We had this discussion in VCWG.
… We decided to not use ns because of the emotional response.

Manu Sporny: https://www.w3.org/2018/credentials/v1

Manu Sporny: There is not a redirect.
… During working drafts we redirected to the github updated version.
… The other thing was say in the spec that we will not change the context after the spec is finalized.
… This allows caching or hardcoding by developers.
… I hope we can use the same approach.

Ivan Herman: Whether we use ns or not: I find the date space more difficult personally
… but I won’t lie down the road over this.
… Redirect to github during development is my intention also.
… After we go to recommendation, it should be fixed.

Ivan Herman: I don’t know if we need to discuss versioning right now.

Phil Archer: The discusion re: persistant URL is of interest to me.

Phil Archer: See W3C Peristence policy

Phil Archer: The date space may not persist.
… Version numbers are problematic, ask DanBri and the Foaf URL

Amy Guy: I wanted to remind people that having the context on github made actual use difficult.

Orie Steele: +1 for hosting on github pages

Dmitri Zagidulin: Can we please host at github with a proper file extension.

Manu Sporny: Versioning must be accounted for.
… Most problems were with the hosting not the actual developers.
… Extensions and Mime types in particular.

Dmitri Zagidulin: (would like to remind everyone about the writeup / explainer about versioning contexts, over at https://github.com/w3c-ccg/did-spec/pull/272 )

Manu Sporny: During development will create a moving target necessarily.
… VCWG had the same debates.
… Can we summarize where we have consensus?

Brent Zundel: Can we wrap up?

Justin Richer: Some people will see the URLs as just a place for comparing.

Manu Sporny: +1 to Justin_R — yes, this isn’t a “purely Linked Data” world we’re working in here…

Manu Sporny: also – just to be clear… I’d personally be opposed to /ns/ URL and non-versioned (and we have good reasons for that)… I’ll have to see what our corporate position is.

Ivan Herman: Amy confirmed that redirection can be set up with proper types, so that is not a problem

Brent Zundel: Let’s move discussion to the issue.

Manu Sporny: I think we have consensus around hosting at W3C. Versioning on the github.
… No consensus on ns or versioning.
… I will summarize in the issue.

Manu Sporny: I summarized context issue here – https://github.com/w3c/did-spec/issues/5#issuecomment-542269659

5.2. FPWD

Manu Sporny: See Issue #68

Ivan Herman: A First Public Working Draft is the first of a series of drafts at w3.org/…
… This becomes a reference to the world.
… All the drafts will then be accessible.
… It starts the IPR process.
… Members can review and start any legal process required.
… Once this is published we can change our publishing method to quickly publish updates.

Ted Thibodeau Jr: +1 FPWD at editors’ will

Brent Zundel: It does not have to reflect consensus.

Ivan Herman: It just starts the process. Many changes can occur. This draft is way beyond the normal starting draft.

Phil Archer: In my mind we shouldn’t publish a spec working draft until we publish our first use case document.

Justin Richer: My qualm is re: document structure. Can we split or add to the document?

Manu Sporny: Justin_R, yes, absolutely, we have A LOT of structural flexibility.

Ivan Herman: Yes we can.

Justin Richer: Discussion at IIW and DID resolution brought this to my attention.

Ivan Herman: +1 to markus_sabadello

Dave Longley: +1

Orie Steele: +1

Brent Zundel: +1

Manu Sporny: +1 to markus_sabadello

Drummond Reed: +1

Markus Sabadello: This first draft would help people know that this is where work is continuing on this topic.

Manu Sporny: I agree in principle with Phil, but without firm knowledge of when the other docs will be ready, let’s publish the working draft now.

Drummond Reed: I agree in theory with phil, but I am having trouble referencing the right document.
… In issue #18 regarding resolution should not prevent publishing a working draft.

Manu Sporny: +1 to publishing DID Spec FPWD ASAP

Brent Zundel: I agree with manu, markus, and drummond. I would really like a working draft now.

Michael Lodder: +1 to publish

Brent Zundel: Anyone opposed?

Samuel Smith: +1 to publish

Dave Longley: +1 to publish

Kenneth Ebert: +1 to publish

Orie Steele: +1 to publish

Ivan Herman: We also need a formal resolution and another one on using Echidna

Manu Sporny: +1 to using Echidna!

Drummond Reed: +1

Manu Sporny: please please please let’s use Echidna

Adrian Gropper: +1

Michael Jones: There’s already a public draft at https://w3c.github.io/did-spec/

Ivan Herman: We also have to include in the resolution what the short name is. Is it then ‘did-spec”

Drummond Reed: Understood, Ivan, we appreciate it.

Drummond Reed: Yes, please, make the short name did-spec

Michael Lodder: as long as we can change it later if needed

Manu Sporny: Notes vc-data-model … alternatives could be dids or did-data-model

Michael Jones: We already have public working draft on github.
… Until we resolve some fundemental issues, we shouldn’t publish a working draft.
… Consensus is implied.

Manu Sporny: -1 to wait on “resolving issues”… FPWDs don’t need group consensus.

Justin Richer: +1 to mike’s point

Michael Lodder: there might be multiple specs

Phil Archer: Why “DID spec” instead of
… “DID”

Ivan Herman: First working draft does not imply consensus.
… There are several recent examples.

Drummond Reed: To Phil: first reason is to distinguish between the spec and when you are talking about a DID (as a identifier or a scheme)

Manu Sporny: +1, FPWD does not imply group consensus…

Michael Jones: In other groups I was in, we didn’t do that until some fundamentals were settled.

Brent Zundel: #67

6.1. Key representation, #67

Ivan Herman: See Issue #67

Michael Jones: As one of the assignees, I have taken the view that key types that the json web key is already a standard.
… There are other fundamental issues being raised. Keys in the DIDs are being used to check signatures.
… These are used by applications, so we should cater to the appliations. It seems that having only one way to do it would increase interop.

Manu Sporny: I think we should put in a couple of examples.
… We have requirements that are hinted at, but are not being written down.
… Other views need to be clearly articulated in the issue discussions.
… Please add your views to the conversation.

Michael Lodder: agreed

Manu Sporny: We need a full hour to discuss this.
… In DID resolution, an idea that an option could be passed to the resolver to request keys in a particular format.

Markus Sabadello: There needs to be more discussion about this. There is the linked data signature. There is multibase.

Michael Lodder: I’m concerned we are trying to force an encoding when we should allow the encoding in value

Michael Lodder: +1 markus_sabadello

Manu Sporny: I agree with mike-lodder

Manu Sporny: (based on the requirements we’ve heard)

Michael Jones: Dave wrote in the issue, that the keys are used by the DID resolver not an application level thing.

Dave Longley: The keys may not be verified by the resolver. Some keys can be bound to an application.
… Some keys can be used by the resolver, others by applications.

Dave Longley: selfissued: in short, a DID Document may express many different keys for many different intended purposes, only some subset may be used to establish control over modifying the DID Document itself

Dave Longley: (and would therefore be consumed in some fashion by the DID network/ledger according to the DID method)

Markus Sabadello: +1 to dlongley, keys in a DID Document may or may not be used by a method and the resolver.

7. PR-s

7.1. Editorial fixes #71

Manu Sporny: See PR #71

Manu Sporny: From easy to most difficult.
… This is a language clarification PR.
… In a few days I will merge it, unless there are objections.
… The other PRs all have discussion.

7.2. Make “id” optional for services and public keys. #66

Manu Sporny: See PR #66

Markus Sabadello: This PR is about making identifiers optional. Currently they are required. There is discussion about ids.
… This is about making did optional so you can have service endpoints without dids being assigned.
… This gives did methods more flexibility.

Manu Sporny: In some discussions, Mike suggested we use kid.

Markus Sabadello: I think that discussion is orthogonal to this discussion.

Manu Sporny: Does anyone object to making them optional?

Drummond Reed: No objection

Orie Steele: No objection

Dmitri Zagidulin: I have a clarifying question.
… For service endpoints, if type is optional and id is optional, we could end up with neither.
… I think we need one or the other at least.

Markus Sabadello: With this PR we are not proposing optional type.

Manu Sporny: Do you still object?

Dmitri Zagidulin: No.

Manu Sporny: We will move forward on merging this PR after minor cleanup.

7.3. other PR_s around removing properties

Ivan Herman: See PR #26

Ivan Herman: See PR #27

Ivan Herman: See PR #28

Manu Sporny: We have three categories of PRs.
… Removing properties.
… Matrix parameters.
… Public key formats.
… There are three PRs on removing properties.
… The arguments to keep them are: Someone may use them.

Dmitri Zagidulin: link to companion issue that summarizes the arguments: https://github.com/w3c/did-spec/issues/65

Manu Sporny: To counter, just because the are not in the DID spec, does not mean that someone can use them.

Ivan Herman: dmitriz preempted me. The commonalities should be discussed via the general issue first: #65.

Markus Sabadello: I agree that #65 is a great summary.

Ted Thibodeau Jr: +1 defer these PRs until resolution of https://github.com/w3c/did-spec/issues/65

Markus Sabadello: Whether the did doc should contain metadata about itself vs about the subject.
… The group consensus has been to conflate so far.

Drummond Reed: +1 to resolve issue #65 first

Manu Sporny: Until #65 is discussed we will not merge the three issues.

8. next meetings’ timings

Ivan Herman: Next weeks meeting is not at this time.

Ted Thibodeau Jr: 6pm Boston/New York

Michael Jones: When is the next meeting?

Brent Zundel: 6:00pm EDT.

Ivan Herman: The Webex codes are also different.

Ted Thibodeau Jr: member-only post with times/links - https://lists.w3.org/Archives/Member/member-did-wg/2019Sep/0006.html

Ivan Herman: In two weeks is also different.

Brent Zundel: Look at the agenda for times and links.

Drummond Reed: Thanks for the reminder, Ivan.

9. Resolutions