DID WG Telco — Minutes

Date: 2021-01-05

See also the Agenda and the IRC Log


Present: Daniel Burnett, Ivan Herman, Brent Zundel, Shigeya Suzuki, Adrian Gropper, Dave Longley, Drummond Reed, Amy Guy, Dmitri Zagidulin, Kaliya Young, Phil Archer, Michael Jones, Manu Sporny, Orie Steele, Joe Andrieu, Ned Smith, Geun-Hyung Kim, Jonathan Holt, Eugeniu Rusu, Charles Lehner, Markus Sabadello, Juan Caballero, Justin Richer



Chair: Brent Zundel

Scribe(s): Daniel Burnett, Brent Zundel


1. Agenda Review, Introductions, Re-introductions.

Brent Zundel: presents agenda.
… reminder: if you have not yet voted in TAG election, deadline is midnight US ET tonight, so vote!.
… this is for AC reps.
… reintroductions?.

Markus Sabadello: Editor of DID core spec, with Danube Tech. Been working on DIDs etc since the beginning. Interested in resolution aspect of the topic..

Charles Lehner: work for spruce systems. I have to rejoin as others..

Ivan Herman: wayne needs to take care of getting you on the list, charles..

Geun-Hyung Kim: I work for Gooroomee. I am member of W3C and joined this group to check out DID..

2. Reminder to Re-Join WG.

Brent Zundel: we have officially rechartered the group due to the new patent policy, so we all have to rejoin. Orgs, please rejoin. 30th of this month is last opportunity. After that you will be removed from the group.
… do individuals also need to rejoin?.

Ivan Herman: AC rep does renewal for the org, then selects which individuals already in the group to continue..

Brent Zundel: I had received an email asking me to rejoin, so just checking.

Ivan Herman: yes, that was an automated email but you’re fine..

Michael Jones: what does an org need to do to rejoin.

Ivan Herman: microsoft has already done it, and you are all set.
… the AC rep for MSFT should have done this for everyone in the group.

Brent Zundel: there was a special topic call scheduled for today, but we have canceled it.

3. Give feedback on PR 460

See github pull request #460.

Brent Zundel: If you have not looked at this non-normative appendix text, please do. They are important for the spec.

Drummond Reed: on 460, there has been some good feedback. since resource parameter has been pulled in, the appendix text needs a small update..

Drummond Reed: encourage everyone to take a look at the text and comment. Preferably this week so I can update this weekend.

Brent Zundel: if your AC rep needs the link let us know.

Joe Andrieu: on 460, I posted a lot. The current language is confusing and misleading. We can do better. Identifiers refer to things rather than identifying things..

Brent Zundel: everyone, please make your opinions known on the pull request..

4. Registry resolutions.

Brent Zundel: https://www.w3.org/2019/did-wg/Meetings/Minutes/2020-12-17-did-topic#resolution1.

Brent Zundel: a number of resolutions were made in a special topic call in December..
… Our standard work mode is, because we provide minutes and advertise the calls, after 7 days we assume the decision reflects the will of the g9roup. In this case we allowed extra time due to the holidays. Will run now as a proposal..

Proposed resolution: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group.. (Brent Zundel)

Michael Jones: +1.

Manu Sporny: +1.

Orie Steele: +1.

Michael Jones: +1.

Markus Sabadello: +1.

Eugeniu Rusu: +1.

Adrian Gropper: +1.

Dave Longley: +1.

Shigeya Suzuki: +1.

Daniel Burnett: +1.

Joe Andrieu: +1.

Ivan Herman: +1.

Dmitri Zagidulin: +1.

Amy Guy: +1.

Brent Zundel: +1.

Drummond Reed: +1.

Resolution #1: The DID Working Group will maintain the DID Spec Registries until the end of its charter. The DID Working Group plans to request the management of W3C to submit a charter for a maintenance DID Working Group to the W3C Advisory Committee as a successor to this Working Group. Per the planned charter of that Working Group, that group would officially manage the registry, and would do that in cooperation with the W3C Credentials Community Group..

Ivan Herman: this was the only one that needed confirmation because of its implications for the work. The other resolutions are reflected in PRs.

Jonathan Holt: I would like an approach like the EIP process for improvements..

Brent Zundel: please suggest in the registries repo.

5. Priority 1 Issues.

Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p1+sort%3Aupdated-asc.

Brent Zundel: https://github.com/w3c/did-core/issues/118.

Brent Zundel: this will happen just before CR; editorial.

Brent Zundel: https://github.com/w3c/did-core/issues/292.

Brent Zundel: leaving open to track horizontal review. anticipate hearing from PING shortly.
… haven’t heard anything on security review.

Drummond Reed: +1 to giving PING dates.

Manu Sporny: may want to notify them that we are going to CR imminently and suggest a date when we need their feedback by.

Brent Zundel: agree. Will send them a note..

Manu Sporny: not just PING, but anyone we’re waiting on.

Brent Zundel: https://github.com/w3c/did-core/issues/199.

