## Introduction

A key goal in the use of digital credentials is that the issuers give credentials to holders, and the holders share the credentials with whomever they choose, without the knowledge of the issuers. A challenge in the acceptance of digital credentials, particularly those credentials issued by governments, is if the issuer tracks, or is perceived to track, the use of credentials by holders.

In the use of unlinkable credentials, such as AnonCreds, the feature that could lead to Issuer tracking, or the perception of tracking, is revocation. In order to create a presentation that includes the revocation status of their credentials, holders must have reasonably up-to-date revocation data about those credentials. In practice, that means each time they share their data in a presentation, they have to collect revocation data. If the issuer is, or is perceived to be, the provider of that data, then tracking (or the perception of tracking) is possible.

A ledger is used to mitigate that risk -- a neutral, disinterested party providing revocation data when needed. However, when a non-ledger approach is used, such as `did:web` (or `did:webs`), or the ledger is operated by the issuers themselves, that mitigation is lost.

This paper proposes that instead of the holder retrieving the necessary revocation data from the provider, the verifier does that, and provides it to the holder. In that way, any tracking or perception of tracking is of the verifier, not the individual holders.

## Approach

This section describes the proposed approach by first reviewing the flow of the existing AnonCreds approach, along with some notes and conditions that impact both the current and proposed approaches. Following that is the proposed flow of the verifier collecting and providing the holder the needed revocation data. Some process shortcuts that are possible in some circumstances are provided.

### Current Approach

We'll look at the impact of this by starting with the typical, slightly simplified version of what is done today in AnonCreds when presenting revocable credentials, and see how the flow changes with this new approach. Included are the user experience elements of this -- when the user of the Holder software is (typically) involved in the process.

sequenceDiagram
participant Revocation Data Provider
participant Verifier
participant Holder
actor User
Verifier -->> Holder: Presentation Request
Holder -->> Holder: Select Credentials for Presentation
Holder -->> Revocation Data Provider: Fetch Revocation Registry State
Holder -->> Holder: Construct Presentation
Holder -->> User: Do you want to share data?
Holder -->> Verifier: Presentation
Verifier -->> Revocation Data Provider: Fetch Revocation Registry State
Verifier -->> Verifier: Verify Presentation

In that flow, here are some notes and conditions that can occur:

- The verifier may be asking for multiple credentials, any or all of which might have revocation. As such, there may be multiple calls to fetch revocation registry states.
- The verifier may not know what credentials a holder will use to satisfy the presentation request -- what issuers, and whether or not the credentials used will be revocable or not.
- Issuers may have published many revocation registries for a credential they issue, and so even if the verifier knows the credential(s) they are asking for, they will likely not know what revocation registry the holders credential is in.
- This is particularly true of AnonCreds v1.0 in use cases where the number of issued credentials is much larger than the practical number revocation registry size (~5000 to 10000 credentials/registry).
- This is less likely with large sized revocation registries, such as are possible with zk-SAM (~1M or more credentials/registry)
- The verifier must use the same revocation registry states as the holder to verify the revocation-related proofs.
- The holder may not know until they have the revocation registry states if any of the credentials they intend to use to respond to the presentation request have been revoked.

### Proposed Approach

In the proposed approach, the responsibility for retrieving the revocation registry state is assigned to the verifier, and the verifier passes those states to the holder. Since (as noted in the previous section), the verifier (likely) does not know at presentation request time the credentials and revocation registries the holder will use in the presentation, an extra back-and-forth is needed. After getting the request, the holder determines the revocation registries it needs to create the presentation, and sends those to the verifier. On receipt, the verifier retrieves those revocation registry states and sends them to the holder. The holder can then complete the generation of the presentation and send the presentation to the verifier for verification. This is shown below.

