W3C home > Mailing lists > Public > public-credentials@w3.org > January 2017

Verifiable Claims Telecon Minutes for 2017-01-24

From: <msporny@digitalbazaar.com>
Date: Tue, 24 Jan 2017 12:19:30 -0500
Message-Id: <1485278370018.0.13512@zoe>
To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Nate Otto for scribing this week! The minutes
for this week's Verifiable Claims telecon are now available:

http://w3c.github.io/vctf/meetings/2017-01-24/

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 2017-01-24

Agenda:
  https://lists.w3.org/Archives/Public/public-credentials/2017Jan/0024.html
Topics:
  1. Agenda Review
  2. Status of Verifiable Claims WG Vote
  3. Use Cases Narratives and Revocation/Privacy
  4. Correlation Analysis and Prevention
  5. Filtering, Focusing use cases
Organizer:
  Manu Sporny
Scribe:
  Nate Otto
Present:
  Nate Otto, Dan Burnett, Manu Sporny, David Ezell, Joe Andrieu, 
  Dave Longley, Nathan George, Jonathan Holt, Adam Migus, Adrian 
  Gropper, Shane McCarron, Adam Lake, David I. Lehn, Les Chasen, 
  Eric Korb
Audio:
  http://w3c.github.io/vctf/meetings/2017-01-24/audio.ogg

Nate Otto is scribing.

Topic: Agenda Review

Dan Burnett: Agenda is 
  https://lists.w3.org/Archives/Public/public-credentials/2017Jan/0024.html
Dan Burnett:  Comments or suggestions on the agenda?
No changes.

Topic: Status of Verifiable Claims WG Vote

Dan Burnett:  Manu, can you give us an update on the Working 
  Group vote status?
Manu Sporny:  The vote is over; we did well. The W3C staff is now 
  talking to the organizations that formally objected. They asked 
  for some information from us, particularly around privacy.
Manu Sporny:  Have we responded to privacy concerns, will we 
  continue to respond etc. We sent them a list of links going back 
  to 2011 where we have worked to address privacy concerns.
Manu Sporny:  Don't know when this process will be over.
Dan Burnett:  Any other questions on the status of the creation 
  of the Verifiable Claims Working Group?

Topic: Use Cases Narratives and Revocation/Privacy

Dan Burnett: https://github.com/opencreds/vc-use-cases/issues/33
Dan Burnett:  We'll time-limit this discussion. Manu and Joe are 
  the two who are going to have the first comments here.
Joe Andrieu:  This started out as simply another way to represent 
  the tasks in the use cases. Specifically to upgrade and expand 
  the "sequences" we have. This is how I do it in my practice. What 
  came out of this exercise for me were some questions about 
  architecture and protocol. These are somewhat outside our 
  charter, but the questions were hard to answer without at least a 
  strawman.
Joe Andrieu:  From a requirements standpoint, it seemed like a 
  distributed ledger would at some point be necessary, made it seem 
  like an architecture section is necessary
Manu Sporny:  The idea of converting sequences to essential 
  narratives seems good. Waiting on you, Joe, to take the next step
Manu Sporny:  On revocation, there has to be some work on the 
  data model side on how to express revocation. Some work has been 
  done on this. Nate Otto (ottonomy) and Badge Alliance/Open Badges 
  have done some work on RevocationLists as one method.
Manu Sporny:  Do we want as part of the verifiable claims work to 
  specify how revocation is handled?
Manu Sporny:  One thing we can put in a credential is a "place to 
  look up revocation information".
Manu Sporny:  One approach is to say this is out of scope, to say 
  that here's a revocation url but it's up to you to figure out 
  what's at the end of that list.
Manu Sporny:  Those are at least two of the questions in front of 
  us about revocation? Do we want to express it in the group / do 
  we specify a specific protocol?
Manu Sporny:  I think you got the descriptions right in the 
  narrative got it right.
Manu Sporny:  I'll stop there. We have a couple decisions about 
  what we want to support in the group and how far we want to spec 
  this out. My company will be implementing ledger-based revocation 
  and url/http-based revocation in the next 6 months. We'll have 
  experimental proposals for the group to see if they want to bring 
  any of these approaches in.
