DID WG Telco — Minutes

Date: 2020-11-24

See also the Agenda and the IRC Log

Attendees

Present: Daniel Buchner, Shigeya Suzuki, Brent Zundel, Justin Richer, Dave Longley, Manu Sporny, Jonathan Holt, Kyle Den Hartog, Kaliya Young, Orie Steele, Markus Sabadello, Drummond Reed, Ted Thibodeau Jr., Tobias Looker, Wayne Chang

Regrets:

Guests:

Chair: Brent Zundel

Scribe(s): Orie Steele, Dave Longley, Tobias Looker

Content:

Daniel Buchner: Note: the equivalence PR has been updated in accordance with the consensus from the special topic call, and is ready for final review/merge

Brent Zundel: welcome to the Asia friendly time the week of thanksgiving

1. agenda review

Brent Zundel: begining with security / privacy report
… . then PR454
… then we will cover the plan for covering issues for CR
… issues have been prio’ed, we will go through them

Daniel Buchner: PRs ready for merge

Daniel Buchner: I would imagine those are the highest pri?

Daniel Buchner: just a possibility

Brent Zundel: we will cover 454 and other PRs

2. security and privacy horizontal review

Brent Zundel: deliverable that needs to be finished for the security and privacy horizontal review
… we need to hear concerns, so we can address and move forward
… we had volunteers for it, what is the status?

Jonathan Holt: we met last Monday, and hammered out discussion points.
… unsure of the next steps.

Drummond Reed: unsure of status

Jonathan Holt: we need changes accepted and threat models to be discussed by the wg

Drummond Reed: since its security and privacy, we need the security expertise for the final questions

Brent Zundel: looking for more volunteers for the security section

Jonathan Holt: we discussed wanting to capture security issues in an ongoing way

Brent Zundel: primary concern is completing the document, but additional issues can be tracked in github
… orie to try and help, moving on…

3. PR 454 and 455…

See github pull request #454, #455.

Brent Zundel: status update?

dlongely: we are waiting for a response from mike jones regarding the suggestions for adding a note to the PR / regardign @context in the JSON representation section.
… unsure if he is still objecting

Brent Zundel: I will ping him again

Markus Sabadello: after merging 455 and then 454 we still need to revisit the exact terminology… lots of different properties type to hammer down.

See github issue #463.

Markus Sabadello: feedback welcome

Brent Zundel: other PRs that need to be discussed in this meeting?

4. serialization rules

See github pull request #469.

Manu Sporny: too note the new PRs 469, needs review
… this is regarding concrete serialization rules
… daniel buchner raised another PR regarding equivalence properties
… please review PRs

See github pull request #431.

5. other PRs need review

Brent Zundel: lots of PRs need review, moving on…

See github pull request #469.

Justin Richer: regarding 469 and follow ons, it is overly pedantic, but it needs to be… and also when considering other representations… it needs to be really spelled out here.

Justin Richer: engineers are the worst runtime environment possible….

Jonathan Holt: regarding the cbor section, i like it being pedantic, still struggling with the number types
… hard to map CBOR to the ADM without number types in the ADM

Manu Sporny: we have a number in the ADM, and they should map to CBOR

Jonathan Holt: double is not specific enough… these types are not precise enough for double vs float.

Brent Zundel: next topic, moving forward plan.

6. The plan moving forward

Manu Sporny: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+label%3Apre-cr-p1

Manu Sporny: as mentioned, we have prioritized issues…
… the issues are P1, P2, P3

Orie Steele: P1 required to solve before CR

Manu Sporny: P2 is good idea, P3 is not a blocker for CR
… we are going to start going through issues in priority order
… at some point, during P2 we will probably make the call to go to CR
… thats it, we will be processing issues to get closure on things…
… one of the options will be to defer the issue… if its inactive, we can defer to the next version of the spec.
… on an issue by issue basis, we can defer things.

Brent Zundel: sounds good, any questions from the group
… lets jump in

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

6.1. P1 Issues

Manu Sporny: lets do P1 sorted by least recently updated
… running the issues
… first one is instant did resolution
… I think this is …

Daniel Buchner: my pr 431 will resolve this
… this allows for slow blockchains that take a really long time to be useful

Manu Sporny: sounds like we are almost through this one
… moving on to the next one
… current language regarding cannonical dids increases signature complexity

Daniel Buchner: the current spec text can cause harder validation issues
… this is also be fixed by the other PR

Manu Sporny: this issue is also blocked by 431

Tobias Looker: agree with dbuc’s assessment

Manu Sporny: next one is Ping horizontal review

Brent Zundel: we need this done, if you have any security expertise, please help

Manu Sporny: we are blocked from going to CR until this is done
… CBOR “should not be marked at risk”
… update?

Jonathan Holt: I have made updates to the PR, we still need to handle unknown properties in CBOR… still WIP, and semi blocked by numbers

Manu Sporny: we are waiting on PR 420 to be merged, and marking it at risk

Jonathan Holt: I am asserting it should not be marked at risk

Manu Sporny: marking it at risk is telling people that the section may change

Jonathan Holt: i though we settled this with the ADM

