DID WG Telco — Minutes

Date: 2021-05-25

Attendees

Present: Justin Richer, Shigeya Suzuki, Brent Zundel, Daniel Burnett, Markus Sabadello, Adrian Gropper, Michael Jones, Manu Sporny, Drummond Reed, Orie Steele, Ted Thibodeau Jr.

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Drummond Reed, Brent Zundel

Brent Zundel: Agenda review
… special topic call, implementation feedback, testing status, MIME types, DID Core issues and PRs
… Special topic call: we may or may not have one depending on the outcome today. If we have one, it will be Thursday at noon ET.

1. Status of Implementation Feedback

Manu Sporny: shared screen of implementation report
… Shigeya has done a great job of providing a report
… various DID methods are passing the “valid id property” test today.
… currently there are 150 tests all of which have to be checked manually

Shigeya Suzuki: Yes, I’m working on summary part of the report.

Manu Sporny: we currently have enough implementations of versionid
… but hl and service parameters have not been implemented yet
… these could be cut from the spec
… removing hashlink could be removed without a new CR
… but service and relativeRef are not marked as at-risk
… .we do really well elsewhere until we get to the JSON tests

Justin Richer: imho, if we drop these from the data model that will be one of the stupidest decisions this group could make :P

Manu Sporny: the data model has all the different data types and they will likely stay even if there are no implementations in JSON

Michael Jones: Having booleans and numbers should not be controversial.

Manu Sporny: Agreed. We just need a resolution supporting them.
… when we get into DID resolution and dereferencing, it gets thin.
… most of the tests are fulfilled only by the Universal Resolver and Ceramic.
… is the Universal Resolver going to implement those?

Markus Sabadello: Yes, a new PR is coming

Manu Sporny: there were 2 other features that were concerning: canonicalID and equivalentID

Justin Richer: Not sure about SecureKey using equivalentID and canonicalID, but they do use service

Orie Steele: Manu is showing a local version

Manu Sporny: Hopefully if we get ION and SecureKey in, then we’ll have coverage of those properties

Justin Richer: Do I have an action item for that?

Orie Steele: https://github.com/w3c/did-test-suite/blob/main/packages/did-core-test-server/suites/implementations/did-orb.json#L166

Manu Sporny: looks like a bug in the test suite

Orie Steele: https://github.com/w3c/did-test-suite/blob/main/packages/did-core-test-server/suites/implementations/did-orb.json#L146

Orie Steele: ^ including examples of canonical/equivalent and service.

Shigeya Suzuki: Maybe missing from default.js ?

Manu Sporny: The only concern should be with service and relativeRef.
… hopefully that’s not a big problem because we just need implementors to submit their examples.
… so we should go for another week. In the meantime, the pressure is on Markus to get the Universal Resolver in…
… and for those working on the test suite to see why some results are not showing up

Orie Steele: We should also be sure the CR system is generating the right report

Manu Sporny: We are not longer checking in the report
… and the CI system no longer works the way it did before

Brent Zundel: What are our options going forward? We have asked implementors to submit.
… we understand there are implementations supporting the service property, but are there any alternatives such as affidavits?

Manu Sporny: 3 options. 1) people implementation. 2) Affidavits of promising to use it, such as with JSON data model., and 3) remove from spec which forces us into another CR which will take 3-4 weeks minimum.
… the best option right now is identifying implementors and having them speed up

Orie Steele: https://github.com/w3c/did-test-suite/pulls

Brent Zundel: we can take a few more mins to discuss if needed

Orie Steele: ^ there are a lot of open PRs

Shigeya Suzuki: https://github.com/w3c/did-test-suite/issues/132

Shigeya Suzuki: I created a new issue about descriptive text for implementations.
… we may need to ask implementors to update their descriptive text.

Manu Sporny: question for Shigeya: what is the description for?

Shigeya Suzuki: There are inconsistent uses of the summaries of the tests in the report.
… that would better categorize the outputs of the reporting tool

Manu Sporny: I think that’s something that the test suite curators can add as metadata

Markus Sabadello: For the Universal Resolver, we are including the file name but we could include the name inside the test submission

Manu Sporny: The Universal Resolver is submitting DID methods that you didn’t author, but you are submitting requests for multiple other live DID methods.

Markus Sabadello: It depends somewhat on the DID method type and how it is implemented.
… most of the time it is a Docker container that is running code from the DID method authors
… so in that case, the Universal Resolver is running different code

Manu Sporny: I would say it meets the bar for an independent implementation. Does anyone object?

