# Session 1

Review the problems and find user stories

## 1. Reusable proofs
User stories
- I prove a high value transaction. The verifier leaks the proof. Now everybody knows I have a lot of money
- I'm a member of a politically affiliated group. I use a membership proof to attend an event, but I don't want this proof to be used in the future to publicly-verifiably link me to this group.
## 2. Composable verifiable credentials
We identified three cases:
- composability while keeping the **verifier efficient**
- composability while keeping **privacy**
- composability of credentials
- take many credentials and create 1 presentation
- composability of presentations
- take many presentations and create 1 presentation
- multi-party composability
- Sub problem
- root of trust with multiple issuers used in a composed presentation
User stories:
- **privacy**
- Prove that you do live in a country which is in a non-sanction list. Do not show which country. This uses different country identity systems that use different standards.
- **verifier efficiency**
- In Semaphore you want to prove that you attended all devconnect events, but you don't want to pay more gas price in the smart contract.
## 3. Issuance-presentation linkability
User stories:
- I get a government ID. I use it to prove I'm over 18 to enter into a bar. I don't want the government to know I went to the bar.
- In anon adhaar, to avoid having credentials used by a third person they need to be freshly issued. This causes the holder to request a credential at the time of verification, which creates a issuer-verifier correlation.
- As a user I ask the issuer to sign a credential of mine, and I don’t want to issuer to potentially track my activity by checking a specific attribute of the gave credentials (e.g., issuance timestamp, specific attribute that minimise the size of the anonymity)

## 4. Revocation
User stories:
- [Verifier] I have a rental car service and I want to allow people to rent a car with minimal disclosure from their part. I want to privately check that their driving license is valid (not revoked due to driving infractions)
- [Holder] My credential was stolen and I want to prevent it from being used to spend any of my funds. We have to achieve this without having the presentation be linkable by the issuer.

## 5. eIDAS 2.0 alignment

# Session 2

Choose a problem and research

- Reusable proofs
- Solutions exists
- but are they practical in the real world?
- Solution is broken with the TEE attack
- can it be solved?
- Composable verifiable credentials
- in the single party context: already solved by POD2
- Inssuance-Presentation Linkability
- not interested
- Revocation
- high impact

we choose Revocation.

## Research on Revocation
- existing solutions:
- short expiry dates: unlinkable by verifier, but may be linkable by issuer
- public revocation lists: unlinkable by issuer, but requires either prover / verifier to be online
- w3c's Bitstring Status List https://www.w3.org/TR/vc-bitstring-status-list/
- CRSet https://arxiv.org/pdf/2501.17089, considers issuer privacy
- "20250609 Improving AnonCreds v1 Revocation" https://docs.google.com/presentation/d/1fhwA3uP4XXTqOj5442IbwUS5iFcjagYXFwIB8ADFnGs/edit?slide=id.p#slide=id.p
- iden3 https://docs.iden3.io/getting-started/claim-revocation/
- https://docs.iden3.io/protocol/spec/#revocation-tree
- EUDI revokation requirements: https://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.4.0/annexes/annex-2/annex-2-high-level-requirements/#a2338-topic-38-wallet-instance-revocation

### Privacy in the context of Revocation
- Issuer (See CRSet for related research)
- Not reveal which credentials are revoked
- Not reveal how many credentials are revoked
- Not reveal when credentials are revoked
- Holder (traditional point of view)
- Not reveal usage of credential to the issuer
- Not reveal usage of credential to the verifier
- Verifier
- ???


### Requirements from deployment context
- online requirements for prover / verifier
- storage / compute requirements for prover / verifier
- issuer resources -- how frequently do they have to re-issue credentials?

# Session 3

> Introduction to user requirements and types of constraints (privacy, latency, regulatory, UX)
> Groups draft user personas, write stories, and define constraints
> List of user needs, pain points, regulatory/technical constraints. Present in 1 pager with all the relevant links.

Dimensions of credential systems
- Time (long-lived VS short-lived)
- Support type (physical VS digital)
- Responsiveness of the Issuer

Assumptions
- We can define a protocol that requires changes in the issuer

## Constraints

### Privacy
- issuer doesn't learn when/which holder is using the credential
- timing correlation
- id deanonimization
### Regulatory
- regulatory needs offline verification
- can we get offline verification and decentralization?
- yes: the issuer can sign the revocation set commitment with a timestamp
- offline holder
- offline verifier
### UX
- when user wants to prove a non-revoked credential it shouldn't take a lot of time or bandwidth
- the system should work on milions of credentials
- the system should work on mobile phone
- in a web browser
### Others
- offline issuer
- the holder should be able to present credentials even if the issuer is offline
# Session 4

## Status quo
- Taiwan digital wallet project hasn't defined a revocation mechanism
- eIDAS will skip revocations and instead do short-lived credentials
- Current problems with revocation: https://www.linkedin.com/pulse/arf-v15-five-things-watch-eidas-revocation-andrew-tobin-bqb9e/
- Existing w3c Bitstring Status list: https://www.w3.org/TR/vc-bitstring-status-list/

