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

Verifiable Claims Telecon Minutes for 2017-01-17

From: <msporny@digitalbazaar.com>
Date: Tue, 17 Jan 2017 17:02:50 -0500
Message-Id: <1484690570896.0.12612@zoe>
To: Web Payments IG <public-webpayments-ig@w3.org>, Credentials CG <public-credentials@w3.org>
Thanks to Matthew Larson 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 2017-01-17

  1. Agenda review and Introductions
  2. Status of Verifiable Claims WG Vote
  3. Web of Trust Use Case
  4. Prioritization of/response to privacy concerns
  Dan Burnett
  Matthew Larson
  Matthew Larson, Dan Burnett, Manu Sporny, Gregg Kellogg, 
  Christopher Allen, Joe Andrieu, Eric Korb, Nathan George, Dave 
  Longley, Nate Otto, Jonathan Holt, Adrian Gropper, Adam Migus, 
  John Tibbetts, David I. Lehn, Rob Trainer, Adam Lake, David Ezell

Matthew Larson is scribing.

Topic: Agenda review and Introductions

Dan Burnett:  Manu had suggested that web of trust use case ... 
  issue 32 .. any objections?
Dan Burnett: Manu requested discussion of 
  ... suggested some discussion on privacy issues... any issues 
  after trust use case?

Topic: Status of Verifiable Claims WG Vote

Manu Sporny:  Status of vote. Vote closed on Sunday. 
  Fantastically healthy turn out. Highest number of votes in 
  history (pending verification).  Some formal objections around 
  privacy, thinking that privacy on web could be greatly harmed. 
  But most were simple +1s.
  ... things are good, the only thing that we need to do is to 
  address privacy concerns... and agenda item will address that.

Topic: Web of Trust Use Case

Dan Burnett: https://github.com/opencreds/vc-data-model/issues/32
Gregg Kellogg: Note that “WoT” is an ambigious acronym for those 
  also involved with “Web of Things”.
Christopher Allen:  It is relevant to to quicly discuss the use 
  case. What I tried to do was capture a more modern version of the 
  classic PGP use case.
  ... If we have someone who wishes to establish a relationship 
  to the world and aquire relationships and credentials and set 
  aside some of the anonymity and get a job in those fields.
  ... I tired to identify some bootstrapping issues. One of the 
  first was the self signing. And what does it mean to be self 
  signed? It gets more thorny in the class PGP sense.
Manu Sporny: Here's where I started responding: 
Manu Sporny:  Given that background, what I tried to do in the 
  issue is map the issues in what Christopher was talking about. If 
  you look at the issue below ^
  ... There was a slight distinction in bewteen a claim and a 
  credential. A verifiable claim could be a age on a license . An 
  entity credential is a collection of claims. For instance a 
  drivers license is an entity credential.
Joe Andrieu: Terminology: Is it ok to say that an unsigned claim 
  is a "claim"?
Dan Burnett: Joe, I personally think so.  It is a claim, but it 
  is not a verifiable claim
  ... At the bottom of the comments there is a properly formed 
Eric Korb: Is this the example Manu is referring to: // This 
  credential states that Alice knows Bob, and Bob has a public key 
Nathan George:  One question I have is what zero knowledge proofs 
  have in verifiable claims?
Manu Sporny: Erkorb_rm, no, that's not the example, it's the one 
  further up on the page.
Manu Sporny: Erkorb_rm, this is the example we're looking at - 
Eric Korb: Manu, thx
Eric Korb: Manu, DDO = ?
Dave Longley: 
Manu Sporny: Erkorb_rm, DDO means Decentralized Identifier 
  Descriptor Object 
Dave Longley:  Part of the challenge here is we really arent 
  talking about the cypto and there is some questions about the 
  crypoto graphic proofs and how they related to verifiable claims.
Manu Sporny: Pseudonymous signature scheme: 
Manu Sporny:  Nathan to to respnd there are multiple places where 
  these proofs can be  used in VC. SO what might be most helpful is 
  to define the data models.  Since we are a working group we need 
  to be very specific about DM and how they apply to VC.
Christopher Allen: These are ZKPs - 
Christopher Allen: Please don't confuse these with cryptographic 
Christopher Allen: They are VERY advanced.
Dave Longley: The attributes you express in the claim may 
  eliminate your pseudonymity, despite your best efforts to hide 
  other types of identifiers
Christopher Allen: There are things between like selective 
  ... VC is focusing on cyrpto graqphic proofs. We have to be 
  very careful about ZKPs.  We have to be very careful when we say 
  a technology protects a persons privacy. As there are simple 
  defeats to these technologies.
Dave Longley: Furthermore, your ability to use claims made about 
  you may be significantly reduced (or entirely) due to a lack of 
  accountability (as they seem to made about "anyone")
Christopher Allen:  I have some concerns in that I want the 
  dataformat to express the ability to address ZKPs. But in fact 
  ZKP are very new and there are a variety of complexities. And I 
  dont want that to get in the way of being able to have psuedo 
  anomonymous low cryptography claims.
  ... lets be careful and not get totally lost. The big thing 
  that is missing is the question of a nonce that I talked about. 
  The question of a simple cyrypto that that the other party has 
  possession of the private key.
  ... finally lets make sure everyone knows that no names have 
  been exchanged here.
Joe Andrieu:  My question is about the user use cases... about 
  the revocation of a claim. Manu I appreciate yuour feed back that 
  we dont depend on ledgers.
  ... how do we talk about this example when a claim has been 
  revoked or ammended.
Manu Sporny:  The use case is covered in multiple ways.  What is 
  the best practice?
