2025-05-12 AnonCreds Working Group Meeting

2025-05-12 AnonCreds Working Group Meeting

Summary

  • Google's "libzk" paper, IETF spec and CCG presentation
  • BBS pseudonymous identifier issue – "forever unlinkability"
  • Results of the AnonCreds v2 Webinar – success!
  • Changing the AnonCreds github organization
  • Open Discussion

Time: 7:00 Pacific / 16:00 Central Europe

Call Link: https://zoom.us/j/94264308304?pwd=uhn8kba2MiIizcVijwfs0K8UoEibqb.1

Recording: https://zoom.us/rec/share/r92kDdmzZwoYh2CzAa_JwZFmGaFUsKlkSrr-py8QnOdYaTdihuVKanLyoWcYjhyv.ZD0TSVsp7BoyisXm

Notices: 

This specification creating group operates under the Linux Foundation Community Specification License v1.0.

antitrust-policy-notice.png

LF Decentralized Trust is committed to creating a safe and welcoming

community for all. For more information

please visit the LFDT Code of Conduct.

Meeting Attendees

  • Stephen Curran (BC Gov / Cloud Compass Computing Inc.) <swcurran@cloudcompass.ca>

Related Specifications and Repositories:

Meeting Preliminaries:

  • Welcome and Introductions
  • Announcements:
  • Any updates to the Agenda?

Agenda

  • Google's "libzk" paper, IETF Draft Standard, and CCG Meeting (recording).
    • Question: Given a VC has been issued with a set of attributes, what is the process to define a verifier's "presentation request" that a holder uses to create a presentation?
      • Related question – what are ZK circuits?
    • Thoughts on the revocation system?
  • BBS pseudonymous identifier issues – forever unlinkability
    • Issue: Given colluding verifiers sharing pseudonymous identifiers and a (future) quantum computer calculation, unlinkability can be broken.
    • Proposals:
      • Document risk in the spec – at minimum.
      • Add in a vector of secrets that would prevent breaking unlinkability up to "n" uses of the credential.
      • Implement a ZKP proof of the pseudonymous identifier.
    • Process for planned solution:
      • Issuer issues a VC signed with a BBS Signature to the holder that contains an attribute that is a unique identifier for the holder. By using the same identifier in different instances of the same credential (say, a driver's license that gets renewed), the PSID to verifiers will remain stable across VC instances.
      • The holder generates a set of N secrets that it associates with the unique identifier attribute and that will be used in sending presentations to verifiers. The holder may decide the value of N, balancing risk of correlation and resources (time, size) in generating/sending the presentation.
      • The verifier sends the holder a presentation request that includes a request for a pseudonymous identifier (PSID) based on the unique identifier. The request includes a context for the PSID for the verifier. The verifier sends the same context for all presentation requests for the same (if you will...) context. Different verifiers send different contexts.
      • The holder generates the PSID and PoK of the PSID using the credential signature, the context and the N secrets and perhaps other cryptographic material.
        The verifier receives the PSID and can verify the PoK of the PSID.
      • A PQ attacker must acquire PSID+PoKs from N (??) presentations from the same holder to be able to correlate the holder.
  • Webinar complete: https://www.meetup.com/lfdt-sf/events/306421109/
  • AnonCreds Quarterly Report
  • Changing the AnonCreds github organization
  • Open Discussion

To Dos:

Action items