DID WG Telco — Minutes

Date: 2021-06-29

See also the Agenda and the IRC Log

Attendees

Present: Daniel Burnett, Charles Lehner, Adrian Gropper, Shigeya Suzuki, Manu Sporny, Markus Sabadello, Ted Thibodeau Jr., Orie Steele, Drummond Reed, Kyle Den Hartog

Regrets:

Guests:

Chair: Daniel Burnett

Scribe(s): Orie Steele, Manu Sporny

Content:

1. Agenda, reminders

Daniel Burnett: meeting reminders, IANA, implementation feedback, did rubric status, did core issues and PRs
… Skipping introductions
… No special topic call
… Meeting on july 6 is canceled

2. Status of Implementation Feedback

Daniel Burnett: manu summary?

Manu Sporny: https://w3c.github.io/did-test-suite/

Manu Sporny: the current status on implementations is available at the URL
… the report is auto published

Manu Sporny: See Status of implementations:

Manu Sporny: the mailing list email covered the status, see the link
… we need to make some decisions, see the summary, we will need to make some proposals / resolutions at the end of CR/2
… overall we are in good shape…. it can only get better from here… we appear to be able to get to REC.
… we good number of implementations, covering a good amount of features
… CR2 ends in .5 month.

Daniel Burnett: questions?
… are there any areas where we need to push?

Manu Sporny: shigeya answers are good… some folks feel they have implemented things, some debate over how the implementations are proved….
… some need to coordinate on open concerns / issues
… implementers need to make changes, assertion is test suite is good

Shigeya Suzuki: its good now, but there are modifications to the rendering needed to show parameters before end of CR

Manu Sporny: thanks for volunteering to do that

Daniel Burnett: some minor discussion remains, any questions?

3. IANA Discussion

Manu Sporny: Murray got back to us – https://lists.w3.org/Archives/Public/public-did-wg/2021Jun/0009.html

Manu Sporny: they got back to us…..
… yay…
… eta 1 year before its done.
… we can’t register the media type in time… but they are opening a WG called mediaman…
… the WG won’t start for months or finish for a year… so we can’t register our media type…
… the suggestion is to leave it hanging, and try to fix it later…
… there are 18 implementations of the media type… so it seems like it won’t break things…
… we should note that registering the media type will be done, once the mediaman wg has an official position.
… we can put it out as advisory and go to rec

Daniel Burnett: they can still argue against 18 implementations…. this won’t effect our process, but we should not assume the outcome we want will happen.
… others should participate, if you want the outcome.
… questions

4. DID Rubric status/publication

Manu Sporny: orie: I believe the rubric is developing.

Orie Steele: I will continue to provide feedback on some methods to that rubric. There is also the rubric podcast thing, that will elaborate on the rubric and things described there in. I can see progress, nothing more official though.

Manu Sporny: what orie said
… they are producing content, and are aware of the september deadline

Daniel Burnett: we have had a conversation about it… you cannot assume that folks will say yes… we will see what we have.
… questions?

5. DID Core issues and PRs

Manu Sporny: regarding PRs…

Manu Sporny: This one is ready to go, I just need to merge it – https://github.com/w3c/did-core/pull/764

Manu Sporny: charles?

Manu Sporny: Charles added this one – https://github.com/w3c/did-core/pull/771

Charles Cunningham: adding descriptions to diagrams, as requested in issue 625

Manu Sporny: this is one of the major outstanding things
… this really helps, thank you

Markus Sabadello: See issue https://github.com/w3c/did-core/issues/625

Daniel Burnett: excellent example of how these should be done, you just imagine that you are describing the thing over the phone…
… they are not hard, and a good opportunity for new contributors

Manu Sporny: here are the issues that remain: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+-label%3Adefer-v2+

Manu Sporny: we are down to a beautifully small number of issues
… wonder to almost get to nothing… 2 waiting on michael herman
… 3 waiting for confirmations, then 3 remaining issues
… 2 real issues, linking to use case, easy….

5.1. External security / crypto review

See github issue #768.

Manu Sporny: the big one is from mark from the http wg, asking for an external security review…
… Mark co-chairs http wg at IETF… he is asking us why we have not asked IETF or CFRG to do a security review
… we also asked TAG
… folks at IETF are asking why there is no sec review
… suggestion is to do it, even though it will annoy folks…
… still they may have comments
… I asked mark if he expects us to engage with CFRG, and the security area

Drummond Reed: I was going to mention the ones that we are waiting on michael for, we have waited that out
… how long will a security review take?

Manu Sporny: 1 to N months to complete

Daniel Burnett: we have done what we are required to do by process
… while sec reviews are good, its not appropriate for it to be a gating factor

Manu Sporny: agree, it should not be a gating factor for getting to REC, its a politics and optics issue
… its important to work with CFRG to address the concerns folks are raising.
… the responses from CRFG have not been great…. we will go into a maintenance mode, we would like to start engaging on these items…
… when the WG is recharted / reconvened we can implement feedback gathered.

Drummond Reed: I like that

Daniel Burnett: part of the process has been implementations, its important to convey that this is not an opportunity to restart our process
… we are continuing our existing process, and look forward to addition reviews and feedback.

Manu Sporny: I will take an action to draft some language, and can put it to the group to review

Daniel Burnett: reminder that we have a higher bar regarding consensus than IETF, we are way beyond “rough consensus and running code”
… folks have known about this for some time
… this will come up as we proceed to the next phase

