Lionel Wolberger: Data Minimization, Selective Disclosure and Progressive Trust ✪
Lionel Wolberger: Three goals -- data minimization, selective disclosure and progressive trust -- we need definitions around these ✪
Lionel Wolberger: Other focus -- trying to move forward one of the implied processes ✪
Montgomery Hart: It looks like some of these crypto methods definitions need work. ✪
Lionel Wolberger: We need more civic leaders, org leaders, to try to understand the basics here. ✪
Joe Andrieu: Great introduction in the document, Lionel. ✪
Lionel Wolberger: The average driver can change oil, so people need to understand the basics -- background to accustom people to focus on cryptography. ✪
Lionel Wolberger: Focusing on the three terms - data minimization, selective disclosure and progressive trust -- part of the main work here is to define these terms. I'm finding this useful, bringing privacy enhancing strategies down to critical vectors. ✪
Lionel Wolberger: It's good to get orthogonal differences between words that meet our aims. ✪
Lionel Wolberger: The first definition is a policy definition - ✪
Lionel Wolberger: Data minimization is a policy of minimum data collection and/or access for maximum value: limiting the amount of shared data strictly to the minimum necessary in order to successfully accomplish a task or goal. ✪
Lionel Wolberger: Data minimization should focus on the policy - the human motivations, the organizational tendencies -- it's a non-technical word... if you don't need it, don't use it. Minimum data for maximum value. ✪
Lionel Wolberger: Selective disclosure is the ability of an individual to granularly decide what information to share. Selective disclosure is a means by which data minimization can be achieved. ✪
Lionel Wolberger: The next term is where we want to roll in technical/crypto stuff - selective disclosure - the means by which data minimization is achieved. Three terms related to one another. ✪
Lionel Wolberger: Progressive trust is the ability of an individual to gradually increase the amount of relevant data revealed as trust is built or value generated. ✪
Lionel Wolberger: The third one is progressive trust - this is behavior over time - how we expect our digitally powered relationships enable types of interactions where we trust individuals and organizations. ✪
Lionel Wolberger: We want to be able to dial it up, and dial it back. ✪
Christopher Allen: I had suggested that we clarify these terms for our own usage because there was a disconnect between cryptography uses of it and security uses of it. When I tried to do research on data minimization, I kept finding documents stating that data minimization was a requirement, but then didn't outline strategies. ✪
Christopher Allen: I suspect as we have more cryptographers that we may need to clarify these discussions and reconcile them. You can have a complete copy of your own persona, all the VC stuff itself. Data minimization is the technique where we can only give those portions that are absolutely required to various parties. Selective disclosure applies cryptography to that, partial information in a blinded way so that there are additional capabilities. ✪
Christopher Allen: Progressive Trust is how entities ask for more... these all fit together. ✪
Christopher Allen: I'd like to be clear about this, have a paper, publish strategies for data minimization, selective disclosure, etc. ✪
Christopher Allen: I hope we can dive deeper into this. ✪
Jan Camenisch: Two comments for now, regarding data minimization -- it's important to point out that minimum disclosure is not the only way to provide this. SSN is a good example, SSN used as key not realizing that's a bad thing to do. Just using this technology by itself, you need to understand business processes to get data minimization to appropriate level. ✪
Jan Camenisch: Second point, selective disclosure - you have your credential that can selectively disclose your attributes. When you have a credential w/ verifiable claims, don't mix up item I receive from an issuing party vs. the item that I send to a verifier. The way you use crypto typically, you transform the item that you're sending to the inspector. ✪
Moses Ma: I'm wondering if terms like "data leakage prevention" or "identity security" might be useful in greater adoption - "data minimization" feels like it's not descriptive of the goal and doesn't create an emotional impact? ✪
Jan Camenisch: You may use a ZKP on the credential -- helpful to give those two artifacts different names. ✪
Jan Camenisch: It might be helpful for people to understand between the two things. ✪
Dave Longley: I.e. the information presented may be a "proof of possession" of a credential with certain attributes rather than the credential itself (depending on the presentation protocol/crypto methods used and privacy requirements) ✪
Joe Andrieu: Data Minimization -- Policy -- technology by itself is not enough. e.g., SSN as key in database Selective Disclosure -- Technical -- adds cryptography to present PARTIAL subsets of credentials Progressive Trust -- UX -- optimizing human experience by building relationships over time ✪
Joe Andrieu: Move extraneous definitions to later in the document - resonating w/ what I just posted... one of them is policy, other is technical mechanism, optimize human experience. You can do or not do, enhances human experiencce. ✪
Adrian Gropper: Great start, love the way everything is separated out. Duration of storage of credentials/claims - one aspect of minimization is that you can't store information you're getting. You have to ask for it again. Ask for it transparently, if someone does store some aspect, I can go back and see what they have. ✪
Adrian Gropper: Are these two dimensions in scope? ✪
Christopher Allen: I would say yes, this is still pretty early ✪
Christopher Allen: Selective disclosure in the cryptography community has always been a Zero-Knowledge technique, but in the broader identity community I kept hearing examples of people talking about things that they said were "selective disclosure", but what they really were was data minimization. ✪
Christopher Allen: For example, I can go to a bar and provide an over-21 claim, I can do that directly don't need crypto to do that. Selective disclosure takes that up a notch and allows me to have issuer give me a date and then me provide something different like "over 21" ✪
Christopher Allen: If I just give "DMV says I'm over 21", give that to drug store, shipper combines all of that... data minimization helps, but selective disclosure/anti-correlation helps you blind that... combine w/ shipper next door, etc. ✪
Christopher Allen: For broader community, I'm thinking of selective disclosure as various cryptographic techniques. ✪
Christopher Allen: SSL had this as one of its principles, start off as very little trust, add confidentiallity, upgrade to identify one party, both parties, ,etc. Progressively more secure/trustworthy. ✪
Manu Sporny: Thanks Lionel, everyone else that worked on this. It's a great start. [scribe assist by Dave Longley] ✪
Manu Sporny: I wanted to point out something that isn't a surprise to anyone -- I'm concerned about what we're saying about selective disclosure. Meaning the cryptography itself can do. When we talk about it, we do it in vacuum, you can prove things in zero knowledger and here's how you do it, and all of that is correct. [scribe assist by Dave Longley] ✪
Manu Sporny: When you deploy to the real world and there are other identifiers they have as a natrual consequence of ordinary day to day usage [scribe assist by Lionel Wolberger] ✪
Manu Sporny: Markers like IP address, email address [scribe assist by Lionel Wolberger] ✪
Lionel Wolberger: ... These crypto tricks are discussed in a vacuum and we do not have production systems at scale where these are working. ✪
Lionel Wolberger: ... Danger of lulling people into a false sense of security ✪
Lionel Wolberger: ... If we do that, it will come back and bite us. ✪
Drummond Reed: I strongly disagree with Manu that because other highly correlatable identifiers are in high usage, that means it is not practical to introduce new systems that do not use such correlatable identifiers. ✪
Ted Thibodeau: "Selective disclosure" just means "choose what you say"; it doesn't mean "they can't see you, ask others about you, etc." ✪
Joe Andrieu: +1 For being careful about claims for selective disclosure being a silver bullet wrt correlation ✪
Lionel Wolberger: ... Ensure that the document states the dangers presented by this other data that constantly flies along the side of privacy engineered transactions ✪
Lionel Wolberger: ... This creates a constant passive (if not active) attack on our systems ✪
Drummond Reed: Until we build infrastructure that fully supports pairwise pseudonymous identifiers and selective disclosure, it will continue to note be possible. ✪
Lionel Wolberger: ... Our long term position is that this stuff is quite limited in its capability to protect people. ✪
Manu Sporny: Back to you for scribing, and well said! [scribe assist by Lionel Wolberger] ✪
Moses Ma: I think we should consider things like "identity security" and "data leakage" -- things that are more descriptive and immediately wanted by public. ✪
Jan Camenisch: Sorry need to leave :-( there would be lots to say here.... ✪
Christopher Allen: @Jan_Camenisch See you first Tuesday in March! ✪
Drummond Reed: I understand Manu's point, mixing systems creates a mess. I want to voice the opposite view - we are building infrastructure w/ CCG technologies that will enable broad/global scale support for pseudonymous identifiers. Those systems are needed by new products/services w/ GDPR. ✪
Christopher Allen: @Jan_Camenisch Can you come to #RebootingWebOfTrust in Santa Barbara? ✪
Drummond Reed: I'm very involved with Sovrin infrastructure/tech - very focused on technology - demand is there - need is there - this is a requirement. Lots of examples for that. The fact that correlation is so deeply entrenched is not a reason to say that we should not proceed and start building infrastructure that's not correlatable. ✪
Montgomery Hart: I don't think the issue is there isn't demand, or that we don't need this--I think the point is that we need to be extremely careful about side channels. ✪
Drummond Reed: Some of this is coming through regulatory compliance, some of this is coming through org needs - constant surveillance is a problem. ✪
Drummond Reed: Yes, I agree about being very careful about side channels. But to even have that problem, we have to build the non-correlating layer. ✪
Mike Lodder: I agree our layer needs to not introduce new correlation ✪
Drummond Reed: I have to leave early today, but glad we are diving deeper into this discussion. ✪
Christopher Allen: Other correlators such as MAC addresses, you need to warn people about them, we're responsible for our layer. Don't agree that there isn't something in place - Lightning on Bitcoin uses Tor-style circuits for everything, carefully designed to minimized correlation down to a deep level. They do have areas where they need people to make verifiable claims for products/services on Lightning. ✪
Christopher Allen: They need to make sure that next layer up doesn't break that. I do want to move to next agenda item which is a review of the suites. Data Minimization suite, selective disclosure suite that can help clarify some things. ✪
Joe Andrieu: My comment: people are arguing with me, e.g., on Twitter, about things I didn't say, but which they hear coming out of others in the community. ✪
Lionel Wolberger: We discussed a few terms, will take more feedback, will discuss this overall challenge behind discussing selective disclosure. ✪
Manu Sporny: No doubt that there is demand for selective disclosure capable technologies, concern is over-promising at the wrong time. [scribe assist by Lionel Wolberger] ✪
Lionel Wolberger: ... Avoid accidental side effects, side channel attacks ✪
Lionel Wolberger: ... If we were rolling out these services built from the ground-up on selective disclosure, it could work ✪
Lionel Wolberger: ... But that is not how the market works. ✪
Lionel Wolberger: ... Services roll out with all other services in the background ✪
Lionel Wolberger: ... You may argue bitcoin did that, but it inevitably must touch other systems with correlatable identifiers ✪
Lionel Wolberger: ... We need to call out in advance that we saw this coming and stated proper precautions that needed taking ✪
Lionel Wolberger: ... We need this technology, just avoid the over-promising particularly in the areas of security and privacy. ✪
Adrian Gropper: We're talking about tech for "do not track 2.0" ✪
Dave Longley: It's difficult to imagine many cases with a non-correlating layer being used and there was no other fingerprint/trace of your identity left via any other side channel either by accident, or because you don't fully control your own identity, or because it is mandated by regulation (or likely would be in the future), etc. ✪
Joe Andrieu: I wanted to highlight that we need to be careful w/ the hype. I spent most of the weekend pushing back against things other people in this community have said that are concerning people in the identity community. ✪
Topic: Cryptography Suite Implementations
Christopher Allen: We have an RSA Suite, Koblitz Suite, intrigued by redaction signature suite -- in our canonicalization of graph data, we end up with a list of quads. ✪
Moses Ma: How does "Do Not Track 2.0" fit with BitFury's Crystal suite for blockchain investigation and transaction tracking? ✪
Christopher Allen: The idea would be to hash those quads individually, and then hash the hashes. ✪
Christopher Allen: This is not selective disclosure, it enables data minimization. ✪
Christopher Allen: As the bearer of one of these credentials, they could choose to only give a minimal number of attributes. Party that receives it can verify that they did receive it. They can verify that non-redacted items work. ✪
Christopher Allen: That enables a lot of data minimization. Maybe this should be our minimum recommendation in a signature suite? It doesn't prevent correlation, but it is imminently analyzable. It requires nonces to be properly secure, but we could review/secure/add significantly to. ✪
Christopher Allen: Also think it has consequences -- verifier code has to come back and say "not everything was verified, just the stuff we needed". Different result code in libraries vs. true/false verified or not. ✪
Christopher Allen: Object has particular data that we wanted (or didn't have the data). We can contrast that w/ much more complex pseudonymous signature suite that uses selective disclosure. ✪
Christopher Allen: Compare/contrast against CL Signatures, etc. ✪
Christopher Allen: Goal for this agenda item -- look through items / data verification - where should efforts go? ✪
Manu Sporny: The LD Proofs and signatures and stuff, these aren't official W3C recommendations right now. We are building on top of things that haven't gone through the W3C process, most people in this group don't care about that, but I think it's really important that they do and we want more cryptopgraphers looking at it and poke holes in it. [scribe assist by Dave Longley] ✪
Kim Hamilton Duffy: +1 To more review and extreme vetting of the signature suites ✪
Manu Sporny: In the latest version of one of the suites we're using something compatible with JOSE. I wonder if there's a part of crypto Tuesdays that we push together the things people are taking for granted. The suites that are out there RSA/Koblitz/etc -- and getting those down the international standard pipeline before or as we look at the other specs like CL signatures and redaction, etc. Is there interest in helping push that stuff forward? [scribe assist by Dave Longley] ✪
Joe Andrieu: Yes, definite interest -- question -- what's the best way to do that? ✪
Manu Sporny: We're getting to that stage where we need implementations. Multiples of those from outside and inside the community and test suites would really help. Without that harder to push things further. If we had some place to focus, that would be it. The other thing is that to start a W3C WG you need TAG review, security review, etc. [scribe assist by Dave Longley] ✪
Manu Sporny: So that's what we need for the next steps. Crypto Tuesdays will hopefully help attract cryptographers to review the specs. [scribe assist by Dave Longley] ✪
Manu Sporny: Once we have that in line, then it will be fairly easy to get it through the W3C process. The other thing that's bad about crypto -- it's really hard to get crypto through standards organizations because the companies who want to devote the time and money to get it through -- there aren't a lot of those folks on the planet. We need a good solid core like 15 companies to push things through. [scribe assist by Dave Longley] ✪
Manu Sporny: Next steps are implementations and then update the specs accordingly, and then build a set of companies that will take these things through the REC process at W3C or at IETF or elsewhere. [scribe assist by Dave Longley] ✪
Joe Andrieu: (I'm back. Seems to be temporary blip.) ✪
Christopher Allen: I'm concerned about taking on the Redaction signature suite and it should be a priority. [scribe assist by Dave Longley] ✪
Lionel Wolberger: THanks to seeing Jan, Brent, Irene on the call--sorry about conference line bouncing issues! ✪
Christopher Allen: I think redaction signature suite should be a priority - fundamentally, there will be the argument wrt. "there is already the JOSE spec"... what we have that is not possible in JOSE is that we have graph data. Not talking JSON, not talking anything else... just graph data. ✪
Christopher Allen: Graph data has an advantage, the only thing that takes advantage of graph data is redaction suite... much stronger position when going to other parties... one of the biggest reasons are data minimization requirements... we can support w/ redaction signature suite. ✪
Christopher Allen: That might be the real leverage point to persuade people to making this a standard vs. JOSE. ✪
Manu Sporny: I think if you use that line of argumentation, the counter is you can do this in JOSE you're just missing converting into a Quad format and then hash it. Data Normalization is missing -- and if you had that you could use JOSE. Granted, you'd still have all the semantics issue, you don't know what the data means, you have issues with cross syntax portability (you can't use same signature in CBOR, JSON, XML) -- those are the real benefits of the Linked [scribe assist by Dave Longley] ✪
Christopher Allen: Partial information isn't useful? [scribe assist by Dave Longley] ✪
Manu Sporny: You could normalize out into a list and redact it. [scribe assist by Dave Longley] ✪
Manu Sporny: The response could be "no you don't, just normalize into a list and here's how you do it, and you don't need Linked Data Signatures". I think that will be the response because the folks that are using JOSE and JWS believe in a fully JSON world. [scribe assist by Dave Longley] ✪
Manu Sporny: That's what the data format is and you use that, full stop. Where as LD signatures doesn't make that assumption and calls for normalization. I think it would be fairly easy to knock the legs out from under it, that's not to say data minimization isn't useful. [scribe assist by Dave Longley] ✪
Manu Sporny: The other concern I have is that Dave and I put that together and we have zero free time -- would need others to help take it forward. [scribe assist by Dave Longley] ✪
Manu Sporny: The Redaction suite. [scribe assist by Dave Longley] ✪
Christopher Allen: If you are interested in that suite, let me know. This may be an important leverage marker for us. We do have to have RSA and Koblitz reviewed, there are questions about nonces and other things in those suites. We need cryptographic review of those things. ✪
Christopher Allen: Those will be topics of future meetings, if there are other people interested in redaction suite, please let me know. That's it for today. Next weeks meeting is on ocap and verifiable claims. ✪