Dan Burnett:  Could you say a little bit more about how to point 
  to an external object for revocation?
Manu Sporny:  In the current certificate authority system we have 
  a system for certificate revocation lists. This is a format for 
  certs that have been revoked by a CA. We're effectively talking 
  about the same thing, so part of this is to see if we can use the 
  same format. Or if a new format that's a better fit for VCs.
  ...would be better
Dave Longley:  We shouldn't assume that there is just one way to 
  do revocation. There may be varying needs for different levels of 
  privacy or etc. What we should be able to do is express 
  information in the credential itself to describe what type of 
  revocation method is used.
Nathan George: +1
Jonathan Holt:  I pitched this to the american board of medical 
  specialities. There's some differences about how this would like 
  to be expressed...
Adam Migus:  I agree with everyone here. I don't think we've done 
  a complete job if we "scope out" revocation. Need to have at 
  least one way in scope for the project.
Dan Burnett:  I'm not hearing any disagreement with putting 
  revocation into scope.
Dan Burnett:  I think we knew that anyway, but it's nice to have 
  it reviewed here that we agree that it's in scope.
Manu Sporny:  I do want to hear from Nathan George and Nate Otto
Manu Sporny:  The next steps for issue #33 is about converting 
  sequences to essential narratives: Let Joe convert the doc to 
  this format.
Manu Sporny:  We should take this revocation thing and move it to 
  its own issue.
Manu Sporny:  We need to create an issue in the data model to add 
  a section on revocation.
Nate Otto:  Yes, Badge Alliance and Open Badges Spec, moved to 
  IMS Global, we do have a notion of revocation list, and hosted 
  revocation. [scribe assist by Manu Sporny]
Nate Otto:  We have two ways of verification of revocation... ID 
  that is HTTP based for revocation... go fetch document, use 
  whatever you found as canonical document, if there is a property 
  revoked=true, then it's been revoked. Most people only publish 
  that property. [scribe assist by Manu Sporny]
Nate Otto:  There is also a signed assertion version, you can use 
  a revocation list where there is a Linked Data document that 
  contains an array of revoked assertions, if you find a revoked 
  assertion, then you can assume it's revoked. you can find 
  revocation reason. From this experience, not all platforms are 
  going to want to use the same method of revocation, we wanted to 
  keep spec open to things like ledger-based revocation in the 
  future.  [scribe assist by Manu Sporny]
Nate Otto:  If they are using signed verification - they may be 
  sensitive to hosting costs, so ledger based may be the way to go 
  in the future there. [scribe assist by Manu Sporny]
Nathan George:  A lot of our revocation story is centered around 
  the idea of anonymous credentials. About whether data is included 
  or not included in a specific claim. We can extend that story to 
  cover credentials that are not presented as an anonymous 
  credential. Would like to cover how revocation is covered in a 
  "did"-like object.
Dan Burnett:  Manu, you had volunteered to create a new issue for 
  the data model?
Manu Sporny:  Sounds like we are creating a new section in the 
  data model for revocation. Sounds like we don't want to say there 
  must be only one way. I'll volunteer to write this section.
Nate Otto:  Yes, I can help put that together
Dan Burnett:  Make sure to put forward and back references to 
  what we have.
Dan Burnett:  When you create the issue, link to #33 and from #33
Manu Sporny:  Will do.
Dan Burnett:  Any other questions/comments/discussion on either 
  issue #33 or the topic of revocation, creating a new revocation 
  section.

Topic: Correlation Analysis and Prevention

Dan Burnett: https://github.com/opencreds/vc-data-model/issues/12
Dan Burnett:  I think it was the same two people on this one.
Joe Andrieu:  This started out initially as an open question 
  about how we deal with correlation in the privacy section. I made 
  some notes, but I'll skip them, because they're not what the 
  issue became. Adrian added what I call a "use domain".
Joe Andrieu:  How do you talk about these usages that are really 
  several transactions in a system.
Joe Andrieu:  What came out was a discussion about correlation. 
  Questions for me came up like, "What's the architecture?" How can 
  we talk about correlation of different entities in these 
  transactions. Adrian's language didn't necessarily break it out 
  in terms of architecture and components.