Brent Zundel: addressed by PR that has been merged (I think). Is there anything that needs to be addressed by appendix PR?.

Drummond Reed: yes. The substantive issue has been addressed by the resource parameter, but the balance will be addressed by the appendix PR.

Brent Zundel: manu has reflected this status now in the PR.

Brent Zundel: https://github.com/w3c/did-core/issues/291.

Brent Zundel: leaving open for PING review. Action is on brent to contact..

Brent Zundel: https://github.com/w3c/did-core/issues/119.

Brent Zundel: Same for TAG, same action item..

Brent Zundel: https://github.com/w3c/did-core/issues/170.

Joe Andrieu: what was the PR that pulled in resource?.
… I wasn’t aware of it.
… I want to look into it.

Brent Zundel: https://github.com/w3c/did-core/pull/480.

Brent Zundel: PR 480.
… the text had been modified to comply with most consensus we had in the group during our special topic call. There is not a property in the DID doc, but a parameter that can be created to ma]ke a DID URL.
… it was merged under the assumption of agreement by group, so please review.

Joe Andrieu: what you said sounds okay, but I will check.

Brent Zundel: we revised it with your opinions in mind.

Drummond Reed: I proveded response on 457 that herd privacy is important but may not apply to all DIDs. Can apply to many, but not all..

Brent Zundel: let’s not have the conversation now..

Joe Andrieu: herd privacy is about applying to ALL DIDs.
… so let’s have a special topic call on this.

Brent Zundel: I believe this has been partially addressed..

Drummond Reed: To be clear, herd privacy should to apply to all privacy-respecting DIDs for humans. To insist that it apply to all DIDs would be a major mistake..

Brent Zundel: https://github.com/w3c/did-core/issues/58.

Ivan Herman: on registry handling, I don’t see anything here not solved by our resolution..
… was about registries will be handled..
… our resolution today explains this..

Brent Zundel: can you please comment in issue, and close if happy?.

Ivan Herman: will do.

Brent Zundel: https://github.com/w3c/did-core/issues/170.

Brent Zundel: last action item needed here was for Mike to provide a PR for any text changes he believed were necessary..

Manu Sporny: changes made based on the issue are clarifying that id is different from kid and ??..
… orie has also put in multiple PRs to explain how they are different and how to set them..
… clear now that they are different..
… when will this issue be resolved?.

Michael Jones: does the issue contain links to all the PRs mentioned?.

Manu Sporny: let me know if not.

Michael Jones: I will review the spec to see if this issue is still pertinent.
… I’ll sign off or raise a PR..

Brent Zundel: https://github.com/w3c/did-core/issues/518.

Ivan Herman: I put in a PR recently about this. AKA used lists instead of ordered set. Waiting on editors..

Brent Zundel: if 522 is merged this can be closed?.

Ivan Herman: yes.

Brent Zundel: https://github.com/w3c/did-core/issues/384.

Manu Sporny: over the past few weeks have done top to bottom review of all normative statements in spec.
… there is one PR that finishes up tightening up the language.

Brent Zundel: https://github.com/w3c/did-core/pull/526.

Manu Sporny: Amy has reviewed many times. At this point think the normative statements are in good shape..
… PR 526 is the last one..
… our spec is 125 pages, will get larger with appendix. 168 normative statements, which is a lot for a data model spec..
… out of 168, about 90 are about core data model, 20 are about did methods, and remainder have to do with did resolution and dereferencing.
… good chunk of statements where it’s questionable whether we should test them..
… overall in good shape, last remaining PR to approve, then possibly decide about testing the res and deref statements..

Michael Jones: the language being used to describe normative statements is confusing. We explicitly state that the whole spec is normative unless marked otherwise..
… so let’s stop calling the 2119 language as the only normative statements. Everything else is testable.

Manu Sporny: while technically true, editors have worked hard to ensure that statements to be tested are written using the 2119 language.
… it’s hard to pick up other language. if you want something tested, use 2119 language. makes it easy for group to understand exactly what will be tested..
… easier for testing and communication..

Michael Jones: let’s not use misleading language. talk about 2119 lang you intend to write tests for. Don’t make “normative statements” be a subset of what they actually are..

Phil Archer: mike, you’re correct about the boilerplate statement that’s in all W3C specs. The way it is interpreted in all specs we are aware of is that we use the 2119 language to make clear what is to be tested as distinct from the intro text additionally included typically.

Orie Steele: we are arguing over what we test. As long as we are clear about how we make clear which statements are testable, I’m good. It shouldn’t be every statement in the spec..

Drummond Reed: +1 to just following a simple rule: apply 2119 language to any normative requirement that needs testing..

Manu Sporny: some people may have missed the testing special call. Intent is to write tests for every RFC 2119 language. If you don’t see one you think is needed, propose it..
… Also, there are never enough test writers, so we will prioritize MUST statements over SHOULDs over MAYs in our test development..
… anything MUST that is testable by machine WILL be in the test suite. For others we’ll see how far we get..

