DID WG Telco — Minutes

Date: 2021-05-04

See also the Agenda and the IRC Log

Attendees

Present: Ivan Herman, Manu Sporny, Brent Zundel, Shigeya Suzuki, Charles Lehner, Justin Richer, Chris Winczewski, Amy Guy, Geun-Hyung, Ted Thibodeau Jr., Drummond Reed, Dmitri Zagidulin, Juan Caballero, Adrian Gropper, Daniel Burnett

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Charles Lehner

Content:

Geun-Hyung: Geun-Hyung has joined #did

Brent Zundel: first topic: agenda review, along with intros and reintros
… announcing special topic, brief test coverage report.
… then jump into conversation about additional notes our group hoping to publish - impl guide and rubric
… then go through did-core PRs, issues. any questions, suggestions, changing/adding to agenda?

1. Special Topic Call

Brent Zundel: We know each other well enough - skipping reintros. Moving on…
… Special Topic Call: Thursday 12pm eastern time - DID Rubric
… We will be working on that document, refining it, feedback, making progress.

2. Test Coverage Report

Brent Zundel: Now we have a brief test coverage report.

Manu Sporny: Over the past month and some change, there have been a number of people implementing tests in the test suite. Thank you to everyone who has submitted tests.

Manu Sporny: https://github.com/w3c/did-test-suite/issues/72

Manu Sporny: Linking to a couple of things… First item: set of issues tracking the test suite audit.
… Issue 72: Amy went through latest specification. This includes latest PRs merged. Went through every normative statement in specification, pulled out by section, created checklist, to ensure every statement intended to test has a test in the test suite.
… Editors and contributors have gone through checklist for every test, checked boxes felt needed to check; have not checked boxes for SHOULD/MAY statements, or human-testable statements.
… Have completed that as of Sunday. Done full audit pass through specification.
… We have tests for everything we believe we wanted to test, except for the CBOR section.
… No tests for the CBOR section - they have not been submitted. Today is cutoff day.
… Everything else includes tests.
… Issues 72 through 77 cover those tests.
… I believe the audit is complete at this point.
… Question: what to do about the CBOR section.
… We did find a couple tests missing, a handful; language had changed, not reflected in tests. There are new PRs in to fix all of those omissions/errors.
… Haven’t pulled in PRs yet but they have reviews; waiting a couple days before merging.
… That’s where we are. All documented in issues.

3. CBOR section

See github issue did-test-suite#28.

Brent Zundel: Chair things.
… On the 13th of April, the chairs set a deadline for tests to be written.
… for the end of April - and stated at that time that any normative statements that were untestable because no tests were written, would have to be removed from the specification.
… What this means for group is need to decide what to do with the CBOR section.
… Issue where CBOR production/consumption rules discussed at a meeting in April
… It is clear from those comments that the concerned parties were aware of the need for tests to be written. There was also a special topic call on the 8th of April
… that focused primarily on the CBOR section and how to test it, with concerned parties.
… I outline all of this to make very clear that communication has been clear, and that all efforts have been made, as chairs and editorial staff, to encourage the writing of these tests.
… With all of that said, we have some options, and will write these up as formal proposals once we get feedback from group.
… Option 1: remove CBOR from DID Specification, and publish it as separate note.
… Option 2: Remove CBOR from Specification to informative appendix of specification.
… Option 3: remove it and don’t do anything
… My encouragement is to strongly consider option 1.
… Opening to group for comments/suggestions.

Amy Guy: +1 option 1 .. makes sense as a note, which can be linked to from the registries, as any representation spec would be

Justin Richer: My concern for CBOR section as forcing function … interoperability … make JSON-based spec…
… Of options, I think 1 is best (don’t know if we are debating that) but concerned that publication as note would give less weight to the specification, and allow it to be functionally ignored by other components, for example the registries, which could morph in such a way to shut out CBOR or other representations.

Brent Zundel: For record, I agree with you for my motivations for a CBOR section
… Another option: to remove CBOR from spec, and change registries so that it can be registered as a new format in the registries.

Manu Sporny: I agree with Justin’s sentiment; I think it becomes fairly difficult to argue… we had an ADM so we could do things like CBOR
… But where we are is not tests…

Drummond Reed: We have always said that new representations should be able to be registered in the DID Spec Registries.

