- From: Markus Sabadello <markus@danubetech.com>
- Date: Thu, 8 Feb 2018 00:38:12 +0100
- To: public-credentials@w3.org
- Message-ID: <5ac53787-d456-6551-e089-f3fc4624641c@danubetech.com>
Sorry again for missing the call yesterday, but 3 comments/questions related to what's in the minutes: 1. In the DID spec, there's no section yet that describes the "publicKey" array of the DID document. Is anyone working on that? 2. Regarding signature suites, the LD key registry <https://w3c-ccg.github.io/ld-key-registry/> mentions Ed25519SigningKey with an example but doesn't have a link to that. Is anyone working on that? [If not, then perhaps I could] 3. Regarding implementations, I was doing some work for the Finnish TrustNet project to implement Verifiable Credentials in Java, including signing with RSA and Ed25519, highly experimental, but wanted to share: https://github.com/TrustNetFI/verifiable-credentials-java This uses LD-Signatures in Java: https://github.com/WebOfTrustInfo/ld-signatures-java Markus On 02/06/2018 08:38 PM, msporny@digitalbazaar.com wrote: > Thanks to Lionel Wolberger and Manu Sporny for scribing this week! The minutes > for this week's Credentials CG telecon are now available: > > https://w3c-ccg.github.io/meetings/2018-02-06/ > > Full text of the discussion follows for W3C archival purposes. > Audio from the meeting is available as well (link provided below). > > ---------------------------------------------------------------- > Credentials CG Telecon Minutes for 2018-02-06 > > Agenda: > https://lists.w3.org/Archives/Public/public-credentials/2018Feb/0007.html > Topics: > 1. Introductions > 2. Announcements > 3. DID Specification Reconciliation > 4. Crypto Tuesdays > 5. Cryptography Suite Implementations > Organizer: > Kim Hamilton Duffy and Christopher Allen and Joe Andrieu > Scribe: > Lionel Wolberger and Manu Sporny > Present: > Ryan Grant, Dave Longley, Mike Lodder, Nate Otto, Christopher > Allen, David I. Lehn, David Chadwick, Manu Sporny, Ted Thibodeau, > Kim Hamilton Duffy, Moses Ma, Greg Linklater, Dan Pape, Adrian > Gropper, Joe Andrieu, Drummond Reed, Lionel Wolberger, Montgomery > Hart, Ty Danco, Jan Camenisch, Chris Webber, Irene Hernandez > Audio: > https://w3c-ccg.github.io/meetings/2018-02-06/audio.ogg > > Ryan Grant: Does anyone know what the consequences of "one more > DID Spec Closure call" are? > Lionel Wolberger is scribing. > Adrian Gropper: 5C is Adrian Gropper > Christopher Allen: > https://lists.w3.org/Archives/Public/public-credentials/2018Feb/0007.html > Manu Sporny: Remind me of any codes and shortcuts > > Topic: Introductions > > Ty Danco: Hi listening in for first time, from fintech, crypto > enthusiast [scribe assist by Manu Sporny] > Dan Pape: Hi, doing C++ development, working with Ryan Grant > [scribe assist by Manu Sporny] > > Topic: Announcements > > Christopher Allen: Announcements - Next week is focused on > linked data capabilities > ... based on discussions from last RWoT > ... please read final draft of the paper. > ... Implementor's toast > Chris Webber: Also a draft of it in spec form: > https://w3c-ccg.github.io > Christopher Allen: Basic idea is to implement the changes > suggested in the DID reconciliation talks and making sure they > all fit. > Christopher Allen: https://rwot6.eventbrite.com > ... RWoT March 6-9 Santa Barbara. Join the optional golf as > well. url: rwot6 > ... In April 3-5 internet identity workshop, > ... post IIW workshop on the Thurs/Fri at the end. > Kim Hamilton Duffy: 206, 401, 541, 773, 802 > Nate Otto: Ooh, who's the 541? Hey, potential other Oregonian! > Group starts to go over action items. > > Topic: DID Specification Reconciliation > > W3C-CCG to complete reconciliation of #RebootingWebOfTrust & > Hardening changes (All, due end of January > https://github.com/w3c-ccg/did-spec/pull/41) > Ryan Grant: I still owe a pull request, but it's minor broken > references. > Manu Sporny: Going well, one more call needed on service > discovery, maybe also identifiers. > ... the spec is good for implementation, esp the first part > ... implementing on Veres One, no issues yet > Drummond Reed: DID Spec Completion Proposals link (discussed on > the last DID Spec Closure Call): > https://docs.google.com/document/d/1aR8V_JUJdq1Sbi47wCV5aa-dEY0e-V2RqwPNP5ci1bg/edit#heading=h.21shj40jfml > ... to clarify our data verification things. > ... and need a spec text version of ___ > ... David, can we close the work item? David says yes. > ... snaps for everyone, we closed our first work item :-) > ... thanks to David for leading that. > > Topic: Crypto Tuesdays > > ... dive deeper into crypto, encourage cryptographers to > participate, focus feedback on privacy and crypto requirements > ... started a draft on data minimization doc > Manu Sporny is scribing. > Lionel Wolberger: DATA MINIMIZATION PAPER -- > https://github.com/w3c-ccg/data-minimization > Lionel Wolberger: > https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-fall2017/blob/master/topics-and-advance-readings/Data-minimization-and-selective-disclosure.md > Lionel Wolberger: Two papers, the first one is the one we're > migrating towards, CCGs > Lionel Wolberger: Main issues and goals... > 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. > Christopher Allen: Q > 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. > Moses Ma: +1 For Joe's distinctions > 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" > Lionel Wolberger: Adrian: +1 > 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. > Dave Longley: +1 To Joe's comments > Dave Longley: Many business incentives strongly aligned against > zero knowledge systems > Lionel Wolberger: +1 > Christopher Allen: https://w3c-dvcg.github.io/ > 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? > Ryan Grant: +1 To more rigor behind LDS. > 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] > Joe Andrieu: Lost my connection (FYI) > Lionel Wolberger: Lost mine too > 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] > Dave Longley: Data signatures stuff. > 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] > Moses Ma: Oh, a quick thank you to Adrian and Markus for filling > out the History of CCG survey. Please take a look: > http://www.surveygizmo.com/s3/4162124/DID-chapter-contribution > 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. > Ryan Grant: Bye. thanks everyone! > Moses Ma: Bye everyone! > Christopher Allen: Based on proposal by Christopher Webber and > Mark Miller during last RWoT. > > > >
Received on Wednesday, 7 February 2018 23:38:46 UTC