22B/ A Useful Revocation Scheme for BBS+ VCs

From IIW

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

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:

  • [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