Manu Sporny: I don’t think anyone is actually implementing CBOR, they are doing variations on it. Digital Bazaar had: we are interested in CBOR-LD; would be interested in publishing as note.
… danger of publishing CBOR as it is, it’s a bit of an examplar - no one deploying it. would end up publishing note that no one intends to implement.
… Biggest problem is it’s in spec, but no tests, not implemented. I would be supportive of publishing as note, noting no one has implemented tests or implemented it.
… Noting … different implementation like CBOR-LD would be better, but not volunteering.
… Having example of alternative in registry is a good idea.

Ivan Herman: Just an additional point to what was said before: it may be still too early to talk about the details, but at some point in time in the coming months, we have to begin discussing how we imagine the world post this WG. What kind of continuation, etc.
… It would be possible to say that in maintenance WG following this one, we put CBOR (or CBOR-LD, etc) as potential agenda item.
… so to try to message community beyond the note, that we haven’t given up.
… We have to do what we have to do now, but long-term this group still intends to have CBOR coming at some point, when it’s ready.

Brent Zundel: Comments, suggestions?
… Please suggest alternate proposals if needed to +1. More detail needed?
… Add Ivan’s suggestion that it should be input to WG?

Drummond Reed: I’d love it for someone to speak to option 2, the appendix, the +/- of that.
… My understanding is we are going to have/allow/provide for did-spec-registries to registry new representations, like for other things.
… It could be a path for that. What is the relationship of publishing as note or in appendix, or as requirement for registry?

Ivan Herman: Slight reservation about having as note because of time: do we have someone who will volunteer to write that note?

Justin Richer: My concern with moving out into note or other thing is that it could allow for greater wiggle room in the registry
… since this group has insisted on making its own registries - than is potentially helpful
… because then we are functionally creating an abstraction from a single data representation type
… - yes there are differences between JSON and JSON-LD but these are bigger than JSON and CBOR (?)
… Concern about … constructs. Any CBOR representation would be prohibited from translating a object key(?) to an abstract property name
… We need to maintain flexibility… Concerned that without the weight of CBOR as first-class citizen, the registry could easily slip away from enabling that.

Dmitri Zagidulin: wait, but like.. the whole issue with the CBOR section is that nobody’s put forth the implementations, test suite, etc. So regardless of if we’re worried about its effect on the Registries, etc.. not much we can do here

Manu Sporny: I’ll volunteer to move the spec test. It was written to be easy to move into a note.
… I note that in the registries we have a section for representations that is empty right now.
… Having the CBOR note would allow us to point to that.
… To Justin’s concerns: none of the spec test will change in any dramatic fashion. All the work done to ensure things like translate to binary and round-trip - text remains.
… Exists in other sections that will be kept.
… Some concerns others might not understand.
… For example, CBOR-LD encoding depends on that language remaining.
… DB uses it.
… I would expect at least one editor to object to that language changing, so that it would enable CBOR-LD to exist
… which has stronger needs than vanilla CBOR stuff.

Justin Richer: FWIW I’m not concerned with core spec language changing, but with registry language itself, which is managed separately.

Manu Sporny: The CBOR-LD translation is a binary transformation from the ADM and back into the ADM.
… I’m not concerned we will lose that, but there is a risk - not sure what to do
… I don’t think the registries will be affected.

Proposed resolution: remove CBOR from the DID Core Specification, publish it as a WG Note, and add CBOR to the DID Spec Registries with a reference to the WG Note (Brent Zundel)

Manu Sporny: +1

Amy Guy: +1

Ivan Herman: +1

Drummond Reed: +1

Dmitri Zagidulin: +1

Ted Thibodeau Jr.: +1

Shigeya Suzuki: +1

Brent Zundel: +1

Adrian Gropper: +1

Daniel Burnett: +1

Charles Lehner: +1

Geun-Hyung: +1

Resolution #1: remove CBOR from the DID Core Specification, publish it as a WG Note, and add CBOR to the DID Spec Registries with a reference to the WG Note

Brent Zundel: with sadness, resolved.

4. Test suite (part 2)

Brent Zundel: If there are no more questions or comments on that topic, we will move on to a brief conversation about notes
… primarily the implementation guide, as the rubric we will talk about mostly on the special topic call.

Manu Sporny: Given where we are, that that proposal passed, that I believe means we are done with tests.
… We have tests for everything we intended to tests, including DID resolution, dereferencing and other sections.
… Test suite done at this point. Need people to submit implementations. Once PRs merged, good time to get people to submit implementations.
… Good news: we have a bunch of GitHub handles for DID Method implementors.
… Could ask them to submit implementations to test suite.
… Are we moving on to that phase where we are requesting broad implementation?