Manu Sporny: I have the ball on a draft

6. Test suite

Daniel Burnett: anything else for issues?

Manu Sporny: if we have time, would like to talk about test suite

Manu Sporny: We have 3 questions the group needs to address here: https://lists.w3.org/Archives/Public/public-did-wg/2021Jun/0012.html

Manu Sporny: #1: Are the hl, relativeRef, and service implementations independent enough?

Manu Sporny: question 1 are hashlink, relative ref and service independent enough
… kyle i think you did this implementation?
… orie may have done one, markus may have done one…

Markus Sabadello: I think we have an implementation of this, the way it is getting counted may be to blame
… hl, relativeRef, service … we implemented them… maybe the test suite is testing the syntax, and not reporting the results fully?

Kyle Den Hartog: basically yeah… while we are not technically testing dereferencing, we have 2 implementations behaving similarly
… regarding did params, its hard to tell what is being tested… I was mostly looking at validation of the DID URLs…

Orie Steele: IIRC, we each tackling the way we’re testing these things differently – writing implementation for dereferencer, or DID Method implementation, two places where they show up, not counting them in the same way, to kyle’s point, what are we testing – tend to agree with kyle, wrt. dereferencing, we just can test that DID URL conforms to syntax and output conforms to data.
… As long as you’re providing input/output… input conforms, output conforms, not counting them consistently.

Manu Sporny: agreed, this would appear to be mostly a copying issue
… we can copy them from 1 place to another, to make them show up perhaps.
… we might consider this easier to fix by just copying data from 1 place to another.

Markus Sabadello: Our Universal Resolver report with these parameters: https://github.com/w3c/did-test-suite/blob/main/packages/did-core-test-server/suites/implementations/universal-resolver-identifier-tests.json

Manu Sporny: i think hl, relativeRef and service have been implemented

Shigeya Suzuki: the “it” blocks may not be covering the test suites, if the output is not in the table, its likely the statement does not run
… so its possible we are not actually testing the data.

Kyle Den Hartog: I don’t want to copy did params into our did implementations
… I can check the syntax, would that work?

Kyle Den Hartog: sounds good, I’ll update those files

Manu Sporny: action is for implementers for features, markus and kyle, look at your files, and figure out how to get your tests to show up.

Markus Sabadello: it would be cleanest to submit implementations for the dereference suite and the implementation suite
… show that you can both parse and dereference

Manu Sporny: i think we are done with q1

Drummond Reed: no objections

Manu Sporny: The second question is … #2: Are we letting the JSON serialization keep unimplemented features?

Manu Sporny: question 2, we seem to need a resolution of some kind…
… datetime, null, integer
… we said all normative features must have at least 2 implementations before we exit CR… we want to keep the data model intact, even though nobody is using them currently

Drummond Reed: I think we want to keep the model intact

Kyle Den Hartog: we can implement it

Daniel Burnett: Yes please !!!

Kyle Den Hartog: Sounds good I can do that

Manu Sporny: as long as those are “real implementations”
… lets be careful

Daniel Burnett: I understand your concern, but remember we are testing the spec… the feature needs to be implemented, the example does not need to be “useable”
… the more complete the tests are the better
… our goal is to demonstrate that someone reading the spec could implement it

Orie Steele: https://did.actor/mike/

Orie Steele: ^ kyle

Kyle Den Hartog: I will try to make our example good

Manu Sporny: +1 to what Kyle just said, that’s the right way to do it.

Drummond Reed: :-)

Daniel Burnett: in response to drummond… folks have built implementations just to allow folks to meet the number… the requirement is not that folks use it, its that feature are implementable when you read the spec.

Manu Sporny: action is on implementers to cover the remaining features

Kyle Den Hartog: Sounds good, I should be able to get those in this week

Manu Sporny: Last question is #3: What are we going to do with deactivated, nextUpdate, and nextVersionId?

Manu Sporny: what are we going to do with deactivated, nextUpdate, and nextVersionId
… I know some folks think they implemented these

Kyle Den Hartog: I have seen evidence that they have been implemented
… but they appear not to be reported

mnau: this appears to be different than the syntax tests
… we appear to need more functional tests for did methods that support this

Markus Sabadello: these tests happen in did resolution

Manu Sporny: Yes, Markus is correct, apologies, I misspoke.

Markus Sabadello: you must submit reports for a resolver, NOT a did method
… some potential confusion over where did methods vs resolution vs dereferencing get tested
… maybe a shortcoming of the test suite

Kyle Den Hartog: https://github.com/w3c/did-test-suite/blob/674a122d49da1ce80ee677412ab4faf7d118cac2/packages/did-core-test-server/suites/implementations/dereferencer-3-3box-labs.json#L25

Markus Sabadello: there should be enough

Kyle Den Hartog: you can see the implementation report,

Drummond Reed: That would imply that the WG members know math ;-)

Daniel Burnett: this will take extra time to resolve
… please continue to work on issues and mailing list

Manu Sporny: +1 to moving discussion to issues/mailing list

Daniel Burnett: we are close

Kyle Den Hartog: Would updated and created be the same for the first publishing?

Markus Sabadello: created and updated can be the same per the spec -> so it’s a bug in the test suite

Drummond Reed: +1

Kyle Den Hartog: it’s not the first publishing :)
… remember next call in 2 weeks

Kyle Den Hartog: Ahh I’m misunderstanding the implementation then. I can go look at his code because I understanding it’s behaving as expected