22B/ A Useful Revocation Scheme for BBS+ VCs
A Useful ZKP Revocation Scheme for BBS+ VC
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
(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
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?
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
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