Drummond Reed: I agree with manu, those are separate implementations

Markus Sabadello: Ironically this sometimes could mean that for certain DID methods the Universal Resolver could be resolving through different resolution paths.
… so those might not be considered two implementations.

Manu Sporny: The only time we need to be careful about this is when we have a normative statement with only two implementations and one of them is the Universal Resolver.
… for example where a test shows only the Universal resolver and Ceramic may be suspect
… but we will check that

2. MIME Types

Brent Zundel: We have an IANA Considerations section in DID Core
… and we specify MIME types there that we have had issues getting registered with IANA due to containing two plus signs
… option #1: remove all media types from spec and hope there is no impact
… option #2: we only register did+json
… option 3: only register one MIME type and write IANA

Manu Sporny: We haven’t sent IANA a “we really need you to act” email
… I will avoid saying anything else

Michael Jones: Normally when you ask IANA to register and there’s a problem, the experts say what to do
… the double plus issue is understandable - with the JWT work we changed one plus to a dash
… why aren’t we doing that

Manu Sporny: IANA asked us to write up a spec proposing support for two plus signs
… we wrote up that spec a year ago
… there was a robust mailing list discussion
… but then it died down and there was no decision
… even though the feedback was mostly positive
… and ironically the feedback was that a spec was not really needed to register
… so we have a couple options
… first we could go back and just ask to register, pointing to the past experience
… RE “why aren’t we changing one plus to a dash”, the JSON-LD MIME type already has a plus, so JSON processors would not recognize it if that was changed.

Michael Jones: The way to force the hand in the IETF process, we just ask for a preliminary registration
… either they will register it or they won’t
… if they register it, we’re done
… if not, then we can appeal
… and ask for full registration

Manu Sporny: Ok, we will go forward with that approach, which means we don’t change anything in the spec

Michael Jones: In the comments, explain what happened, citing the spec you wrote, and say, “W3C as a cooperative standards org requests your help in resolving this”.

Manu Sporny: Ok, we’ll do that.

Brent Zundel: Good. Thanks Mike for the input.
… any other input about MIME types?
… based on those last two topics, we will NOT have a special topic call this week.

3. DID Core issues and PRs

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

Brent Zundel: my hope as we go through these, my hope is we can get volunteers

3.1. All appendix sections needs to be cleaned up. (issue did-core#728)

See github issue #728.

Manu Sporny: some of the PRs have turned into challenges even though they are all editorial
… .so it may take some back-and-forth on each of these
… if you have concerns with the language, please make concrete recommendations on new language

3.2. Diagrams need SVG and detailed description

See github issue #625.

Manu Sporny: using the GitHub change tool would help the most

Markus Sabadello: I should have done this much sooner. So far I haven’t been able to.

Drummond Reed: I did the diagrams with an OpenOffice app, but I can’t get them converted to SVG.

Shigeya Suzuki: Please let me know exportable formats, then I may help.

Brent Zundel: if folks can help, please offer

3.3. verification method IDs MUST contain a fragment

See github issue #708.

Markus Sabadello: Thanks, Shigeya, I will share my source docs and ask for help

Manu Sporny: George Aristy from SecureKey would like to have normative statements about the structure of DID URLs
… but I don’t know as the WG could agree on anything more than a valid URI
… however it would be worth a call with George to understand

3.4. FAQ Question: Can the DID Controller of a DID Document be updated/changed after the DID Document has been registered? (issue did-core#719)

See github issue #719.

Brent Zundel: PR that addresses this: https://github.com/w3c/did-core/pull/754

3.5. Examples might be out of date

See github issue #734.

See github pull request #748.

Drummond Reed: I submitted PRs on that and the next issue; they just need review

Orie Steele: I removed the Ethereum address example
… there is still a potential issue with having a public key multibase example first
… so I hoped that providing several examples would solve the problem

Brent Zundel: a link to the PR is in IRC so please review

3.6. When is the DID URI getting constructed

See github issue #729.

Manu Sporny: this just requires me to write some text
… if someone else wants to take a look at that, please do

3.7. Proving Control sections are wrong

See github issue #583.

Manu Sporny: The PR is in and has been merged, and I am waiting for Amy to see if it addressed her concern

Brent Zundel: There are currently 15 open PRs that are all editorial
… I encourage WG members to go in and review and approve (or improve)
… the editors rely on our review to know when they can go forward with a merge
… thank you everyone for your hard work; it is a pleasure to work with you
… NO SPECIAL TOPIC CALL this week
… next meeting is June 1