DID Working Group Telco — Minutes
Date: 2020-03-17
See also the Agenda and the IRC Log
Attendees
Present: Daniel Burnett, Chris Winczewski, Ivan Herman, Amy Guy, Dave Longley, Manu Sporny, Orie Steele, Yancy Ribbens, Phil Archer, Brent Zundel, Thomas Schwarz, Markus Sabadello, Jonathan Holt, Michael Jones, Joel Hartshorn, David Ezell, Justin Richer, Daniel Buchner, Kaliya Young, Dmitri Zagidulin, Andrei Sambra, Thomas Schwarz
Regrets: Drummond Reed
Guests:
Chair: Daniel Burnett
Scribe(s): Amy Guy, Manu Sporny
Content:
- 1. Agenda Review, Introductions, Re-introductions
- 2. Label etiquette
- 3. Schedule and Arrange Topic Calls
- 4. Registries PR and status
- 5. Issue status check
1. Agenda Review, Introductions, Re-introductions
Daniel Burnett: outlines agenda
… Anything anyone wants to add?
… what is happening aorund the world right now is extraordinary, unprecedented in our lifetimes
Daniel Buchner: Luckily we can still argue virtually on GitHub
Daniel Burnett: we understand that the highest priority for all of us is to focus on health, ourselves and our communities
… we know many of you have issues to deal with that will take your time and at unpredictable moments
… the current plan is to continue the work on a best effort basis
… we understand not everyone will be abel to participate at the levels they have been
… lack of participation at this time is not assumed to mean lack of interest
… our calls will proceed, but maybe slower
… we iwll not push as fast as possible, but continue to make whatever progress we make
Manu Sporny: that’s great.
Justin Richer: about edits, PRs and issue processing, I’d like to ask about timing
… we had rolling 7 day windows, what the official numbers are going to be going forward?
Daniel Burnett: I don’t know there’ll be an official change, but unofficially I’ll let manu talk to it
… absolute windows are not going to work
Manu Sporny: the editors still need to meet and figure out exactly if anything is changing. We’re going to proceed as is, which means keeping the 7 day windows
… the editors have traditionally not merged anything if there’s chance we don’t have consesnus, we’ll still use our best judgement there
… we don’t want to merge something and someone says they were gone dealing with covid19 stuff and everything changed in the meantime
… we don’t want that to happen
… we haven’t heard anyone yet say .. we’ve got notification from a couple of people that they’re going to be unavailable over the next two weeks, but from
… […] other standards efforts. At this point we’re not aware of anyoen who will be completely unavaiable for DID for two weeks that we should consider moving that window
… but if it happens we’ll talk about it as the chairs and editors and as a group and decide whether we need to extend that window
… For the time being, since we’re all mostly remote, we’ll continue as is and use our best judgement
… if it seems like merges are resulting in objection we hadn’t seen before, we’ll probably end up extending those
… The other thing of course is that we hope that the editors and nobody else is going to demand that people focus their attention on issues and push them forward
… That will not be a good work mode
… Give everyone some grace
… on responding to issues, don’t try to rush things through
… then we’ll continue to monitor things to make sure that everyone is able to provide input, nobody is being rushed unnecsesarily and everyone is
… […] the rate that they can
… That’s it
Daniel Burnett: brent, markus?
2. Label etiquette
Daniel Burnett: Do we have anyone on the call [.???]
Markus Sabadello: Sorry I got disconnected :( +1 to everything manu said.
Brent Zundel: reminder to the group of what the labels are for in github
… they are primarily the organsiation and communication mechanism for the editors and the chairs
… the editors can add a label to add their opinion on how they feel the issue or PR should be classified
… the other editors can go in and see that and then we can all know to that small group what we mean, which allows us to triage things and move them forward
… it would be helpful if nobody else really messed with the labels
… when I raised an issue in the VC group I’d try to be helpful and add labels, and get miffed when manu would take my labels off and put his own labels on
… and I realised I wasn’t actually being helpful
… If you have question feel free to ask
… if you’re not an editor or a chair, don’t worry about the labels
Daniel Burnett: any questions?
3. Schedule and Arrange Topic Calls
Daniel Burnett: we had a topic call yesterday, there are people who have complained about doodle polls every week
… there are some pluses and minuses
… the polls produce more of an opportunity for those in Asia for example to find a time that works for them as well
… the chairs do understand that for many people this is a hassle to do this
Michael Jones: I support the doodle polls because it increases participation and for those who are interested dit only takes one or two minutes, which is nothing compared to the calls so it’s a good investment of time
Daniel Burnett: what the chairs discussed as an option for today is it looks like the past few calls have been occurring at noon US eastern time, 5pm Central Europe, 9am west coast US (though that will change) on Mondays or Thursdays
… so the chairs would like to do a straw poll and choose one of the three options
… Monday at noon US eastern
… Thursday at noon US eastern
… Or doodle poll
Daniel Burnett: Straw poll: Monday at noon US EDT, Thursday at noon US EDT, or Doodle poll
Daniel Burnett: This would be on an ongoing basis, whether we continue using doodle polls or establish one of the other times
Manu Sporny: Thursday at noon
Daniel Burnett: Go ahead in IRC
Orie Steele: Thursday at noon
Michael Jones: Thursday noon Eastern
Dave Longley: Thursday at noon
Jonathan Holt: Monday at noon US eastern
Ivan Herman: Thursday at noon
Chris Winczewski: Thursday at noon
Justin Richer: noon thurs preferred, noon monday also ok
Amy Guy: Thursday or Monday both fine for me
Joel Hartshorn: Thursday at noon
Brent Zundel: doodle poll, can’t do thursday at noon
Yancy Ribbens: *day at noon
Daniel Burnett: this is until at least the end of march. Europe changes time at the end of march?
… we may have to revisit then
… thank you, the chairs will discuss and decide what to propose
4. Registries PR and status
Daniel Burnett: https://github.com/w3c/did-core-registry/pull/14
Orie Steele: I want people to be aware of the PR, it’s been up for longer than 7 days
… at this point I feel like it’s done, it’s a decent starting point, it adds some basic functionality which we’ve never had before
Manu Sporny: https://github.com/w3c/did-core-registry/pull/11
Orie Steele: it will help us add properties with confidence to the registries
Manu Sporny: We’re talking about #11
Orie Steele: as the person who is waiting to add lots of properties to the registries, imo much of the registries content is being held up by this PR
… the sooner we can get consensus to approve it the better. If you have changes you’d like to make I’d like to know
… if you have an objection, request changes continuously until your objection is met
… Both of the PRs are ready to merge
… we’ve had the subsequent registries call which was holding back 14 and we had no objections on that call to the content of 14
… similarly for 11 we were holding back on that waiting for reviews
… there haven’t been objections and it has a significant number of approvals
… I don’t know when we’ve had consensus, especially on the registries’ repo because people aren’t regularly visiting that repo to see them
Daniel Burnett: we want to make sure people are aware that these are important and foundational for us to move forward. They’re blocking future work
… Please get comments in right away
… the editors would like to be able to merge this in a couple of days
Jonathan Holt: I have objections about the language
… we talked about this on the separate call. I think it’s a fundamental discussion we have to have
… For future interop with other specs
… I think we need more discussion to think about the security vulnerabilities and thew ay the spec can be more interoperable with other methods
Daniel Burnett: is this something that has to be done before we can merge these, or can it occur after we get these merged?
Jonathan Holt: it’s specific to URL in JSON-LD, and it’s a non-starter for me
Orie Steele: the PR is for the JSON only representation, and the JSON-LD representation, that would be adding registry properties for those representations. I’ve pinged you jonathan for feedback on the cbor representation
… I’d love to see additionally information or context or something regarding cbor
… regarding hyperledger ares scheme, they decided to switch from DID uris to https urls for their specs on a github issues thread I linked previously with a massive amount of debate
… they ultimately decided to switch to https urls specifically because of the web browsability feature
… They chose to migrate to the format we are using
Ivan Herman: the only point is as far as I can see 11 and the discussion we had yesterday has quite a lot of influence on the way 14 is shaped
… so I am fine merging them one after the other but I think we should see the results.. pull 14 is the skeleton of the document itself
… that document must include statements we have agreement on before this can be merged
… or do you want to merge it first and change it afterward? I just want to be sure the document reflects the discussion
Michael Jones: for those who weren’t on the special call we took half the call arguing about what kind of links to use to get to human readable specs, and this was for people not for programs or machines
… my memory is everybody but one person though we could use links that are clickable by humans with browsers to read the specs
… while jonathan would like some additional stuff, offering support is not practical. I think we should merge it as is
… in the future if ipfs etc are resolvable in browsers we’d consider using them, but right now we want developers to find specs
Manu Sporny: Everyone should read the minutes from yesterday (if you have an opinion on this and weren’t there): https://www.w3.org/2020/03/16-did-minutes.html
Manu Sporny: just pointing out minutes from yesterday, if you were not there and have an opinion, read those before jumping in
… orie, I think we should hold a tiny bit on 14 because some of the consensus decision we had from yesterday may impact the language
… I may modify the language to apply the decision we had yesterday
Jonathan Holt: in short allowing for URI allows a DID URL being the source of the registry and I think it allows for more secure robust framework
… regarding the cbor stuff, has anyone read my whitep aper at rwot? I wanted feedback to push that forward, would be appreciated before making PRs
Orie Steele: jonathan_holt, please open issues or comment on PRs. if you want reviews from this group.
Orie Steele: i’m happy to review on an issue
Daniel Burnett: right now there’s not overwhelming support for jonathan_holt’s position. that’s going to leave me and the chairs to suggest merging and continue the discussion afterwards
… think really carefully about what really needs to hold up the work at this point
5. Issue status check
Daniel Burnett: https://github.com/w3c/did-core/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-asc
Daniel Burnett: this is a walkthrough of our standard issues
Orie Steele: jonathan_holt https://github.com/w3c/did-core-registry/issues/5 feel free to ask for a review on this issue.
Manu Sporny: in the did-core spec there were a number of PRs that need reviews, please review those
Daniel Burnett: going through to see what the status is
Daniel Burnett: https://github.com/w3c/did-core/issues/176
Daniel Burnett: first I see is 176
… selfissued?
… the next 5 are assigned to you
Michael Jones: this is one of a set of things where most of them should be removed
… statements that are not actionable
Daniel Burnett: sometimes removing things are appropriate, sometimes it’s not appropriate to remove things because you’re not sure how to word it
… if you really believe that no statement like that belongs in it, make a PR to remove it
… if you believe it should say more, please make a proposal for what it should say
Michael Jones: I’ll re-read it and make a PR
Ivan Herman: a general comment. I understand that the normative text shouldn’t be [??]
… on the other hand having remarks in the text that makes the spec more readable and connect to the reader to other things I find it useful
… as a reader
… the way we can do that is declare certain areas or certain paragraphs as being non normative
… we can put them in NOTES which are automatically non normative
… I would prefer to consider not to remove these things because they can be useful
… but turn them into non normative
Michael Jones: it’s already non normative because it’s security considerations
… I’ll read it and see if I can make it more [??]. My request was not to remove it, but to substantiate the statement
… I’ll re-read it
Daniel Burnett: yes, the security considerations section is a special one. we’ve been encouraged to information in that is even our opinion
… sometimes things which we can not provide a specific action for but we can suggest general thinking about
… it’s still encouraged by the privacy and security interest groups to do that
… they may not all be as perfect as you’d like
… I understand that you may not be an expert. It is helpful to kick things off with you having a concrete proposal so thank you for agreeing to do that
Michael Jones: I’ll try to do them before the next call
Daniel Burnett: https://github.com/w3c/did-core/issues/178
Michael Jones: this one is different
… suggesting that people combine timestamps with signatures may be a nice opinion but if we’re going to say that there should be a statement following it saying for example you could use a, b, c. It’s not actionable, it’s saying do something without saying how
… if someone things you’d want to do that, they should own writing the for example statement
… I don’t know what’s being asked
Daniel Burnett: orie provided an example, someone just needs to add text
Daniel Burnett: https://github.com/w3c/did-core/issues/179
Daniel Burnett: next is 179
… this is a discussion question that you’re asking
… someone may have a response. if you’d like to suggest something that would be helpful
Michael Jones: I think this is bad practice
… you could do notifications if you registered for them, other than polling
Daniel Burnett: I suggest you write what you would propose instead and then create a PR
Michael Jones: I was hoping somebody who wrote this text would speak up and say why they wrote it
… I can do what you suggest but there are probably people who know why this text is there
Daniel Burnett: we’ll see if we get some discussion on it
… expressing alternatives in the issue is more helpful
Michael Jones: I’ll say I want whoever wrote this to speak up and say why, and how I’d do it instead
Justin Richer: just a quick note, process on [??] it’s often very helpful to simply make a PR that takes an action on the text and that can include being like I’m just going to delete this text
… because there’s no justification for it
… that kind of thing can in a helpful way force the group and the editors to look at text they might not have looked at for quite some time, realising we don’t need it any more or we didn’t mean that to be there
… along the lines of what dan has been saying
… it’s really helpful to create a PR against the text, even if it does something potentially destructive, to say if this were gone what does that mean
… ti helps unstick things
Daniel Burnett: thank you
Dave Longley: https://w3c.github.io/did-core/#noitficaiton-of-did-document-changes
Dave Longley: if you go the spec where this is quoted, there are 3 points, the first covers the subscriptions which is the option mike is talking about
… the second option is if subscriptions are not possible
… it might be that this is already covered
Daniel Burnett: https://github.com/w3c/did-core/issues/180
Daniel Burnett: Item 180
Michael Jones: this is nonsensical, in what sense would a DID have a cryptocurrency balance
Daniel Burnett: discussion has started, respond in issue
Michael Jones: the two comments are also not actionable
Daniel Burnett: comment in the issue, and be clear about what you mean by actionable. it looks like there’s more information coming in, perhaps there’s a wording change that will come out of this
Daniel Burnett: https://github.com/w3c/did-core/issues/181
Daniel Burnett: verifiable timestamps
Michael Jones: this is one of about 6 where there’s use of a term that is not defined
… I want someone else to step up and define it, or I’ll delete it
… who knows what it’s supposed to mean?
Manu Sporny: we can .. I don’t think a good way to address these issues is I’m going to delete it and nobody else steps up to explain it. The editors will eventually get to this stuff. PRs that delete content that you don’t understand in the spec are going to result in most likely turmoil and the PR won’t go anywhere and will eat up everyone’s time
… if you feel like it’s a useful definition to have in there or you think other people think it’s useful, take a shot at it, but this is one where we might end up removing it but please don’t threaten to delete spec text that doesn’t make sense to you because more than likely it was put there by someone else for a reason
… all that to say the terminology we’ll get to and the editors are busy in other parts of the spec
Michael Jones: we shouldn’t be using terms that are not well understood and are not defined in the spec
Orie Steele: selfissued you should be opening PRs, and helping to gather feedback on your issues by inviting conversation.
Daniel Burnett: it’s not that we disagree that a term needs to be defined. There are ways you can offer to help. This is a great example of where you don’t understand what it is. We’re trying to keep all of the work be on the editors all the time
… orie has given some examples now. Something that would be helpful now is to look at those and suggest a possible improved definition
… you don’t have to do that, if you don’t this will keep rolling around
… until someone is able to get to it
… when we get external reviews we expect reviewers to tell us what issues are, not necessarily how to solve them
Manu Sporny: +1 to what Orie said… “I don’t understand this, I’m deleting it” is not an okay way to address these issues. “I don’t understand this, I’m going to go and look to see who added the text and ask them and then work to do a PR that addresses my concern w/ their text.” is much more helpful.
Daniel Burnett: but when group members say that, one of the things we’d like to encourage group members to do is also to write something to help
Orie Steele: eventually
Michael Jones: orie, you seem to understand, could you write a sentence in a PR?
Orie Steele: I have 4 open PRs… https://github.com/w3c/did-core/pulls
Daniel Burnett: perhaps in discussion here you can figure out what’s appropriate and one can write a PR
Michael Jones: somebody who understands the intent should write a PR
Orie Steele: selfissued if you could review them, i would be happy to help…
Daniel Burnett: https://github.com/w3c/did-core/issues/157
Orie Steele: registry issues
Daniel Burnett: manu updated with a status comment
… if there’s any more information you can add to help make it clearer
… manu did it
Daniel Burnett: https://github.com/w3c/did-core/issues/154
Daniel Burnett: oliver is not on the call, plenty of discussion
Orie Steele: this is also blocked by the did core registries discussion
… what oliver is objecting to is the jsonld related security vocab and its relationship between [??] progress, please go review the did core registries PRs
Daniel Burnett: thank you
Jonathan Holt: it’s also blocked by the rdf normalisation algorithm that ld proofs use, I’m not getting consistent results
Daniel Burnett: https://github.com/w3c/did-core/issues/151
Daniel Burnett: from oskar
… it’s been assigned to juan who I don’t believe is on the call
… is juan a member?
… what’s needed for this to move forward?
Ivan Herman: he’s not a member
Daniel Burnett: we can’t assign this to him
Orie Steele: assign oliver ;p
Daniel Burnett: is there someone who would like to take on this issue?
… oliver would have been ideal, but he hasn’t been attending recently
Manu Sporny: we’ve been assigning it to the person that raised the issue
… I can do that unless someone feels strongly about taking this
Ivan Herman: oskar is not a member of the group
Daniel Burnett: I’d like the editors to review this issue and decide in your next call who you think might be appropriate to take this on
Daniel Burnett: https://github.com/w3c/did-core/issues/143
Daniel Burnett: assigned to drummond, though he’s not on the call
… this is a bit of a broader issue
… manu and dlongley are responding to each other in this issue
… let’s leave drummond assigned for now but we may need to look on someone else taking this on, eg. orie
… Anything else for today anyone?
… Thank you everyone
… Please do let us know if you can if something impacts your ability to respond in a timely manner, we’ll do our best to accommodate that
… we’re going to be giving everybody more time to respond
… I wish you all good health and safety
… Bye!
Manu Sporny: Thanks all! :) Thanks rhiaro for scribing! :)