W3C home > Mailing lists > Public > public-credentials@w3.org > April 2020

[MINUTES] W3C CCG Verifiable Credentials for Education Task Force Call - 2020-04-27 12pm ET

From: W3C CCG Chairs <w3c.ccg@gmail.com>
Date: Tue, 28 Apr 2020 20:00:32 -0700 (PDT)
Message-ID: <5ea8edd0.1c69fb81.8fe8d.626d@mx.google.com>
Thanks to Nate Otto for scribing this week! The minutes
for this week's CCG Verifiable Credentials for Education Task Force telecon are now available:

https://w3c-ccg.github.io/meetings/2020-04-27/

Full text of the discussion follows for W3C archival purposes.
Audio from the meeting is available as well (link provided below).

----------------------------------------------------------------
CCG Verifiable Credentials for Education Task Force Telecon Minutes for 2020-04-27

Agenda:
  undefined
Topics:
  1. Introductions & Reintroductions
  2. Cryptographic accumulators for privacy-promoting credential 
    verification
Organizer:
  Kim Hamilton Duffy and Joe Andrieu and Christopher Allen
Scribe:
  Nate Otto
Present:
  Mike Lodder, Shivam Sethi, Nate Otto, Eric Welton, Jim Goodell, 
  Chris Winczewski, Kim Hamilton Duffy, Blaž Podgorelec, Uli 
  Gallersdörfer, Allan Third, Simone Ravaoli, Adam Lemmon, James 
  Chartrand, Pave, Hans Pongratz, Alan Davies, Ganesh Annan
Audio:
  https://w3c-ccg.github.io/meetings/2020-04-27/audio.ogg

Shivam Sethi: Present +
Kim Hamilton Duffy: https://www.w3.org/community/credentials/join
Kim Hamilton Duffy: https://www.w3.org/accounts/request
Kim Hamilton Duffy: 
  https://www.w3.org/community/about/agreements/cla/
Kim Hamilton Duffy: https://w3c-ccg.github.io/meetings/
Nate Otto is scribing.
Nate Otto is scribing.

Topic: Introductions & Reintroductions

Alan Third: I work for the Open University on Blockchains and 
  Credentials
S/Alan/Allan_
Kim Hamilton Duffy:  Welcome, we will invite you to present at a 
  future call.

Topic: Cryptographic accumulators for privacy-promoting credential verification

Mike Lodder: 
  https://docs.google.com/presentation/d/10RBfGIyjyKdbmEDkKuM3O1pU5p-UpkiOHlUnZGi8cF4/edit?usp=sharing
Kim Hamilton Duffy:  We'll let Mike present and then turn over 
  for Q&A. Mike implemented "cryptographic accumulators" for the 
  Sovrin system. We're fortunate to have him join us.
Blank is punk rock!
Mike-lodder slide 2 a little bit about me. An independent 
  consultant. Feel free to use these slides in the public domain.
Mike-lodder slide 3. I'll cover the basics of cryptographic 
  accumulators. I'll dive into the crypto, but not very deep. Then 
  how we will apply these to verifiable credentials.
Mike Lodder:  Slide 4. A fast and secure way to "prove set 
  membership". The three types that people are using in production 
  are merkle tree-based, RSA and ECC. The value of an accumulator 
  is a fixed size. It doesn't grow with the more items that are in 
  the set. Verification time is constant regardless of how big the 
  list is.
Mike Lodder:  We can use zero-knowledge proofs, you don't have to 
  reveal what else is in the set. Some methods even allow you to 
  check the position of the item in the set, but most of them you 
  don't need to worry about that, because all you care about is 
  presence of the element you're looking for.'
Mike Lodder:  Slide 5. There are public parameters that everybody 
  is entitled to see in order to create, update, do proofs against 
  the accumulator.
Mike Lodder:  If you think of a revocation list, you still have 
  to have a list of all the elements that are in there
Mike Lodder:  Slide 6: here's some basic math. First, the rule of 
  exponents, remember how these rules work to understand how 
  accumulation occurs.
Mike Lodder:  Modular arithmetic. We create a "finite field" with 
  a limit, so everything happens within the field. In this example, 
  everything we do is mod17 (usually a prime). To do a division, 
  instead you "do a modular inverse". Find a number when you 
  multiply it by the mod is 1. You can think of it as "clock 
  arithmetic". You go around the clock and it resets when you get 
  to more than the mod.
Mike Lodder:  Slide 8: Here are some examples of how cryptography 
  uses modular arithmetic
Mike Lodder:  Slide 9 when we have a finite field, we like to 
  define a generator. A base that when raised to every number less 
  than the mod, I can reach every number in the modulus (gen^n mod 
  x). Generators are important in this work.
