W3C home > Mailing lists > Public > public-credentials@w3.org > February 2018

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

From: <msporny@digitalbazaar.com>
Date: Tue, 06 Feb 2018 14:38:41 -0500
Message-Id: <1517945921116.0.9891@zoe>
To: Credentials CG <public-credentials@w3.org>
Thanks to Lionel Wolberger and Manu Sporny for scribing this week! The minutes
for this week's Credentials CG 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).

Credentials CG Telecon Minutes for 2018-02-06

  1. Introductions
  2. Announcements
  3. DID Specification Reconciliation
  4. Crypto Tuesdays
  5. Cryptography Suite Implementations
  Kim Hamilton Duffy and Christopher Allen and Joe Andrieu
  Lionel Wolberger and Manu Sporny
  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

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: 
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: 
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 
Ryan Grant: I still owe a pull request, but it's minor broken 
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): 
  ... 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: 
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 
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 
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 
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 
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 
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 
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 
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 
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, 
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 
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 
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 
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 
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 
Moses Ma: Oh, a quick thank you to Adrian and Markus for filling 
  out the History of CCG survey. Please take a look: 
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 Tuesday, 6 February 2018 19:39:04 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 11 July 2018 21:19:44 UTC