§ AnonCreds Specification

Specification Status: v1.0 Draft

Latest Draft:

https://github.com/hyperledger/anoncreds-spec

Editors:

• Stephen Curran
• Mike Lodder
• Aritra Bhaduri

Participate:

GitHub repo

Commit history

Discord

§ Abstract

This paper discusses the requirements for a revocation mechanism in AnonCreds, a system that supports the issuance and verification of verifiable credentials. The revocation mechanism aims to allow the holder of a credential to prove its non-revocation without revealing any correlatable identifiers. This paper presents the data flow involved in the revocation process, including issuer setup, credential issuance, activation/revocation, presentation request, and verification. With each part of the process are defined the privacy, security, and practical requirements of a suitable AnonCreds revocation scheme.

The paper covers the following elements of verifiable credential revocation.

1. Introduction

• Background and motivation
• Objectives of an AnonCreds revocation mechanism

2. AnonCreds Issuer Setup With Revocation

• Creation and publication of a revocable Credential Definition (CredDef)
• Establishment of a Revocation Registry for tracking revocation status
• Ability to create additional Revocation Registries as needed

3. AnonCreds Issuance with Revocation

• Assignment of a RevocationId to each issued credential
• Correlation of RevocationId with the holder for revocation purposes
• Importance of not sharing RevocationId with verifiers

4. AnonCreds Credential Activation/Revocation and Publication

• Revocation process initiated by the issuer
• Update of the Revocation Registry to mark revoked credentials
• Publication of RevRegEntry depending on the revocation scheme
• No technical requirement for issuer-to-holder notification of revocation
• Holder’s ability to detect revocation through proof creation

5. AnonCreds Presentation Request with Revocation

• Request from verifier to holder for a non-revocation proof (NRP)
• Creation of NRP by the holder, including cryptographic link to the source credential

6. AnonCreds Verification with Revocation

• Verifier’s processing of non-revocation-related parts of the presentation
• Verifier’s processing of revocation-related parts of the presentation
• Combination of verification outcomes from all proofs in the presentation
• Rejection of unverifiable presentations due to unsuccessful proof verification

7. Conclusion

• Summary of the revocation data flow in AnonCreds
• Implications and benefits of the revocation mechanism
• Future research directions and potential enhancements

References: Include all the references cited throughout the paper.

Keywords: AnonCreds, verifiable credentials, revocation mechanism, issuer, holder, verifier, Credential Definition, Revocation Registry, RevocationId, non-revocation proof, proof verification.

§ Status of This Memo

This is document describes the requirements for a revocation scheme suitable for use by AnonCreds.

This document is a product of the AnonCreds Working Group. It represents the consensus of the AnonCreds community.

Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at https://github.com/hyperledger/anoncreds-revocation.

§ Copyright Notice

This specifications is subject to the Community Specification License 1.0 available at https://github.com/CommunitySpecification/1.0.

If source code is included in the specification, that code is subject to the Apache 2.0 license unless otherwise marked. In the case of any conflict or confusion within this specification between the Community Specification License and the designated source code license, the terms of the Community Specification License shall apply.

§ Introduction

AnonCreds must support the revocation of Credentials issued to Holders by Issuers. The scheme used to support revocation must not compromise the AnonCreds privacy and security considerations,a nd must be practical for the expected characteristics of AnonCreds participants: issuers, holders and verifiers. This document defines the requirements for a suitable AnonCreds revocation scheme.

§ Requirements, Notation and Conventions

The key words “MUST”, “MUST NOT”, “REQUIRED”, “SHALL”, “SHALL NOT”, “SHOULD”, “SHOULD NOT”, “RECOMMENDED”, “NOT RECOMMENDED”, “MAY”, and “OPTIONAL” in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.

§ Terminology

§ AnonCreds Revocation Data Flow

AnonCreds includes a mechanism that supports the revocation of verifiable credentials. This mechanism includes:

• An issuer setting up to issue revocable credentials.
• An issuer issuing revocable credentials.
• An issuer activating or revoking issued credentials.
• A verifier requesting a presentation to include a non-revocation proof for one or more revocable credentials.
• A holder generating based on the presentation request of the verifier a non-revocation proof for attributes derived from revocable credentials.
• A verifier verifying a non-revocation proof included in a presentation from a holder.

A fundamental goal of AnonCreds is to not provide a correlatable identifier for either a holder or a credential as part of generation and verification of an AnonCreds presentation. Applying that goal to revocation means that the revocation mechanism must support the holder proving a credential used in generating a presentation is not revoked without providing a correlatable identifier for that credential or the holder itself. As such, an AnonCreds revocation mechanism must use some sort of Zero Knowledge Proof (ZKP) that allows the holder to prove a credential they hold is not revoked without revealing an identifier for their credential or for the holder themselves.

In the following, we describe the basic flow that must be supported by any revocation scheme suitable for AnonCreds.

§ AnonCreds Issuer Setup With Revocation

Before issuing credentials of a given type with AnonCreds, an issuer must create and publish a Credential Definition (“CredDef”) that is flagged to be revocable. In addition, the issuer must also create a Revocation Registry, which holds the revocation status of a set of issued credentials. A Revocation Registry is linked to a given Credential Definition. Each Revocation Registry may be of a limited size (number of tracked credentials). If so, an Issuer MUST be able to create additional Revocation Registries when needed so as to have an effectively unlimited supply of credentials of a given type.

§ AnonCreds Issuance with Revocation