sequenceDiagram
participant Revocation Data Provider
participant Verifier
participant Holder
actor User
Verifier -->> Holder: Presentation Request
Holder -->> Holder: Select Credentials for Presentation
Holder -->> User: Do you want to share data?
Holder -->> Verifier: Revocation Registry Needed
Verifier -->> Revocation Data Provider: Retrieve Revocation Registry State
Verifier -->> Holder: Provide Revocation State
Holder -->> Holder: Construct Presentation
Holder -->> User: If revoked: Do you REALLY want to share data?
Holder -->> Verifier: Presentation
Verifier -->> Verifier: Verify Presentation

The following shortcuts are possible with this approach, based on various conditions related to the presentation:

- If no revocable credentials are used in the presentation, there is no need for the holder to request any revocation registries states from the verifier, and that part of the protocol can be dropped. The holder simply responds to the request with the presentation.
- If the verifier restricts the specific credentials that must be in the presentation, and the number of revocation registries is small for those credentials, the verifier could include the revocation registry state with the initial presentation request. That would eliminate the back and forth to request and retrieve the revocation registry state.
- This is a more likely possiblity when using a revocation registry with a large size, such as with the zk-SAM revocation scheme.
- If the verifier has an acceptable cache of the revocation state needed by the holder, they could use that instead of retrieving the registry state from the revocation data provider during the process.
- In providing the revocation data to the Holder, there MUST be some proof that the data is valid. For example, a signature of the issuer or the state proof provided by an Indy network.
- The holder will still be able to retrieve the revocation data themselves when necessary. This might be used to:
- Do periodic checks to see if their credential has been revoked by the Issuer, independent of presentation requests. This would not be needed if the Issuer informs the Holder when their credential has been revoked.
- In the case of a suspected malicious verifier, confirm with data directly from the source if a credential has indeed been revoked.

Note the more complex user interactions for the Holder User. They first must decide if they want to share the data with the verifier, possibly without knowing that credentials they intend to use are revoked. Later, it is possible that in constructing the full presentation, they learn that one or more of the credentials they intend to share are revoked. In that case, they would likely be asked again if they want to share the data.

## Appendix A: Why Revocation Could Lead to Tracking

When unlinkable (ZKP-based) revocation is involved, it may be harder to achieve that issuer non-involvement in the use of digital credentials, depending on how the issuer publishes the revocation data.

Issuers of revocable credentials periodically publish updates to the set of credentials that they have issued and subsequently revoked. Typically, verifiers want to know that presented revocable credentials have not been revoked at the time they are presented -- in (more or less) real time. That means that the holder must retrieve the latest revocation data from wherever the issuer has published it, and use that to construct a proof about the revocation status of their credential. With an unlinkable (ZKP based) revocation proof, they do that without sharing a unique identifier for their credential. If there is a way to track the holders collection of the revocation data -- even if it is just a perception of tracking -- confidence in digital credentials is undermined. For example, if every time a mobile Wallet contacts a location on the Internet related to the issuer (e.g. same Internet domain) to get revocation data, the owner of the wallet may come to the conclusion that their use of credentials is being tracked. Worse, if immediately after the holder collects data from the site, the verifier does the same, it could be possible (or a perception) that the holder of the revocation is tracking when a holder uses their credentials and where.

### Schemes Where This Approach Can Be Used

There are a number of schemes for unlinkable revocation that rely on the holder getting revocation-related data from a source, and then generating a proof. For example, the current AnonCreds v1.0 approach requires the holder to get the current accumulator and deltas (changes to the credential revocation status) for the credentials in a given Revocation Registry. These are candidates for this approach.

* AnonCreds vl.0 -- CKS Signatures
* BV Signatures
* zk-SAM

There are also schemes that use services to provide the necessary revocation-related data, and these schemes would not be able to use this approach. Note that with these techniques, the Issuer, or a collaborator is the provider of the revocation data, and the possibility of tracking is higher. We don't have a mitigation proposal for these revocation schemes.

* ALLOSAUR
* LVVM