Re: [MINUTES] W3C Credentials CG Call - 2018-02-06 12pm ET

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.
>
>
>
>