UofT Anonymous Credentials

There are often scenarios online where users want to show who they are without being tracked or revealing additional details about their identity. A common example of this is proving you are over the age of 18 without giving up your address, name, or other sensitive information found on your ID.

In the context of UofT, suppose that you are a graduate student who wishes to access university-funded counselling services for a conflict you are having with your academic supervisor. However, you wish to remain anonymous throughout the process. Currently, there is no way for students to access university services anonymously. Thus, we propose and evaluate UofTAnonCreds.

Anonymous Credentials Primer

The simple model we work with is as follows: There are issuers, holders, and verifiers. In our case, the issuer (UofT) is responsible for issuing anonymous credentials to users (holders). Credential holders (in our case, students and staff at the university) can then present these credentials to verifiers to prove specific predicates about themselves. The trust in this system exists between the verifiers and the issuers, and is based on cryptographic assumptions.

There are two main properties that are of concern in our examination of anonymous credentials:

1. Selective Disclosure: Using zero-knowledge proofs to prove predicates without revealing any additional information (for example, proving that a user's age is greater than 18)
2. Unlinkable Disclosure: Verifiers cannot share information to correlate data between presentations to try and discern a user's identity.

An ongoing concern is the revocability of anonymous credentials, specifically regarding the tradeoffs between different schemes and their performance/scalability. In the context of UofT, we must consider what happens if a student graduates, gets expelled, or faces other circumstances that warrant restriction of access. There are over 100,000 students and staff at the University of Toronto, thus in our system, scalable revocation in a necessity.

Research Questions

Our research was guided by the following overarching questions:

1. What frameworks exist in the anonymous credential revocation space?
2. How is revocation currently implemented in existing systems?
3. Can we evaluate alternative revocation strategies with existing frameworks to improve scalability?

Other tools

There were several other tools and libraries we attepted to use based on our proposal. Unfortunately, due to the nature of the anonymous credentials space and how most of these tools are new, our attempts with these tools were generally unsuccessful.

The initial plan was to use MDOC-based credentials since that was defined as an ISO standard and supported by Apple and Google. We expended a substantial amount of time trying to leverage Google's new LongFellow-ZK library for our credentials. Unfortunately it did not work, and we submitted issues on their GitHub repository where other users reported encountering similar problems.

Additionally, we tried the Multipaz Open Wallet library, but were again unsuccessful. We found incomplete documentation regarding revocation, and upon inspecting the GitHub repository, saw that it was still undergoing initial development stages.

Neither of the options explored above provided enough of a basis for us to use/compare/contrast/benchmark revocation approaches for our project, so our search continued.

AnonCreds Libraries

Finally, we came across the AnonCreds v2 library. It seemed reputable as it was developed in collaboration with the provincial government of British Columbia and a company called LIT Protocol. It also seemed more fleshed-out as a framework compared to LongFellow-ZK and Multipaz Open Wallet since it was building on a v1 of their work, which already had seen some adoption.

AnonCreds v1 was a "code-first" specification, in that it took a very opinionated approach to anonymous credentials. While most frameworks require extensive setup and knowledge of the underlying cryptography, AnonCreds v1 made all the hard decisions for users. All developers had to do was add in their use case, thus the only data they were interacting with was plaintext. It was adopted because it was accessible.

AnonCreds v2 used the same objects, high-level interactions (issuing, holding, requesting, presenting, and verifying), and opiniated features as v1. The main difference was pluggable signature schemes, emphasizing the use of newer BBS signatures because they allow multiple proofs in one (smaller) signature. It also has support for post-quantum signature schemes. Most importantly, however, is that revocation is a working feature in v2 - so we can conduct our research and benchmarking based on this library!

More on Anon Creds?

Details about accumulators and the architecture etc.?

Demo-related stuff

Benchmarking

Setup / Methodology

Results

Limitations and Future Work

References (TODO)

Images https://www.vecteezy.com/vector-art/583708-online-shop-icon-vector https://www.istockphoto.com/vector/single-man-stick-figure-icon-gm2022468311-561503485 https://www.dreamstime.com/illustration/government-silhouette.html