Brent Zundel: Yes, thank you.
… The chairs had said mid-May for getting implementations in. I am affirming that, with Dan’s permission.
… Two weeks from today, we’ll have another call, and by that meeting, implementations will need to be in.

Daniel Burnett: Perfect
… People can continue to send implementations after that date, but the reason giving that date is that that’s when we will look to see if we have sufficient implementations to move on in the process.
… If you know people who want to submit later, they can do that. Just don’t wait - if everyone waits, we don’t get to move on in the process.

Brent Zundel: Agreed.

5. Notes: Implementation Guide and Rubric

Brent Zundel: Chairs would like to say: if we do not have anyone sign up to be an editor of the implementation guide by the end of May, then we’re not going to have an implementation guide.
… At the end of May (possibly sooner), we will be calling for a first public working draft of the rubric note.
… I know that some work has gone into an implementation guide. Orie and possibly others have been collaborating on it.

Brent Zundel: https://w3c.github.io/did-imp-guide/

Brent Zundel: If you look at the implementation guide ^, there is some content in there, that it may be worth keeping.
… The clock is ticking… If anyone wishes the implementation guide to move forward and be publishable by the WG as a note, and you are willing to make that happen, please let the chairs know, so we can assign you as an editor and get that work accomplished.

Brent Zundel: https://w3c.github.io/did-rubric/

Manu Sporny: Note that Orie also has a huge update to the implementation guide here: https://github.com/w3c/did-imp-guide/pull/3

Brent Zundel: The rubric has had a lot of work going into it, and I understand more is underway.
… So please, before our special topic call on Thursday, familiarize yourself with the rubric, so that we can get that wrapped up.
… Any questions or comments about these notes?
… Any volunteer to be an editor of the implementation guide?

6. Pull Requests https://github.com/w3c/did-core/pulls

Brent Zundel: Is there an editor who would like to run through the PRs. or the chairs to do it?

6.1. Updating figure 2 to include example values

See github pull request #727.

Manu Sporny: PR: simple update to the diagram that shigeya is doing on behalf of someone else who did a full review of the spec.
… Their review came back with nothing really wrong.
… PR is editorial. If you have opinion on the diagram label, please take a look.

6.2. Other PR-s coming on Appendices

Manu Sporny: There is going to be a large series of PRs coming up: editorial fixes, appendices
… Editors will make a pass… Non-normative sections, not expecting a lot of discussion, just giving heads up, will be getting a lot of PRs about appendices.

Ivan Herman: There is one appendix which is still a thorn in our side: the IANA Considerations one.
… At some point we have to decide what to do with the did+ld+json stuff. We are getting dangerously close to have to make the decision.

Manu Sporny: Thank you, Ivan. Amy and I have been moving that conversation along at IETF.
… Issue is that a number of people have stepped in with comments, which is good… No clear path. people say it’s fine, others saying what does it really matter - MIME type supposed to identify completely.
… Haven’t lit a fire yet
… Initially they pushed back, wanted discussion.
… No one is saying can’t register these. Either will be a specification that talks about structured media types
… or there won’t be, but will be allowed to do it.
… Just an opaque string.

Ivan Herman: There has been push-back

Manu Sporny: There was, but we had the discussion.
… People said there should be meaning to the multiple pluses. If no meaning, can register. If meaning, need spec.
… That is my interpretation of what folks are saying there.
… We need a decision; will outline what was said.
… We can also speak to the Area Director about what the relevant path forward is, and say that the WG really needs a decision, give a concrete timeline.

Ivan Herman: I would propose first to wait for your overall editorial stuff, so that what we go to IANA with is as final text as possible.
… Once that’s done, we can just try to register the two media types. One is not a problem. The other… just see what happens.
… That’s the only way; we have to do that before we go to PR - ASAP.
… I don’t really know the mechanism as IETF. I’ll follow your lead on that manu, but we have to do it.
… Aside: let’s not forget, unfortunately, to remove the application for did+cbor

Manu Sporny: Agreed. Not an IETF expert; Justin would probably no better.
… Multiple plus signs: problem not going away. Other people have same requirement. Really does need to be pushed at IETF.
… If not this, will be did+ld+cbor.
… Will try to send email

