Verifiable Claims Telecon
Minutes for 2016-11-29
- Agenda
- https://lists.w3.org/Archives/Public/public-webpayments-ig/2016Nov/0025.html
- Topics
- Organizer
- Dan Burnett
- Scribe
- Manu Sporny
- Present
- Manu Sporny, Dan Burnett, Jonathan Holt, Shane McCarron, Drummond Reed, Joe Andrieu, John Tibbetts, Adam Migus, Dave Longley, Gregg Kellogg, Adam Lake, Nathan George, Colleen Kennedy
- Audio Log
Manu Sporny is scribing.
Topic: Agenda review
Dan Burnett: So, first thing up - any comments on the Agenda? One request from Anders to talk about the item he sent to the list.
Dan Burnett: We may timebox that for 10 minutes, before doing spec issues.
Topic: New Participants
Jonathan Holt: My name is Jonathan Holt, I'm a clinical geneticist, work in biomedical informatics and plant and animal genomics. I work on the FHIR HL7 standard among other things. I am board certified in internal medicine, clinical genetics, and preventative medicine. I'm also a fellow in the American College of Medical Genetics and Genomics (ACMG). I'm very interested in verifiable claims and how it might impact the organizations and communities in which I'm involved.
Topic: New Location for Specs
Dan Burnett: Review new location of data model spec https://opencreds.github.io/vc-data-model/
Dan Burnett: And use cases https://opencreds.github.io/vc-use-cases/
Dan Burnett: We've moved the specs to different Github repositories
Dan Burnett: Is there anyone who tried to find them, but were unable to find the new specs?
Manu Sporny: We moved the specs so they would have their own issue trackers. [scribe assist by Dan Burnett]
Manu Sporny: Just really quickly, for those that are new for how we do things at W3C... giving some background on why we moved the specs... Typically the way W3C does things now is you move each spec to its own github repo and it gets its own issue tracker. The trackers are linked off the spec, so you can add issues in the issue tracker. Anyone with a github account can do that, if not, you can send an email to the mailing list and we'll create it for you. [scribe assist by Dave Longley]
Manu Sporny: We did this in preparation for handing these repos over to a WG. We're currently a task force... real work starts when the WG starts, so that's why things have moved around. Other thing to note is that Phil Archer is adding the use cases as a deliverable for the WG. It wasn't before but he thought it was a good idea for this group to keep cleaning up the use cases and incubating. [scribe assist by Dave Longley]
Manu Sporny: Specs haven't changed, they've just got new homes. [scribe assist by Dave Longley]
Topic: Status of W3M Charter Review
Drummond Reed: I joined late so I may have missed it - any update on progress towards becoming a formal working group?
Manu Sporny: Drummond, nothing new, we expect to hear something in the next week or two from W3C Management.
Topic: Call for review
Dan Burnett: We'd like to encourage everyone to review those documents, please do review them over next 1-2 weeks.
Dan Burnett: Any questions or suggestions, please do that. We'll go through issues as we have time on the calls.
Dan Burnett: I will go through issue raising process. Any review is helpful, but any questions/comments are good. If you don't like general direction, we'd like to know sooner rather than later.
Joe Andrieu: In a previous meeting, use cases for CSV on the Web, I'll include that in my review - are there any other exemplars that I may be pointed to? Of other W3C use cases.
Shane McCarron: The digital publishing IG has a really rich use cases document. Let me find the link for you.
Jonathan Holt: I'm on the HL7 side, we use the W3C spec format quite a bit.
Manu Sporny: Could we get some volunteers to get people down on the record for doing reviews? Typically if we ask, it won't happen unless people get on the record to do it. Volunteers to do reviews over next 2-3 weeks? [scribe assist by Dave Longley]
Jonathan Holt: Jonnycrunch volunteers
Joe Andrieu: I will do a review
Jonathan Holt: I will review
John Tibbetts: I'll volunteer for review
Adam Migus: I will do a review
John Tibbetts: I will do a Review
Shane McCarron: Here are some dpub use cases: http://w3c.github.io/dpub-pwp-ucr/index.html
Topic: Brief review of adding issues in GitHub
Manu Sporny: Issues in the issues tracker, as you find them in the spec, please write them in the issue tracker or they will get lost. [scribe assist by Dave Longley]
Dan Burnett: Issues for the spec: https://github.com/opencreds/vc-data-model/issues
Dan Burnett: I had one question about how to use github. Any developer that has used github knows what to do. Every one of you can go to the link above and see the issues.
Dan Burnett: The issues are publicly visible, in order to add an issue, you'll have to create an account. Like any online service today. When you do that, you can go to issue tracker link.
Dan Burnett: In upper right, there is a "New issue" button that you can click on. you will have the ability to create a title and a description. Please do both. Give a thorough description. Then submit new issue, it's that simple.
Dan Burnett: Many of the existing issues have labels, privacy, security, every group ends up with its own process as it goes forward. I know this group has a way in which its been working so far. When you put an issue in, don't label it. That is something the chairs and editors can go through and prioritize. Whether you piroritize or not, we'll have to change the labels. The labels are for people that need to organize the work.
Dan Burnett: The point is, don't worry about the labels.
Dan Burnett: As far as discussion goes, this is something that groups vary on. The mailing lists are archived, typically.
Dan Burnett: We should have much of discussion on issue tracker. For now, go ahead and feel free to discuss issues in issue tracker. Editors will be looking for significant issue that we're concerned that people in the group are not aware of, we may send a reminder to the mailin glist or encourage discussion on mailin glist.
Dan Burnett: We may have different travel schedules, any disagreements.
Shane McCarron: I don't mind relaying the github discussions to a mailing list. That's what web payments does.
Manu Sporny: We haven't been using the issue tracker in this group and that will change as we move into a WG. There are two ways of doing this is that you tie the issue emails to the mailing list. Every time someone comments on the issue it goes to the mailing list. And you can then communicate either way and your comment will come through. What most groups tend to do is to tell the WG participants to go and subscribe, click the "watch" button on the repo. [scribe assist by Dave Longley]
Manu Sporny: Then you will get emails every time someone makes a comment on an issue or does a pull request. Then you can use your email filtering software to put that into a particular folder. [scribe assist by Dave Longley]
Dan Burnett: I suggest we try that first. [scribe assist by Dave Longley]
Manu Sporny: The problem with that is that it excludes people that are'nt on the calls and don't know that they are suppose to be doing that. [scribe assist by Dave Longley]
Shane McCarron: Make it part of the working group instructions
Manu Sporny: We have some people that will be excluded from those conversations and they may have things to say. On the mailing list ... we have 150 people, not all 150 of them will sign up for the issues, when there is a bunch of discussion happening in github, which is the downside. [scribe assist by Dave Longley]
Manu Sporny: Some groups prefer that and others like opening it up. [scribe assist by Dave Longley]
Manu Sporny: It's a good practice that saves the editors a lot of time. If you're going to do a solid review of the specs, please go through the issues first before adding new ones. [scribe assist by Dave Longley]
John Tibbetts: In addition to reviewing the current documents, do we want to be familiar with the current issues before adding issues?
Dan Burnett: I agree that that's helpful, if you have any concerns/ questions whether your issue has been raised or not, please enter it. [scribe assist by Dave Longley]
Dan Burnett: I'd rather not lose anything important. [scribe assist by Dave Longley]
Dan Burnett: If you want to watch all new issues, or if we end up tying github to the mailing list, it's very easy to drown in emails.
Dan Burnett: The email traffic from github can be very extensive. Be prepared to filter, even with filtering it can become tricky. As opposed to issue creation/deletion. If for some reason people are missing out on discussions, we can make sure they get included. Drowning in emails is a problem
Manu Sporny: Will you cover how to process issues, we don't make discussions on github unless they are editorial -- we have a call and get consensus to make sure everyone agrees. [scribe assist by Dave Longley]
Dan Burnett: I wasn't going to make that statement yet, I didn't want to get ahead of the chairs discussing process. [scribe assist by Dave Longley]
Dan Burnett: I wasn't going to make any assumption about any resolutions today. [scribe assist by Dave Longley]
Dan Burnett: Absolutely, the intent in all W3C groups and it should be in any standards group, is to determine consensus. [scribe assist by Dave Longley]
Dan Burnett: There is something written in the CG on how you declare consensus, usually groups vary a bit, but whenever there is a clear disagreement, you don't have consensus, and then you go into more substantial discussion.
Manu Sporny: We tend to bring important decisions to the calls, binding decisions are usually made on calls.
Dan Burnett: Agree that if there is disagreement, disagreement will happen on the call.
Dan Burnett: That's the way disagreement is usually handled. Disagreements from people in different timezones also have to be considered.
Shane McCarron: You can get lost in the morass of emails on github discussions. Coming in late with a strong objection is not a good way to make friends. You should monitor things you feel strongly about. A lot of WGs decide on a Call for Consensus process, decisions made in a telelconference go out in a 2-5 day consensus so if people miss the meeting, they can still object.
Dan Burnett: Good point, and is why I don't want to make the statement about consensus yet.
Dan Burnett: Any other questions?
Dan Burnett: About Pull Requests - PRs are the way to propose specific changes to the document. You edit the document and push that edit up such that it can be reviewed, including by the editors, once that's done it can be applied to the document. The editors will encourage people to do that. I know some people haven't done that before.
Dan Burnett: The other two chairs have asked for that, what I'm going to suggest is that I'll give a brief overview along with pointers as to what to do. There is material people can read in advance, what people can look at. If we have a discussion today, if I ask for a PR, don't worry, we'll cover it, we'll get to it.
Manu Sporny: If you can't raise an issue for whatever reason (your company may restrict access to github), then send an email to the mailing list. Propose text to change, or just raise an issue that way, and an editor or someone will get it into the github tracker. The best way to get your changes in, however, is via a pull request (PR) to github; it's the easiest way for the group to get your specific changes into the spec. If you have a vague concern about [scribe assist by Dave Longley]
Dave Longley: Some text in the spec, the likelihood of getting your issue resolved is low because you're not being specific enough. Please be specific about what you want changed and the new text. Pull requests are preferred if you can do it.
Dan Burnett: We're still fairly early in the process, there is a point in the process, not now, much later, where it's more likely that there will be a requirement that changes be precise. That's reasonable when you have a document that's getting closer to finalized.
Dan Burnett: Specificity helps.
Topic: Nesting Signatures with JWT
Dan Burnett: If there is no clear resolution on these issues, it may require more thinking for people. For today, since we're just getting started, issues freshly migrated, we'll start at the beginning.
Dan Burnett: Initial discussions and thoughts and see where we get.
Dan Burnett: https://github.com/opencreds/vc-data-model/issues
Dan Burnett: Skipping issue from Anders since he's not on the call.
Dan Burnett: Starting with issue #1
Dan Burnett: Nesting Signatures with JWT
Dan Burnett: There is a concern that nesting multiple signatures with JWT results in an exponential increase in the amount of data that needs to be stored. Each "envelope" needs to encapsulate the entirety of the signed data as a base-64 encoded blob. This is an issue for endorsements, counter-signatures, and M-of-N signature schemes. How will nested signatures be supported using JWTs?
Manu Sporny: We've had pressure to try and figure out how the VC model works with JWTs. This is a healthy good pressure to have because there's a lot of libraries out there for JWTs, lots of thoughts put into them, etc. We have some requirements that makes using JWTs a bit more challenging though. That's where this issue came from, people asked if you can put VCs in a JWT... and we said, yes, for basic ones it's pretty clear. The issue is using JWTs with higher [scribe assist by Dave Longley]
Dave Longley: Order protocols. If you have a protocol that does multisignatures, if you have one org that signs a claim and you want another to countersign it, like a notary or the gov't to counter sign a state-sign driver's license, etc. ...
Manu Sporny: It's simple with Linked Data Signatures, you just tack on another signature. [scribe assist by Dave Longley]
Manu Sporny: With JWT, you have to base64-encode before you sign .. and that envelope/encapsulating format needs to stick around. [scribe assist by Dave Longley]
Manu Sporny: So you can't as easily do that. [scribe assist by Dave Longley]
Manu Sporny: Unfortunately, it's a fairly open question ... and the hope is to gather some thoughts in the github issue. [scribe assist by Dave Longley]
Manu Sporny: People could propose how to do it, or we could decide not to support certain schemes because it's too hard to do with JWTs. [scribe assist by Dave Longley]
Jonathan Holt: Uport solved this by using IPFS, wrap JWT around the content... data model for uport, base64 encoded JWT, that entire idea, you can WoT counter-sign assertions being made.
Gregg Kellogg: It would be useful to capture discussion in the issue; perhaps after the fact?
Dan Burnett: That's a good thing to add into the issue.
Jonathan Holt: That may be a good model to use - I used open source library for uport, hash of the document, which could be stored anywhere, it's an elegant way of nesting claims.
Dan Burnett: We should figure out how we capture discussion, if we make a decision, consensus decision will be recorded. As far as discussion, if there is an obvious/simple comment, that will be put in there. Significant comment would be good for person that made the comment to put it in there. I encourage JonHolt to put it in the issue.
Dan Burnett: This is an issue that has to do w/ JWTs, but depending on how it gets resolved for JWTs, it could have an impact on general data model structure. For example, if a wrapping structure needs to be created, we might need to create a wrapper that other syntaxes would use as well, even though it may be not as efficient to them.
Dave Longley: I think we should try to specify something in the JWT, even if it seems that it's not optimal. We could let people decide if they want to use that technology to solve the problem. They're willing to deal with those inefficiencies. I don't think we should bloat schemes when the problem can be solved more elegantly. We may want to separate data model from signature from container. People should be able to use solutions that work best for them. Obviously, we don't want to fragment the space. There may be different signature schemes that work in different scenarios.
John Tibbetts: I think it's mostly been answered by Dave. Is there a requirement that all of the signature schemes have the same capabilities. JWTs are fine for flat spaces, but they don't handle a number of other use cases. Is that something we can commit to doing? JWTs are fine for simple signature schemes, can we say that?
Manu Sporny: Let me try and respond in reverse order. We can say anything we want as long as the group has consensus around it. Maybe we'll say that JWTs are fine for flat data, graphs of data or endorsements are difficult -- we could say that. Or as Dan pointed out, we could try and extend the core data model so that you can do things with JWTs easily, etc. One of the issues with going over this issue right now is that we haven't had that discussion. The [scribe assist by Dave Longley]
Dave Longley: Discussion today is about getting some of these options on the table. Dan to respond to you, I think we want to consider all of these options, we have to do our due diligence to make sure we cover every approach we can think of; expanding core data model isn't off the table. I do agree with Dave Longley that we shouldn't bloat the core data model if there's a problem with an existing technology on the table, so it's a balancing process.
Manu Sporny: To respond to what Jon said, it is true that you can do hashes and store them in IPFS and do content-addressable pointers to these data structures. Also keep in mind that a lot of these protocols have to do with sending the real data from A to B and there are regulations that don't allow you to store this on IPFS. [scribe assist by Dave Longley]
Manu Sporny: Hashing the document and putting the data somewhere else I'm familiar with, but it won't work for some use cases that have regulatory requirements. In those cases, I don't think we can do what you're suggseting, but that said, I'd love for you to expand on what you said and talk about which libraries you were using and what the process was, etc. [scribe assist by Dave Longley]
Jonathan Holt: https://uport.me/library/pdf/whitepaper.pdf .
Manu Sporny: Maybe we can do what you've said or it will give others ideas on how to proceed here. [scribe assist by Dave Longley]
Manu Sporny: Fundamentally, this isn't a problem with Linked Data signatures. The whole reason we're having this discussion is because there's tech deployed that doesn't work in these use cases elegantly, but we can still say "here's how you can solve them" -- and talk about pointing things at IPFS and so on, but that solution is more difficult to implement and deploy than using a LD Signature. The LD Signatures don't have as much library support and haven't [scribe assist by Dave Longley]
Dave Longley: Been through standardization process, so those are the downsides there.
Manu Sporny: We should get all this down on the issue and that will help us make some good progress. [scribe assist by Dave Longley]
Dan Burnett: Any other comments or thoughts? [scribe assist by Dave Longley]
Dave Longley: None
Manu Sporny: We should get folks from the JOSE/JWT WG to give us their opinion on this and get them on the call and tell us how they'd solve the problem with JWTs. [scribe assist by Dave Longley]
Manu Sporny: We have been criticized rightly for saying JWTs don't work for things without having people specifically from that group on the call trying to work through the problem with us. [scribe assist by Dave Longley]
Dave Longley: "Don't work" is probably a loaded phrase
Jonathan Holt: I may be mistaken...looks like it is an array of JWTs, not nested.
Manu Sporny: Once we've gotten this documented and the issue played out, we should contact them and get their input. [scribe assist by Dave Longley]
Dan Burnett: Thanks for working through this issue, things will smooth out soon.