DID WG Telco — Minutes
See also the Agenda and the IRC Log
Present: Justin Richer, Shigeya Suzuki, Brent Zundel, Daniel Burnett, Markus Sabadello, Adrian Gropper, Michael Jones, Manu Sporny, Drummond Reed, Orie Steele, Ted Thibodeau Jr.
Chair: Brent Zundel
Scribe(s): Drummond Reed, Brent Zundel
- 1. Status of Implementation Feedback
- 2. MIME Types
- 3. DID Core issues and PRs
- 3.1. All appendix sections needs to be cleaned up. (issue did-core#728)
- 3.2. Diagrams need SVG and detailed description
- 3.3. verification method IDs MUST contain a fragment
- 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)
- 3.5. Examples might be out of date
- 3.6. When is the DID URI getting constructed
- 3.7. Proving Control sections are wrong
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
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
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:
Justin Richer: Not sure about SecureKey using
canonicalID, but they do use
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
Shigeya Suzuki: Maybe missing from
Manu Sporny: The only concern should be with
… 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