## Problems
Scenarios
- (A) online holder, online verifier
- (B) online holder, offline verifier
- issuer signs a commitment to the revocation set with a timestamp. holder forwards it to verifier. holder proves non-inclusion in the revocation set to the verifier.
- (C) offline holder, online verifier
- this could be a physical credential like a card with no phone
- (D) offline holder, offline verifier
- if holder can be online from time to time: there's a time window of accepting a revoked credential
- if holder can't be online at all: no revocation possible? only short-lived credentials

### (B) online holder, offline verifier

Existing solutions (privado ID) involve:
- issuer regularly commits to the revocation set with a merkle tree
- at presentation time, holder obtains a non-inclusion proof of their credential in the revocation set

How does the holder get the non-revoked proof while maintaining unlinkability?
- If the non-inclusion proof is calculated by the issuer
- the issuer learns about the credential used
- If the non-inclusion proof is calculated by the holder
- If the holder downloads the entire revocation set at presentation time (download only the new values of the set)
- the issuer learns timing correlation
- the holder requires high bandwidth for big revocation sets
- If the holder regularly downloads the entire revocation set (download only the new values of the set)
- the holder requires higher bandwidth for big revocation sets
- the holder requires high storage for big revocation sets

The problem:
- How to reduce the holder load (cpu, bandwidth, storage) while keeping unlinkability?
Solutions:
1. Privacy preserving way to obtain non-inclusion proof
- PIR to retrive the non-inclusion proof
- Oblivious syncing service
- a privacy-preserving service for generating non-inclusion proofs
2. Tree forest: the issuer calculates a partial merkle proof to a subtree, the holder calculates the rest of the merkle proof
- shares the computation between holder and issuer
- reduces bandwidth
- reduces anonimity set
3. Co-snark to calculate the non-inclusion proof between holder and issuer
4. Don't use a revocation mechanism and instead have short-lived proofs
- only useful in some particular use-cases
5. Nullifiers / revocation tokens
- nullifier has to be unlinkable, i.e. a function of some prover-generated nonce
- after a credential is revoked, have to revoke all future nonces


- https://github.com/zcash/incrementalmerkletree

---

# Telegram log

## ying tong, [25 Jun 2025 13:10:33]
Privacy requirements:
- holder privacy
- issuer metadata privacy

Performance requirements:
- online prover/verifier
- bandwidth / computation as a function of the size of the revocation list

## ying tong, [25 Jun 2025 13:29:25]
https://www.researchgate.net/profile/Michael-Hoelzl/publication/326163883_Bridging_the_gap_in_privacy-preserving_revocation_practical_and_scalable_revocation_of_mobile_eIDs/links/5b3f55c4a6fdcc850600eeba/Bridging-the-gap-in-privacy-preserving-revocation-practical-and-scalable-revocation-of-mobile-eIDs.pdf

## ying tong, [25 Jun 2025 13:55:41]
We may also want to support temporary revocation e.g. suspending a driver's license

## ying tong, [25 Jun 2025 13:58:48]
Would be cool to come up with some impossibility results e.g. "either prover / verifier needs to be online"

## ying tong, [25 Jun 2025 15:29:29]
"Oblivious syncing service"

We already know that this kind of approach is possible with expensive cryptography like fully-homomorphic encryption (FHE). But by adjusting the protocol slightly we can simply use PCD. The remote server only needs to learn the nullifier of the note to make synchronization progress without the assistance of the user's wallet, since the wallet can blind or encrypt the rest of the wallet state and only permit the oblivious syncing service to make state transitions involving the nullifier. One would expect this to reveal some information to the service about the note's possible location in the accumulator, but by adjusting how the nullifier is derived in the protocol16 we can eliminate this information leakage entirely, depriving the service of any information about the note being spent.

https://seanbowe.com/blog/tachyon-scaling-zcash-oblivious-synchronization/

## Vivian Plasencia, [25 Jun 2025 15:40:59]

For the presentation

## ying tong, [25 Jun 2025 15:51:50]

RIP "We leave a more thorough investigation of zk-creds-compatible revocation techniques to future work"

https://eprint.iacr.org/2022/878.pdf

## ying tong, [25 Jun 2025 16:16:07]
https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/main-51.pdf

## ying tong, [25 Jun 2025 17:00:53]
Considering the variety of use-cases and requirements, I'm thinking a careful mapping + support for hybrid solutions would make sense, e.g.:

## ying tong, [25 Jun 2025 17:09:37]
"The anonymous credential system uses the SObtSig ↔️ SIssSig protocol to issue a credential with the following information to the user: the users secret skU , the credential serial number id, the time period for which the credential is valid t, and d attributes a1, . . . , ad chosen by the issuer."

This is just expiry tbh

## Zoey, [25 Jun 2025 18:51:15]
https://github.com/decentralized-identity/labs/blob/main/proposals/beta-cohort-2-2025/pp-revocation-mechanism/001_proposal.md

## Zoey, [26 Jun 2025 08:58:53]
https://x.com/secparam/status/1938063395531391380?t=pSQx7udYSmAyW22snUpWqQ&s=19