DID WG Telco — Minutes
See also the Agenda and the IRC Log
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
Chair: Brent Zundel
Scribe(s): Orie Steele, Dave Longley, Tobias Looker
- 1. agenda review
- 2. security and privacy horizontal review
- 3. PR 454 and 455…
- 4. serialization rules
- 5. other PRs need review
- 6. The plan moving forward
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”
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