Joe Andrieu:  We still have this open issue for how we want to 
  talk about the architecture in this document? How do we want to 
  talk about correlation (and preventing correlation) in our data 
  model so we can nail down privacy impacts of verifiable claims?
Manu Sporny:  I think the use case was super helpful from Adrian 
  to help narrow down all the types of anti-correlation that we 
  want to build into the system. It's also clear that we can't do 
  anti-correlation in some of these scenarios. Pure URL approaches 
  will correlate strongly... other approaches like using 
  pseudonymous signatures in other cases will preserve your 
  privacy.
Manu Sporny:  Not sure where we go with this. Two things we have 
  to do in WG: Enable a privacy-enhancing non-correlatable way of 
  doing this (minimum bar in the data model). Question: can we 
  suggest any standard way to do this -- while these technologies 
  are still in development, haven't gone through security review.
Manu Sporny:  Best we may do is say in the spec that it is 
  desired that these be non-correlatable, but provide a warning for 
  pitfalls that make them correlatable.
Manu Sporny:  Then outside the group, work on things like group 
  signatures, anonymous signatures, ... things that plug into the 
  spec and without any modification to the spec improve people's 
  privacy.
Manu Sporny:  For now, we should specifically point out what 
  actions lead to correlatability.
Dave Longley: We should say "unintentionally correlated"
Dan Burnett:  Adrian are you on the call?
Dave Longley: Since correlation is both a goal and something to 
  avoid
Dan Burnett: S/burn/JoeAndrieu/
Adrian Gropper:  I'm tracking what's being said. Glad to try to 
  help. Not at a point where I can relate this in terms of the 
  technology, but let's keep at it.
Jonathan Holt:  Great use case, well documented. While this is my 
  niche, it's a heavy lift.
Jonathan Holt:  Let's start off with a simple use case, with this 
  global vision in mind. This is less of a use case than a "use 
  domain" or a "vision". We're not quite there to apply this 
  technology to make sure we completely enable privacy from the 
  get-go.
Joe Andrieu:  I mentioned that in both the issues we talked 
  about, a desire to have some straw man architecture/protocol, 
  even though that's outside of scope. Maybe we can do what we did 
  for revocation about how we talk about this within the documents.
Joe Andrieu:  Vision: This pharmacy has its domain of trust, this 
  doctor has its domain of trust. We want the Pharmacy to not be 
  able to make certain correlations, but others might need to... 
  Need a description of architecture in this document.
Manu Sporny:  What type of architecture, and which document?
Joe Andrieu:  I have asked for an architecture in general for all 
  verifiable claims (what are our assumptions about all verifiable 
  claims). For revocation, I can address what I need by using a 
  "url, where there may be something". Some of these other use 
  domains need some circles and arrows to explain the different 
  actors, or the different domains of trust.
Jonathan Holt: +1
Manu Sporny:  Trying to get to next step here. Last thing you 
  said hit the nail on the head. We haven't documented the privacy 
  domains. I don't think we're there yet, but we can do a 
  privacy-and-security analysis on Adrian (agropper's) use case. 
  We're all pushing toward something where you're not correlatable, 
  but if we take specific scenarios and apply the spec as we have 
  it, we'll be able to say what the privacy implcations are. If we 
  do this enough times, we may come up with a general case, but 
  let's only generalize after we start to see patterns from 
  specific cases based on the VC spec we have now.
Adrian Gropper:  I think in terms of privacy engineering -- to 
  your comment about this being a "use domain": given that privacy 
  engineering is a field, it would be useful to bring that document 
  into the conversation that joe introduced us to whether we're 
  developing a use case or use domain.
Dave Longley: +1 To manu's suggestion
Dan Burnett:  Any objections to proceeding with manu's 
  suggestion, starting with agropper's use case?
Nate Otto: +1
Dan Burnett:  We do need people to do that though. The discussion 
  was "We could do this"... Who would be willing to work on that?
Jonathan Holt: I do
Adrian Gropper: 
  http://nvlpubs.nist.gov/nistpubs/ir/2017/NIST.IR.8062.pdf
Adam Migus: Sign me up
Joe Andrieu:  I can help, this is the next step to this work, but 
  I'm not familiar with agropper's term of privacy engineering
Manu Sporny: I volunteer to help w/ the privacy analysis for 
  Adrian Gropper's use case.
Adam Migus: (I know enough about NIST privacy engineering to be 
  *very* dangerous). :-)
