W3C home > Mailing lists > Public > public-credentials@w3.org > November 2016

Verifiable Claims Telecon Minutes for 2016-11-29

From: <msporny@digitalbazaar.com>
Date: Tue, 29 Nov 2016 12:32:38 -0500
Message-Id: <1480440758069.0.25267@zoe>
To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Manu Sporny for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:


Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

Verifiable Claims Telecon Minutes for 2016-11-29

  1. Agenda review
  2. New Participants
  3. New Location for Specs
  4. Status of W3M Charter Review
  5. Call for review
  6. Brief review of adding issues in GitHub
  7. Nesting Signatures with JWT
  Dan Burnett
  Manu Sporny
  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

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 
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 
Dan Burnett: And use cases 
Dan Burnett:  We've moved the specs to different Github 
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 
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: 

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:  
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 
Dan Burnett:  We may have different travel schedules, any 
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 
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 
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 
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 
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 
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 
Dan Burnett:  Initial discussions and thoughts and see where we 
Dan Burnett: https://github.com/opencreds/vc-data-model/issues
Dan Burnett:  Skipping issue from Anders since he's not on the 
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 
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 
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 
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 
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 
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.
Received on Tuesday, 29 November 2016 17:33:12 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:32 UTC