Mike Lodder:  Slide 11: Diffie-Hellman example
Mike Lodder:  Diffie-Hellman is used for website traffic 
  encryption. Pick a big prime, then pick a good generator for it.
Mike Lodder:  Diffie-Hellman is a basic computation, but it was a 
  big breakthrough when it was discovered.
Mike Lodder:  RSA works very similar. The person generating each 
  key knows a prime. Find a modulus that is the product of two 
  primes; then calculate modular inverse. You get an encrypt and a 
  decrypt operation. Creating a generator is a bit harder in RSA 
  land because there's an unknown order if you don't know the 
  primes, but can be done.
Alan Davies: Present
Mike-lodder slide 14: I want to bet on a horse, but I don't want 
  to tell people which horse I bet on unless I win, but if I do 
  win, I want to be able to prove that's the horse I bet on. You 
  can create a "blinded commitment", which has good "hiding 
  properties" even if there are big computers working on it.
Mike Lodder:  Slide 15: those are the basics. Now let's talk 
  about accumulators.
Mike-lodder slide 16: RSA Accumulator Example. All accumulators 
  have public properties like RSA modulus (product of two primes of 
  a certain size). Pick "hash to prime number" which converts an 
  input into a prime number. Then there is a hash function like 
  SHA256. Important to use primes because otherwise you could have 
  duplicates in the math. Non-prime numbers used would fail 
  verification checks fast.
Mike Lodder:  The witness in this case is the "value of the 
  accumulator with every other value in the set in there except for 
  the one I'm adding"
Mike Lodder:  Slide 17: what I want to prove is that if I combine 
  my witness and my actual number you get the accumulator. In order 
  to not reveal the value, the prover can add another random 
  generator into the calculation.
Mike Lodder:  Slide 18 and next few slides show you how it works
Mike Lodder:  A verifier doesn't have to do that set of 
  substitution steps through slide 32, they just do the calculation 
  once.
Mike Lodder:  Ok slide 33 why would I use RSA if it's slow? Well 
  it's nice because it lets you do a fixed set of elements or a 
  dynamic set of elements.
Mike Lodder:  Ok slide 34 why use elliptic curves? Because you 
  can use much smaller numbers. Instead of with RSA requiring a 
  certain number of bits, elliptic curves let you use much smaller 
  number of bits.
Mike Lodder:  Slide 36: vocabulary for elliptic curves are 
  scalars and points. Standard notation for these.
Mike Lodder:  The same primitives work, with the operations we 
  discussed before.
Mike Lodder:  Some elliptic curves allow a new operation called 
  "pairing". Those are "pairing-friendly curves".
Mike Lodder:  Slide 38? Downside is it only works with a fixed 
  set of elements. Sovrin has a very large "tails file". Everything 
  else other than the public parameters are nice and quick.
Mike-lodder slide 39: Elliptic curve accumulators accumulate 
  signatures. Witness is really easy to compute, you just "add and 
  subtract points". An attacker would go through a lot of 
  computation to determine whether or not my value is in there.