Jonathan Holt:  It's about documenting the stakeholders. 
  Understanding the technology that's used in a position. I'm with 
  the american board of medical specialties, and this is a 
  cumbersome process right now. Need first understanding the 
  landscape of players, then the technical landscape.
Adrian Gropper: I volunteer as well
Jonathan Holt:  I can help understand the stakeholders and 
  document that. The privacy engineering field will have specific 
  angle. I can help with documenting the stakeholders, but this is 
  a heavy lift. There are background players, like employers 
  (providers of health insurance..). It' s about understanding the 
  flow of information in the state of the art and identifying 
  opportunities for privacy enhancement.
Nathan George: I've been through all these data flows before 
  (developed medical data products prior to my work at Evernym), 
  and can also participate as needed
Dan Burnett:  JoeAndrieu, will you oversee this and get it 
  started?
Joe Andrieu:  I think this is going to be more than a one hour 
  chat and we're done.
Joe Andrieu:  Should we set up a call?
Dan Burnett:  Every time we talk about privacy, there are other 
  aspects that come up? Worry that we wouldn't have the right 
  person on a breakout call when that happens.
Joe Andrieu:  Meant to propose a call on "Use Cases" generally, 
  not just this task.
Jonathan Holt: +1
Dan Burnett:  We have what we need to proceed for this issue? 
  Thoughts on proposal from Joe for separate Use Cases call?
Manu Sporny:  We're suffering from telecon-itis. Though we want 
  to help......
Manu Sporny:  See your point, want to agree. Will have trouble 
  carving out time on a regular basis. Wondering how to help 
  without volunteering to attend another telecon. Could we just 
  continue in GitHub and just tag a bunch of people who 
  volunteered? Or just one call to make a gameplan then move to 
  async in the issue tracker?
Joe Andrieu:  I take your point.
Jonathan Holt: +1
Joe Andrieu:  You guys have lots of calls, looking at the larger 
  community of conversations going on here. We could try moving 
  this forward on GitHub, or have an initiating call to establish a 
  framework and then tease out the details on GitHub. I'd like to 
  (at least) do that. As part of my conversation with agropper 
  there was some good back and forth, but I'm not sure I've grasped 
  the whole domain. Maybe take a call to frame the domain and then 
  move to GitHub.
Jonathan Holt:  Great solution.
Jonathan Holt:  If we have one call to hash out details, then 
  move to github. This is a great domain to "solve", if we solve 
  this one, other solutions may come from it.
Shane McCarron: "A Repo-Man's life is always intense"
Dan Burnett:  Do you need something longer than an hour? We could 
  dedicate next week's call to this for the kickoff meeting.
Manu Sporny: I noted volunteers here: 
  https://github.com/opencreds/vc-data-model/issues/12#issuecomment-274862221
Joe Andrieu:  That would be great. Save me the trouble of 
  organizing a different time on people's calendar.
Dan Burnett:  Any objections to using next week's telecon for 
  that?
Joe Andrieu: And lets keep the github moving forward as well
Dan Burnett:  Will connect with you on agenda, to let you take it 
  over.
Manu Sporny:  Question for you, Dan: At some point, we should 
  talk about those of us who will be implementing over the next 6 
  months... test suite... requirements.
Dan Burnett:  I'll be talking with the other chairs later this 
  week about what would be a good way to address that. We'll be 
  sending some thoughts out to the list within a week or so.
Dan Burnett:  We're at the end of our "above-the-line" items for 
  the agenda.
Dan Burnett:  JoeAndrieu, is there anything else you're aware of 
  in the issues that would be good for productive discussion for 10 
  minutes?

Topic: Filtering, Focusing use cases