Dave Longley: Note: because this data model is based on Linked 
  Data, we can mark up just about anything at all; anyone can 
  create vocabularies in a decentralized way to represent the 
  meaning they want to convey in their claims.
  ... To address that is is a decentralized ledger markup? This 
  is true. Anywhere there is did: this can be replaced with a 
  https: url. But when you do that you lose data portability.
Dave Longley: There can also be links to revocation ledgers or 
  lists included with credentials
Nate Otto: As manu says, some companies are strongly in favor of 
  using http scheme. A couple large companies in Open Badges 
  approached me to request that http based ids for badge objects 
  continue to be supported.
Joe Andrieu:  If there is not a referencable live souce of this 
  information there is no way to ammend it. Am I on the right page?
Manu Sporny: Here's an example of a credential identifier:    
  "id": "did::Alice#CREDENTIAL1",  // this credential lives in the 
  DDO (although, this is not necessary)
Christopher Allen: DID have a method to see revocation
Dave Longley: It could also be linked to via the issuer's 
  dereferencable identifier ... there are a variety of ways we 
  could support different modes of revocation.
Manu Sporny:  At the minimum there is that identifier. There 
  could be another link to a revocation list.
Jonathan Holt: Does multiaddr have a role in the identifier?  
Nate Otto: See ob:RevocationList 
Christopher Allen: I'm not sure ob:RevocationList is the way you 
  do it with many DIDs methods.
Christopher Allen:  I want to make it clear that it depends on 
  the DID method.  In some of the methods that are being developed 
  now there are different ways revocation is accepted. So there 
  might be multiple ways to do it.
  ... In the simplest method the whole claim is revoked and 
  placed.  there is no revocation list.
Christopher Allen: Not necessarily "every possible way", but the 
  most important ones.
Manu Sporny: Yes, agreed.
Nate Otto: @ChristopherA Seems like you are assuming a method of 
  resolving dids to a hosted/available entity. OB defined 
  RevocationLists for @ids where that may not be possible, by 
  making a revocationList available instead. I'm interested in your 
  comments about ob:RevocationList; you could drop them here 
Dave Longley:  It depends on the type of claim in how the 
  revocation is expressed. Its our job to ensure that the data 
  model can express this information. Not say there is only one 
  machine readable way to do this.
Christopher Allen: Also, we don't require ways that others don't 
Dan Burnett: Agree that next discussion should happen in the 
  issue before we talk about it again
Manu Sporny:  The question is does ChristopherA feel if the use 
  case issues have been addressed. This discussion can move to the 
  issue tracker.
Christopher Allen:  Progress is being made, but some maturation 
  is needed in the cryptographic proof.
Agreement that this discussion can occur in issue tracker.

Topic: Prioritization of/response to privacy concerns

Manu Sporny:  This has to do with formal objections. Most 
  everyone who had objections had privacy concerns.(Destruction of 
  internet privacy)
Dan Burnett: Wow, amazing since one of our drivers has always 
  been the enabling of privacy at the core
Manu Sporny:  The group cares about privacy but communication has 
  not been ideal.
  ... The privacy sections of the spec should be filled in at 
  least to what we can
  ... The use of any long lived identifier is dangerous. And 
  cross origin identifiers should be discouraged.
Dave Longley: General idea being put forth by the objectors is 
  that the foundation for any claims tech should be unlinkable 
  claims, everything must be built *on top of* it.
Manu Sporny:  Emails as cross origin ids exist, but we dont want 
  to make the problem worse.
Dave Longley: Rather than our approach: there are different use 
  cases, we can do pseudonymity in some cases and not others, some 
  claims strongly identify people anyway, let's not *require* 
  everything to be built on a layer of complexity that may prohibit 
  certain use cases from being practically implemented (or that may 
  bind us to a particular type of crypto that may be broken in the 
Manu Sporny:  We are going to have to put forth more effort in 
  explaining our privacy strategies. Who can volunteer to help us 
  document our current thinking on privacy?
Christopher Allen:  Privacy is an overloaded word and there are 
  many approaches to privacy. We crippled here in that we are 
  mostly focused on data format and protocols generally address 
  ... Identity is correlation which is good/bad on one had we are 
  correlating as a part of this effort, but on the other hand 
  correlation can reduce privacy.
Dave Longley: Email address.
Adrian Gropper: I volunteer
Adam Migus: Privacy is control; the idea that we should not have 
  cross-domain identifiers because it's bad for privacy is 
  wrong-headed. Rather, allowing the user to establish identifiers 
  and correlate them however they like (which we do) is privacy.
Manu Sporny: +1 To what amigus just said!
Nate Otto: I volunteer
Dave Longley: My view is that the main concern from the objectors 
  is that they think users will be unaware that their privacy is 
  being compromised ... that what they expect they are sharing with 
  others won't be the same as what they actually are sharing with 
  others (i.e. they will be sharing more).
Nathan George: Evernym has made progress around these privacy 
  issues and has things to say as well
Manu Sporny: Here are the privacy issues that we're tracking 
  right now: 
Manu Sporny:  If you have volunteered if you can assign yourself 
  one of these ^ . Start with one.
Manu Sporny: I see the following volunteers for privacy issue 
  documentation: Adrian Gropper, Nate Otto, Nathan George, 
  Christopher Allen, Manu Sporny.
Christopher Allen:  If you are getting ready to code. Get in 
Jonathan Holt: When is the rebooting the web of trust in Paris?  
  and what other conference is happening that week?
Manu Sporny: Here's the link to RWoT - 
Christopher Allen:  April 21-23
Received on Tuesday, 17 January 2017 22:03:20 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:08:56 UTC