Daniel Burnett: manu, are there any tests that depend on this result (the registration)?

Manu Sporny: Yes, there are. Good catch.

Daniel Burnett: Problem: implementation reports may change as the result of the outcome here.

Amy Guy: It is marked at risk though

Manu Sporny: ooh good point rhiaro

Daniel Burnett: We can still get implementations in; still valuable; but we may need to reach out to implementors if we need to make an adjustment.

7. DID Core issues

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

Brent Zundel: 11 open issues.

7.1. Proving Control sections are wrong

See github issue #583.

Brent Zundel: There has been a bit of conversation. Need a PR to fix issue.

Manu Sporny: General statement: I triaged issue this past weekend, marked everything that was a CR comment. Marked anything ready for a PR as ready for PR.
… Almost every one except 2 or 3 are ready for PR.

Amy Guy: brent, I’m looking at 583 but I think I’ll need help. Will ping people.

Brent Zundel: If you haven’t and always wanted to write a PR for a specification, we have a number of issues to choose from, and I encourage you to do so.

7.2. Diagrams need SVG and detailed description

See github issue #625.

Brent Zundel: I believe some work has gone into changing diagrams to SVG format. Or perhaps I am thinking of new diagrams that are SVG.

Amy Guy: brent, descriptions are also on my radar if nobody else gets there first

Brent Zundel: We need detailed descriptions for each diagram.
… Pretend that you are telling the diagram to someone who can’t see - since that what this is for.
… The technical level to contribute is low.
… Currently assigned to Markus.

7.3. Support of publicKeyMultibase

See github issue #707.

Brent Zundel: I know that some changes have come in as a result of this. What more needs to happen?

Manu Sporny: See comment on the things to do

Manu Sporny: I proposed for the publicKeyMultibase stuff a path forward in this link
… It looks like folks want to use publicKeyMultibase instead of publicKeyBase58. We do have an at-risk marker that this may be done.
… One thing could do: update examples. Already have in did-spec-registries, but could add note.
… Add to registries, update material in spec.
… Not normative.
… Concerns raised about publicKeyBase58 applies to publicKeyMultibase as well.

Justin Richer: is it not normative if it’s in the registry as a value with a link to a spec?

Manu Sporny: I believe we can make these changes; haven’t seen any objections. I will put in a PR shortly.

Justin Richer: (actual question on W3C normativity)

Manu Sporny: justin_r, no, nothing in the registry is normative – it’s just “a helpful document for people that care to know about the ecosystem”.

Ivan Herman: The vocabularies, the constraint languages, also have to updated. There are some constraints expressed using b58, not have to exchange that. JSON Schema, etc.
… I’m happy to do that when we have the document done; just listing here to be done.

Manu Sporny: justin_r, it’s the specs themselves that make things normative or not.

7.4. Explain verification suite definition and explain reuse of verification method type/material

See github issue #712.

Manu Sporny: Either Oliver will do it, or I will.
… I’ll add him as an assignee.

7.5. What is storage amplification?

See github issue #721.

Manu Sporny: There is enough there to write something. dbuchner wanted to expand it. Need to explain it; put in list of things to consider for DID method specification.

7.6. Clarification of DID URL vs (base) DID in Figure 2

See github issue #724.

Shigeya Suzuki: I think it is resolved in the latest

Brent Zundel: There is a PR for this; folks should review it

8. Call for implementers

Daniel Burnett: Because are ready to call for implementations right now, it would be appropriate to email out to the various organizations that we have communicated with at various stages in the process. Typically the chairs have done this, to email DIF, CCG, any other place as appropriate
… Because we don’t have a change in official status, but have completed tests: would like someone to volunteer to send out email to ask for implementations.
… That email needs pointer for instructions on what to do.

Manu Sporny: https://github.com/w3c/did-test-suite/#adding-your-did-implementation

Daniel Burnett: Any info for what they need to know needs to be included.
… Alternatively if someone else can get that information, chairs could send it out.
… A link is nice, if the link is completely self-contained and you believe it has everything necessary.

Manu Sporny: I believe it does.
… It has instructions. If you are an implementor, this is how to submit your implementations. … It should be straightforward and easy.
… Others have done it, without the instructions.

Daniel Burnett: It’s short… The hope is that anyone who is aware of the work should be able to follow and understand this.
… The chairs will take that as an action.

Brent Zundel: Thank you everyone.

9. Resolutions