Joe Andrieu:  In vc-data-model privacy issues, several are near 
  duplicates: #11 & #12, #6 & #7
Joe Andrieu:  Make sure we get everyone's pet use case on the 
  list of what's dealt with.
Shane McCarron: +1 To that
Manu Sporny:  Along those lines, JoeAndrieu, I think we've been 
  talking about healthcare and education for a bit, but the VC work 
  was kicked off and started by the Web Payments IG. They care 
  about things like digital loyalty, coupons, offers. From my 
  perspective those are all verifiable claims. JoeAndrieu, do you 
  feel these retail use cases are well represented in the doc? I'd 
  hate to get into the group and not have these use cases present 
  for people who are not yet at the table (in some cases, they  
  have their own group for Digital Offers). Those have been use 
  cases for a long while, the reshuffling to focus on focal use 
  cases, we may have lost a few of those retail/commerce use cases.
Shane McCarron: We had lots of use cases about finance in the 
  document I edited...
Jonathan Holt: That is my concern as well that we are doing a 
  "push" into healthcare, when there currently is a "pull" in the 
  web payments domain.
Joe Andrieu:  Yes we did; The only two retail we have are young 
  use cases. Adult beverages... Manu what I'm hearing is we need to 
  overall review whether we have the domains we want to focus on. 
  In those domains, do we have the use cases that matter to those 
  domains?
Joe Andrieu:  Under retail, we only have address verification and 
  adult beverages.
Manu Sporny:  This is a problem to only have so little for our 
  organization. I want to at least want some of these (loyalty, 
  offers) in the document so people can't say we ignored it. We're 
  not coordinating with the Digital Offers group enough. Would like 
  to cross pollenate, so we can hear their use cases. Get more of 
  those people into this group beyond dezell and myself.
Dave Longley: Offers: "you can buy this for X", loyalty: "you are 
  loyalty member X", receipts: "you bought this for X, it's your 
  proof-of-purchase", discounts/coupons: "you can buy this thing at 
  a reduced rate" or "you can buy two of these for the price of 
  one"
Manu Sporny:  It's Digtial Offers (this thing, this price), 
  digital coupons, loyalty cards, digital receipts (which will be 
  raised soon in WP IG as point of interest). Web Payments IG 
  working on 2017 vision now, having face-to-face in Chicago in 
  March. Would be good to get some of this work fed back to the WP 
  IG especially on digital offers.
David Ezell: I agree that Digital Offers should be front/center 
  in terms of use cases.
Dan Burnett:  I want to hear some of the comments from others, as 
  we're getting short on time. Want to make general statement that 
  it's easy sometimes when (this effort spun out of payments, so 
  payments group may think we know what they need), but at some 
  point soon we need to prioritize what we work on. Priority is 
  likely to be based on those who are participating in the group.
Dan Burnett:  Before dezell panics, this is not saying use cases 
  from payments are not important, but more of a motivation for 
  that group to keep participating. Participation will be what 
  ensures we can focus on that work when we start prioritizing. Any 
  prioritization we do now will be redone/reshuffled when the WG 
  starts anyway.
Joe Andrieu:  Previously, I suggested bringing in domain experts 
  in each of these domains. Is there a way to do that for the 
  domains we're addressing in healthcare, finance, retail, 
  (education). Is it a good process idea to try to corral specific 
  people?
Dan Burnett:  It's fine to invite people you think will help us 
  move forward. If they're difficult to get, find a week they might 
  be able to attend and let's work it into the agenda then.
Joe Andrieu:  More like identifying people who are already in the 
  conversation. "I want to work with YOU on HEALTHCARE" "I want to 
  work with YOU on FINANCE". Are there people in our conversation 
  already we can earmark?
Adam Migus: Please consider me an SME for financial services
Dan Burnett:  Good discussion; we're at the end of the hour.
Dan Burnett:  Let's table that for the moment. Not quite sure 
  where to put it. Very important question about how that should 
  work. Let's talk offline, JoeAndrieu about a good way to 
  incorporate.
Dan Burnett:  Thank you very much.
Received on Tuesday, 24 January 2017 17:20:00 UTC

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