Brent Zundel: at risk does not mean the section is lacking, it means if this section changes during CR we want to be able to change it without going through another CR

Manu Sporny: we could mark them all at risk, if we mark them all at risk we our CR attempt will get denied

Drummond Reed: Yes, marking an entire spec at risk won’t work

Orie Steele: Why aren’t we marking everything at risk? We have seen several orders of magnitude more activity on CBOR than JSON, why not mark all the representations at risk?
… marking at risk is a way of conveying stability
… this is us trying to get weak sections into CR <- edited by me

Jonathan Holt: I have tried to get CBOR supported, and tried hard to deal with the ADM
… i think CBOR should not be marked at risk

Manu Sporny: suggest we move on, we know the PR needs to be merged before the issue can be addressed
… horizontal review / tag
… we offered to meet to go over stuff…

Brent Zundel: this issue and others will stay open until horizontal review is complete

Manu Sporny: PR454 will address unknown properties
… moving on
… ability for a DID method to be known as more than…. addressed by 431 as well
… define serialization for numbers / dates /other properties… this is in progress, justin_r?

Justin Richer: yes, this should be addressed, and the language is changing in a way thats good.
… we should be defining types, not serializations
… and we are doing that in the representations sections
… so this should be solved soon, see 469… we are doing a good job of splitting the types and representations

Drummond Reed: +1 to a datatype on URI

Manu Sporny: this should be addressed when the related PRs are merged?

Jonathan Holt: will we handle big int / big float

Manu Sporny: right now no, because integers are big ints in the adm… decimal should support float… we would need a demonstration to add support for other types

Kyle Den Hartog: +1 to not supporting them

Dave Longley: i don’t think we should support big int / big float, because some representations cant support those types

Jonathan Holt: I agree they are hard, i guess we will see poor interop for big ints and big floats.

Justin Richer: we already need to consider per field processing, because fields get to define types beyond the ones in the representations
… that said, i agree this is more speculative than concrete… we can always add types later.

Kyle Den Hartog: we have used base64url encoding inside of JSON for proof values… we imagine the base64url bytes would be preserved, and the type would be not a float / big int

Tobias Looker: Our experience with ZKPs is that you only really need Uint8Arrays

Brent Zundel: string values or bytes will be used to handle big int / big floats

Manu Sporny: please add comments to the issue

Jonathan Holt: we have already covered base64 to byte array in CBOR

Manu Sporny: issue 199, there is a PR…

Brent Zundel: we had a PR / PRs for this… the most recent one was the “type” property….
… not aware of solutions to this
… this would be addressed by a property that allows for the expression of a did subject in a did document

Drummond Reed: only on the q too say, the answer to the question is now in the appendix, but its not a full solution

Manu Sporny: when should we expect a PR for this?

Brent Zundel: editors /chairs should discuss the cut off date

Drummond Reed: suggest christmas of closing issues

Manu Sporny: normative statements review
… i think i saw an update from amy, where we have the new list of normative statements
… we need to make another pass through
… would be best if testing folks will go through the list

Orie Steele: I’ll try and go through the list again. The more upfront culling we can do the happier people will be, and the more people that commit the better.
… We’ve got way more normative statements than people willing to write tests, we need more testers.

Manu Sporny: this issue is not going to close until we are ready for CR,

Wayne Chang: where do we find the latest tasks for tests

Manu Sporny: you use the test suite

Orie Steele: The main thing that you want to do is that you want to look through this list for things you can write some tests around. Before you look at the list, you want to say you commit yourself/your company to working on tests.
… You can also say, in that issue where you commit, to say you’re good at writing tests for URLs, or that you want to take certain sections of the spec. Once you’ve stated which issues/sections you’re handling you can start opening PRs to cover those statements. All of those are in the test-suite repo and you should open issues over there if you need help.

Wayne Chang: would there be an objection to transforming normative statements to issues

Orie Steele: We did discuss this an option, it was my initial proposal for every normative statement to have an issue. There was pushback for that to being a lot of process – and if the statements change that’s problematic. Now we just want you call out that you take a block of tests and you should try and own that block. We’ll start there, if that’s not working out well, we’ll go back to opening issues for each statement that won’t get removed until we

Dave Longley: have a test.

Manu Sporny: those are all the P1 issues
… what should we do next?

6.2. some P2 issues

Brent Zundel: lets look at some of the P2s

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

Manu Sporny: there are lots of P2 issues, and many of them are ready for PR
… if you are looking for work, please look at ready for pr, and try to write a pr to address those issues
… looking at the issues, there are key expression clarity issues, general concern regarding sloppiness of key expression…. there are some cases where we want to do restrictions
… there are some reviews ivan did, did spec registries issues, questions about the ADM…
… many of them are how we talk about keys / media types
… these are none blocking, and we could defer a good chunk of P2

Brent Zundel: as you can see, P2… please submit a PR, some of these can be addressed by you!
… editors will help you get it done, just give it a try

Drummond Reed: As the Greek God Nike says, “Just do it!”

Brent Zundel: please no easter eggs

Justin Richer: it’s still exciting when it blows up just less enjoyable

Orie Steele: ^ this was me