Daniel Burnett: just wanted to chime in on 2119 language. this is common pattern in specs, to include informational text and all statements we want tested uses 2119 language..

Brent Zundel: review 526.
… if you feel language should be tested, propose RFC 2119 language for that text.

Brent Zundel: https://github.com/w3c/did-core/issues/495.

Markus Sabadello: it’s waiting for a PR from Shigeya. Just adding a clarification..

6. Priority 2 Issues.

Brent Zundel: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p2+sort%3Aupdated-asc.

Brent Zundel: https://github.com/w3c/did-core/issues/163.

Brent Zundel: this will be done just before CR; editorial.

Brent Zundel: https://github.com/w3c/did-core/issues/404.

Brent Zundel: please review https://github.com/w3c/did-core/pull/528.

Ivan Herman: there were discussions on various PRs. Latest one has now been reviewed by Amy and Manu. PR 528. To make definitions clearer I gave an editorial review that called out all the constraints in the text into a table..
… don’t know if editors agree. IF pulled in, then rest is not normative (not needed before CR).
… we still have to collect various ways of specifying vocab for different serializations, but that should not be normative.
… making a first version of a JSON Schema for core vocab.
… will not touch CBOR/CDDL. Also did something for JSON-LD version. Should be made publicly available somewhere..
… If manu and other editors agree, this can be closed..
… I raised two minor issues on some of the constraints. I leave to the editors..

Brent Zundel: so next steps would d be to review and merge 528, then create non-normative vocabs for the different representations?.

Ivan Herman: yes.

Brent Zundel: ivan, can you please update issue with that status?.

Brent Zundel: https://github.com/w3c/did-core/issues/425.

Joe Andrieu: shouldn’t be assigned to me. I made the comment and Wendy Seltzer commented. She suggested looking at IANA protocol registries. There is a larger problem in that we don’t have a mechanism..
… not sure how to turn into spec text.

Manu Sporny: the title threw me off. Now i understand. I volunteered to implement our resolutions from the related topic call..
… we have clear resolutions that need implementing. I volunteer to do that..

Brent Zundel: https://github.com/w3c/did-core/issues/208.

Manu Sporny: Amy has done most of the work here, including a spec on how to deal with mime type suffixes, Ted has contributed..
… qusetion is what to do with DID JSON-LD MIME type and what to do if we can’t register it as we would like..
… what happens at this point deepens largely on IETF. If they do nothing we have a plan B that is documented in the Features at Risk.

Ivan Herman: there is also a PR that needs to be merged..

Brent Zundel: https://github.com/w3c/did-core/pull/524.

Manu Sporny: agreed..

Ivan Herman: also, I contacted PLH to be prepared for this. He is okay with the language we are proposing..

Jonathan Holt: curious about process. Problem is concatenating three MIME types.
… what about CBOR-LD DID and others?.

Manu Sporny: MIME types have to do with specific representation (byte serialization). No issue with DID-CBOR or DID-JSON. Problem is IETF has never given guidance on more than one + sign..
… big unanswered question. We are trying to answer it. Only the did+json+ld is an issue..

Ivan Herman: W3C has a mechanism to submit MIME types that are part of a Recommendation.
… not sure when I need to do that, but will find out..
… no problem with did+json or did+cbor.

Phil Archer: phila_: I am interested in the outcome here. I’d like to be able to use linkset+ld+json (i.e. two + symbols).

Manu Sporny: manu: phila, if we’re successful here – you can just do that…. if we’re unsuccessful, you can use a profile= parameter.

Jonathan Holt: This may also be a problem for did+dag+cbor..

Ivan Herman: jonathan_holt: yes, that is exactly the same problem.

Manu Sporny: jonathan_holt – yes, it would be a problem for did+dag+cbor.

Brent Zundel: https://github.com/w3c/did-core/issues/363.

Brent Zundel: https://github.com/w3c/did-core/pull/525.

Manu Sporny: submitted PR, waiting for PR to go through and original issue submitter to okay.

Brent Zundel: seems to be a comment to that effect. everyone, please review..

Brent Zundel: https://github.com/w3c/did-core/issues/463.

Brent Zundel: we merged a number of PRs for data model and rep sections. Needed agreement on final terminology for rep-specific properties..
… please look at diagram and comment. Next step is whether we want to call @context a property. Not to reopen conversation, but to call rep-dependent and rep-independent things by different terms..

Manu Sporny: if you are trying to get PRs in, we are trying to get to CR (ideally by end of this month). Now is the time to get PRs in. There will be a time when we decide to defer anything without PRs or consensus..

Manu Sporny: If you have an issue you care about and are not writing a PR, we will eventually ask to defer the issue. Ideally end of this month..

Drummond Reed: +1.

Drummond Reed: Let’s get to CR by the end of the month!.

Joe Andrieu: btw, for the record, after reviewing PR 480, I believe we need to reopen that discussion as it was merged without consent..

7. Resolutions