22B/ A Useful Revocation Scheme for BBS+ VCs

A Useful ZKP Revocation Scheme for BBS+ VC

Thursday 22B

Convener: Stephen Curran / Andrew Whitehead, Government of British Columbia

Notes-taker(s): Sebastian Schmittner, EECC

Tags for the session - technology discussed/ideas considered:

Revocation, BBS+, zk-SAM,

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps: 

Presentation by Stephen Curran :

>> Slides <<

Non revocation token using zk-SAM

• zk-SAM = zero knowledge Signed Accumulator Members

• Diskussion on Registry file size. Obviously linear in # credentials.

• Indy (Sovrin): Writing Registry to ledger -> $$ -> Business Decision

• Links

  • Basic approach: https://hackmd.io/kj223D1ZQN29WiusmnPFMA

  • The math: https://hackmd.io/vTyqrJc9QoKgThqQpVtP3g

  • Starter repo: https://github.com/andrewwhitehead/bbs-accum

Andrew's Idea:

(better look at the presentation than at these few additional points ;) )

• Akkumulator = Product of primes, one for each non-revoked VC

  • Check if accumulator is divisible by VC prime to check whether it has been revoked

  • Accumulator blocks -> smae primes in every blocks (corresponding to different VCs of course)

  • ZKP: Do not expose block / index while proving that a VC is not revoked

• Similar to Indy AnonCreds Revocation with Tails files

• VC -> Block + Member Index (prime number) in the registry

  • Opaque signed + shared

• Registry state: set of fully revoked (0), fully non revoked (product of all primes- all the same) and interesting: partially revoked blocks

• Timo Glastra:

  • This is a really understandable explanation of witnesses and accumulators: https://hyperledger-indy.readthedocs.io/projects/hipe/en/latest/text/0011-cred-revocation/README.html

• [Metrics -> see slides]

• There is a proof of concept implementation

• Why this method? Others considered?

• Christian Panquin:
  For background, here is a white paper about various revocation approaches we prototyped a while back with U-Prove, including an accumulator scheme close to this one. https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/Privacy20and20accountability20-20best20of20both20worlds.pdf

• Andreas Freitag: Balancing various target functions, in particular efficiency

  • Working Group in DIF evaluating the options

    • Crypto security

    • Privacy (non correlatability)

    • Performance KPIs (metrics)

  • Need objective (empirical) comparison

  • Interested Cryptographers and Developers: Please join the DIF WG!

• Rouven: Revocation as a service? Trust implications?

  • Stephen: Issuer needs to sign the revocation registry state! - no good as a service (other than CDN)

  • Rouven: Multi Key?

  • Stephen: msgs in VC must be signed with same key as the revocation registry

  • Andreas: Needs to be part of the Issuing Service!

• Andreas: Are you using revocation, Stephen?

  • Indy. -> Small Use Case

  • 12k Lawyers in BC

  • But almost every use case needs to have revocation -> non-avaiable revocation blocks use cases

• Andreas/Christian: "I am valid today credentials"

  • VC with expirey date just saying: that other credential is still valid

  • Keep re-issuing still valid credentials

  • A lot of load on the issuer for issuing lots of still valid credentials often

• Need Options for how to do revocation/non-revoked proofs to choose from