Mike Lodder:  Slide 41: merkle tree accumulators. Values in the 
  set are "leaves" and then everything else is  a hash (or whatever 
  you need it to be, as long as you're consistent). The "witness" 
  is just "the path to the root" -- you don't have to care about 
  anything else in the tree.
Mike Lodder:  Slide 43: in order to do these in zero knowledge 
  you need to use some proofs, such as "Bulletproofs, STAKRs or 
  SNARKs". Merkle trees can be dynamic or fixed, so similar to RSA 
  ones in that respect.
Mike-lodder slide 44: how would I use an accumulator in a 
  verifiable credential? You could say one or more attributes in a 
  credential is in an accumulator. For instance, you can check 
  whether a credential is revoked or not. Observer only sees which 
  registry was checked, not which credential was checked for 
  revocation.
(This is also a capability of an HTTP hosted list of revoked IDs, 
  except that clients don't get to see what the IDs of all the 
  revoked items in the set are)
Mike-lodder slide 45: This isn't just for revocation. It could be 
  to check any attribute in a credential to see if it's in a set or 
  not. The only limit is your imagination in terms of what you can 
  do with set memberships.
Mike Lodder:  Slide 46 some example deployments.
Mike Lodder:  Slide 48 has links to papers, on how to do 
  cryptographic accumulators.
Kim Hamilton Duffy:  I'll ask the first question. I want to ask 
  about when updates need to happen. I'm curious if you can walk me 
  through about: say, what happens is you're using an accumulator 
  to track which credentials have been revoked. Suppose you're 
  using the credential ID. How does a revocation get pushed or 
  queried? If you are the one whose credential was revoked, how do 
  you learn?
Mike Lodder:  A credential issuer doesn't compute the witness; 
  the holder does. The issuer only cares about maintaining the list 
  of issued or revoked credentials. Every time a credential is 
  issued, a value is added, every time a credential is revoked, a 
  value is removed (scribe note: does that mean added to a revoked 
  accumulator?). As a holder, you don't want to leak either your 
  witness or your actual value. If you didn't care about the 
  privacy of those
Things, you wouldn't need to use an accumulator.
Mike Lodder:  The holder could observe the accumulator value and 
  if something changes, they might need to update the witness.
Kim Hamilton Duffy:  Another question, could you walk us through, 
  in hyperledger implementations how ECC, RSA or Merkle were chosen 
  for different implementations. Could you go into more details 
  about the factors leading to that decision?
Mike Lodder:  At the time that Hyperledger Indy 1.0 was written 
  SNARKs were very new. We wanted to do zero knowledge proofs of 
  set memberships and couldn't do it at the time in 2016 with 
  merkle trees. So Indy chose to use Elliptic Curves to keep the 
  values small, because every time the accumulator updated, we 
  didn't want to be posting 2k or 4k accumulator values. It's 
  smaller and faster to compute the proofs than RSA was.
Mike Lodder:  There's two different ways you can do ... the 
  accumulator. You can "add every time you issue" "remove every 
  time you revoke". One way to do it is put a bunch of numbers in 
  there originally and an issuer when they issued would just "grab" 
  one of those IDs and not need to update the accumulator. Only 
  update needed when revoked.
Mike Lodder:  For something like device registrations (tracking 
  laptops held by employees), we ... made an accumulator with a 
  very large number of primes in it.
Mike Lodder:  One other consideration with merkle trees, if you 
  change your fanout (to avoid getting too deep of a tree) you have 
  to recalculate everything. We're choosing Merkle Trees with 
  SNARKs to now be able to cover 1000x the number of items in a 
  set. With this approach you could calculate the revocation case 
  in 1sec even if there are 4billion records in the set
Kim Hamilton Duffy:  I had been thinking about revocation a lot, 
  but it was good to hear these other use cases as well. For 
  instance, revocation could be used on the individual attribute 
  level
Simone Ravaoli: +1 To Nate for an incredible scribing job...  
  almost like a #NateBot
Mike Lodder:  You could say "attribute3" corresponds to "labs you 
  have access to in the facility". It doesn't reveal other things 
  about the credential or the recipient. The reason to use an 
  accumulator is usually because the sets are very large. It 
  doesn't generally get slower to verify as the set grows.
Nate Otto:  You made references to revocation case, i.e. 
  removing. but often these are published to blockchains [scribe 
  assist by Kim Hamilton Duffy]
Kim Hamilton Duffy: ...Can you tell us what that looks like? are 
  you posting a new value?
Mike Lodder:  Most issuers will update once per day. verifer will 
  need to say it's not revoked as of 24 hours ago [scribe assist by 
  Kim Hamilton Duffy]
Kim Hamilton Duffy: ...Issuers write new value with some 
  regularity
Kim Hamilton Duffy: ...Because timestamped, verifier can ensure 
  not revoked within time interval
Nate Otto:  Need a way to find where latest value is published 
  [scribe assist by Kim Hamilton Duffy]
Mike Lodder:  That can be in the credential through json-ld, etc 
  [scribe assist by Kim Hamilton Duffy]
Kim Hamilton Duffy: ...All that matters is parties know
Kim Hamilton Duffy:  You talked about time "an accumulator value 
  from the last 24 hours". Did you have to deal with the scenario 
  where somebody is querying older copies of accumulators. Was this 
  credential valid last year?
Mike Lodder:  Yes, you can do a proof against any time or dated 
  (accumulator value) that you could pull up (say, from a 
  blockchain)
By_caballero: [audio very choppy]. ...
Hahaha sorry
I was asking if anyone at aries is working on
How to look up accumulators elsewhere than on indy?
Awesome, thanks
Mike Lodder:  As in is there open source code that does it. If 
  you look at the https://cambrian.dev/accumulator/docs you'll see 
  some code in Rust. There has been some work done with it outside 
  of the Indy&Aries community.
Kim Hamilton Duffy:  We're at time. Thank you for the 
  presentation and for joining us.
Thanks nate!
What an ottoscribe
Received on Wednesday, 29 April 2020 03:00:48 UTC

This archive was generated by hypermail 2.4.0 : Thursday, 24 March 2022 20:24:58 UTC