When an Issuer issues a credential to a holder, they identify both the Revocation Registry in which they will track the revocation status of the credential, and an identifier (index) within the Revocation Registry for the specific credential. We’ll call the combination of the identifier for the Revocation Registry, and the identifier for a given credential within the Revocation Registry the RevocationId. The RevocationId is tracked by the issuer, correlated with the holder, such that when necessary, the Issuer can revoke the credential. The RevocationID is shared with the holder. The holder will use that information when needed for creating a proof that their credential has not been revoked. The RevocationID is a linkable identifier for the credential and so MUST not be shared with verifiers.

§ AnonCreds Credential Activation/Revocation and Publication

When an issuer decides to revoke one or more issued credentials, they do so by publishing an update to the state of the Revocation Registry, updating (from the last state) the status of each revoked credential. Where the RevRegEntry is published depends on the revocation scheme–it might be to a Verifiable Data Registry (VDR), it might be to a Revocation Manager service, or it might be to a file on a web server.

The holder is not involved in the process of revoking a credential. There is no technical requirement for an issuer to notify the holder that a credential they were issued has been revoked. That said, it is a courtesy that may improve the user experience of the holder. Aries RFC 0183 Revocation Notification is an example of how that can be done. Even if not notified by the issuer of the revocation of a credential, the holder can detect their credential has been revoked when they retrieve a RevRegEntry, attempt to create a proof that their credential is not revoked, and discover they are unable to do so.

§ AnonCreds Presentation Request with Revocation

Carrying out an AnonCreds presentation with revocation is a two-step process, beginning with a request from the verifier asking the holder to include a non-revocation proof (NRP) in the presentation, and then the holder creating the NRP and including it in the presentation sent to the verifier. The NRP must include a cryptographic link to the source verifiable credential to which it is related.

• A holder MUST not be able to produce a valid proof that their credential has not been revoked based on a RevRegEntry in which their credential is marked as revoked.

§ AnonCreds Verification with Revocation

A verifier receives the presentation from the holder and processes the non-revocation-related parts of the presentation and the revocation-related parts of the presentation (if any) in the presentation. The resulting status of the presentation combines the verification outcomes from processing all proofs within the presentation. If verification of one or more of the embedded proofs is unsuccessful, the presentation is rejected as unverifiable.

§ IANA Considerations

This document has no IANA actions.

§ Security Considerations

§ Cryptography

§ Signature

§ Revocation / Accumulators

§ Verifiable Data Registry

It is recommended to use a Verifiable Data Registry that complies with the state of the art security features and best practices.

§ Permission Management

The VDR for storing Schemas, Credential Definitions, Revocation Registry Definitions, and Revocation Status Lists shall ensure that only the owner or from the owner permitted entities can write, edit, or revoke those AnonCreds objects. Furthermore, public AnonCreds objects shall be readable by any entity that can access the VDR.

§ Authentication of Issuer

The VDR shall allow only permitted entities to issue AnonCreds based on AnonCreds objects related to it.

§ Security Requirements at DIDs and Related Keys

It is recommended to follow the best practices of decentralized key management system designs and architectures. For example, an option for publishing AnonCreds is the Hyperledger Indy, which are built on the following DKMS Design and Architecture

§ Envelope

AnonCreds should be packed in a message envelope that can fulfill properties such as authenticity, integrity, confidentiality, and non-repudiation of the message. A message can have these properties with signature and encryption algorithms. It is recommended to choose signature and encryption algorithms that are state of the art and offer such security. For example, Hyperledger Indy utilizes DIDComm v1 as message envelope for exchanging AnonCreds between issuers, holders, and verifiers.

§ Transport

This specification does not mention which transport protocols should be used to exchange AnonCreds between parties. It is recommended to use transport protocols that are state of the art and offer such security.

§ Wallet

It is recommended to follow the wallet security best practices such as the one created by the [DIF Wallet Security Working Group] (https://github.com/decentralized-identity/wallet-security)

§ Recovery

The wallets for AnonCreds shall offer recovery mechanisms for the holders to export their keys and/or link secrets to different devices. Furthermore, wallet applications should offer portability mechanisms for holders to migrate their credentials from one wallet (or end device) to another.

§ Support of Hardware Secure Modules

The current underlying signature algorithm of AnonCreds is currently not supported by any hardware secure module. Use cases requiring binding of an AnonCreds to a device (device binding) can follow the best practices of wallet security (hyperlink) until the AnonCreds signature algorithm is supported by hardware secure modules of enduser devices.

§ Crypto Agility

The underlying signature algorithm of AnonCreds is not known to be a post-quantum computing resistant. As new signature algorithms evolve for the post-quantum computing security, the underlying signature algorithm of AnonCreds shall keep privacy-preserving features such as selective disclosure and non-correlatability.

§ Privacy Considerations

§ References

§ Normative References

§ Informative References

§ Resources on cryptography

§ Sigma protocols

• The original work by Schnorr
• Cramer’s thesis that first defines the concept of Sigma protocol
• set of lecture notes on Sigma protocols
• book with a section on sigma protocols
• Blog post on Zero Knowledge Proofs with Sigma Protocols

§ Acknowledgements

AnonCreds was initially created as part of the Open Source Hyperledger Indy project.

This specification is the work of the AnonCreds Working Group, which includes dozens of active and dedicated participants. In particular, the following individuals contributed ideas, feedback, and wording that influenced this specification:

§ Authors’ Addresses