The Verifiable Claims Task Force

A Task Force of the Web Payments Interest Group

Verifiable Claims Telecon

Minutes for 2017-01-17

Agenda
https://lists.w3.org/Archives/Public/public-credentials/2017Jan/0012.html
Topics
  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
Organizer
Dan Burnett
Scribe
Matthew Larson
Present
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
Audio Log
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 https://github.com/opencreds/vc-data-model/issues/32
... 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

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: 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 credential.
Eric Korb: Is this the example Manu is referring to: // This credential states that Alice knows Bob, and Bob has a public key X
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 - https://github.com/opencreds/vc-data-model/issues/32#issuecomment-272546904
Eric Korb: Manu, thx
Eric Korb: Manu, DDO = ?
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: https://w3c-dvcg.github.io/lds-pseudonymous2016/
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 - https://en.wikipedia.org/wiki/Zero-knowledge_proof
Christopher Allen: Please don't confuse these with cryptographic proofs.
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 disclosure.
... 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? https://github.com/multiformats/multiaddr/blob/master/protocols.csv
Nate Otto: See ob:RevocationList http://openbadgespec.org/#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 https://github.com/openbadges/openbadges-specification/issues/33
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 need.
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 future)
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 that.
... 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: https://github.com/opencreds/vc-data-model/issues?q=is%3Aissue+is%3Aopen+label%3Aprivacy
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 touch.
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 - http://www.weboftrust.info/next-event-page.html
Christopher Allen: April 21-23