§ AnonCreds Specification

Specification Status: v1.0 Draft

Latest Draft:

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

Editors:

• Stephen Curran
• Artur Philipp - Technische Universität Berlin, IDunion
• Hakan Yildiz - Technische Universität Berlin, IDunion
• Sam Curren
• Victor Martinez Jurado
• Aritra Bhaduri
• Artem Ivanov

Participate:

GitHub repo

Commit history

Discord

§ Abstract

The AnonCreds (Anonymous Credentials) specification is based on the open source verifiable credentialimplementation of AnonCreds that has been in use since 2017, initially as part of theHyperledger Indy opensource project and now in theHyperledger AnonCreds project. The extensive use of AnonCreds around the world has made it a defacto standard for ZKP-based verifiable credentials, and this specification is theformalization of that implementation.

For more details on what AnonCreds are and how they work you can refer to theAnonymous credentials with type-3 revocation by Dmitry Khovratovisch, Michael Lodder and Cam Parra which is the compiled pdf from theirofficial TeX document published under CC4.0 license.

§ Status of This Memo

This is a proposal for version v1.0 of AnonCreds which aims at AnonCreds being ledger agnostic.

This document is a product of theAnonCreds Working Group.It represents the consensus of the AnonCreds community.The proposal for v1.0 has partly been worked out at theRWOT2022 event in the Hague, Netherlands.

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

§ Copyright Notice

This specifications is subject to theCommunity Specification License 1.0available athttps://github.com/CommunitySpecification/1.0.

If source code is included in the specification, that code is subject to theApache 2.0 license unless otherwise marked. In the case of any conflict orconfusion within this specification between the Community Specification Licenseand the designated source code license, the terms of the Community SpecificationLicense shall apply.

§ Introduction

AnonCreds ZKP verifiable credentials provide capabilities that many see as important for digital identity use cases in particular, and verifiable data in general. These features include:

• A full implementation of the Layer 3 verifiable credential “Trust Triangle” of theTrust over IP Model.
• Complete flows for issuing verifiable credentials (Issuer to Holder), and requesting, generating and verifying presentations of verifiable claims (Holder to Verifier).
• Fully defined data models for all of the objects in the flows, including verifiable credentials, presentation requests and presentations sourced from multiple credentials.
• Fully defined applications of cryptographic primitives.
• The use of a Blind Signature scheme in the issuance process to enhance the privacy protections available to the holder recieving the credential, including:
  • Only the holder learns the final credential signature, the issuer only learns a blinded version which only the holder can unblind.
  • The issuer can sign messages blindly, never learning their value, while still being able to guarantee that the holder knows the value of the message being signed. This is used for the link secret, which the holder commits to during the issuance, the issuer blindly signs this message along with the rest of the credential attributes and then the holder removes the blinding to get a signature over the credential attributes including the unblinded link secret value.
• The use of Zero Knowledge Proofs (ZKPs) in the verifiable presentation process to enhance the privacy protections available to the holder in presenting data to verifiers, including:
  • Proving that certain values are part of a signed credential without revealing them including: credential signature, link secret and any attributes a holder does not wish to reveal. This helps prevent correlation based on these values.
  • The use of unrevealed identifiers for holder binding to prevent correlation based on such identifiers.
  • The use of predicate proofs to reduce the sharing of PII and potentially correlating data, especially dates (birth, credential issuance/expiry, etc.).
  • A revocation scheme that proves a presentation is based on credentials that have not been revoked by the issuers without revealing correlatable revocation identifiers.

This version (v1.0) removes any dependence on Hyperledger Indy by removing any requirements related to the storage of the objects used in AnonCreds, whether they be stored remotely on a “verifiable data registry” (including Hyperledger Indy) or in local secure storage.

The following diagram and explanation below give a high-level overview of all AnonCreds Data objects, their relations and the owner respectively receiver of each of the data objects.

AnonCreds require aVerifiable Data Registry (VDR). AVDR (box in green) is a public registry (often a ledger) used for storing some of the AnonCreds data objects.

Schemas are public and reusable templates, which define the attributes of issued AnonCredscredentials and can be written (e.g. by anIssuer) to theVDR.

Based on aSchema, arbitraryIssuers (box in yellow) can create a Credential Definition (Credential Definition) which references theSchema. ACredential Definition enablesIssuers to issue AnonCredsCredentials toHolders and enablesVerifiers (box in red) to verifyCredentials issued to and presented by aHolder. ACredential Definition consists of two pieces of information: First, thePrivate Credential Definition includes the private signing keys of theIssuer for signing and issuing AnonCredsCredentials toholders and is kept private by theIssuer. Second, thePublic Credential Definition includes the public keys of theIssuer, has to be stored on aVDR and is used byholders and arbitraryVerifiers in order to verify AnonCredsCredentials issued to and presented byHolders.

EachHolder (box in blue) has alink secret, which enablesCredential toHolder binding: Whenever aCredential is issued to aHolder by anIssuer, theHolder generates ablinding factor and uses this to commit to a blinded version of thelink secret which is sent to theIssuer. TheIssuer verifies the commitment, before producing a blind signature over the blindedlink secret along with the other attributes within the AnonCredsCredential. This blind signature is sent to theHolder, who removes theblinding factor to retrieve a credential signature over theCredential attributes including the unblindedlink secret. By using the samelink secret for everyCredential that is issued to theHolder, theHolder can prove the affiliation of multipleCredentials at presentation time.

Holders never present the raw signed credential data they - received fromIssuers - toVerifiers for verification purposes. Instead aVerifiable Presentation is created by theHolder and sent to theVerifier. AVerifiable Presentation is a derivation of an AnonCredsCredential which allows aHolder to proof the correctness of the revealed credential data, without revealing the original raw credential signature(s). Additionally,Holders prove knowledge thelink secret attribute within theCredential, without revealing this value to theVerifiers.Verifiers processVerifiable Presentations for verification ofcredential data.

AnonCreds allows the revocation ofCredentials issued toHolders byIssuers. In case revocation is required, at least one (Revocation Registry Definition), which references the associatedPublic Credential Definition, has to be stored to theVDR by theIssuer in addition to thePublic Credential Definition. ARevocation Registry Definition can haveRevocation Status Lists. When one or more credentials have to be revoked, theIssuer stores aRevocation Status List with the updated status of the credentials in question to theVDR.Holder use these additional pieces of information in order to generate aNon-Revocation Proof. ANon-Revocation Proof proves to aVerifier, that the credential theHolder presented to theVerifier, has not been revoked.Verifiers use the information provided by aRevocation Registry Definition and associatedRevocation Status Lists to verify theHolder`sNon-Revocation Proof. ATails File supports the revocation mechanism. EachRevocation Registry Definition requires exactly one Tails File.

§ Requirements, Notation and Conventions

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

§ Terminology

Accumulator

A [cryptographic accumulator] is used in the AnonCreds v1.0 Revocation scheme as a space- and time-efficient method of proving a value membership in a set of values without revealing the individual members of the set. In AnonCreds v1, an accumulator is a core element of theverifiable credential revocation mechanism.

AnonCreds Method

AnonCreds methods specify how AnonCreds objects are written (registered) and read (resolved) on a givenverifiable data registry implementation. AnonCreds was originally written to useHyperledger Indy as its onlyVDR implementation, but the evolution of AnonCreds to enable storing objects on anyVDR implementation means that AnonCreds methods (comparable toDID Methods from theW3C DID Core specification) are necessary. AnonCreds Methods are defined in theAnonCreds Methods Registry repository.

AnonCreds Objects

The published and shared data objects used in AnonCreds v1.0 including the published objectsschema,credential definition,revocation registry definition,revocation registry entry and the shared objectscredential offer,credential request, andpresentation request.

BigNumber

ABigNumber is an data object which safely allows mathematical operations on numbers of any magnitude. BigNumbers are commonly used in cryptography schemes, including those underlying AnonCreds v1.0.

Blinded Secret

A cryptographic technique where a secret value (a number) is blinded before it is shared such that the sender can later prove knowledge of the secret value without sharing it. The AnonCreds v1.0link secretmechanism is based on the use of a blinded secret.

Blinded Secrets Correctness Proof

AZKP-based proof that can be verified to show that ablinded secret was produced correctly from anunblinded secret without exposing the secret.

Blinding Factor

A blinding factor is a randomBigNumber selected from the set of integers up to the order of the RSA group,n. It is generated by theholder to blind theirlink secret during credential issuance. Knowledge of the blinding factor can be used to create aBlinded Secrets Correctness Proof.The blinding factor can be removed from the signature theissuer produces to retrieve a valid signature over theunblinded link secret. A blinding factor and associatedBlinded Secrets Correctness Proof are similarly generated for each non-disclosed attribute during credential presentation, such that aholder can prove they know these values without revealing them to theverifier.

Call Home

Call home is a term used when evaluating the privacy characteristics ofverifiable credential deployments. If aholder presenting data from a verifiable credential must always contact (“call home to”) theissuer,holder actions are open to the actual, or perception of, tracking of the holder by the issuer.Verifiable credential schemes that do not make possible the tracking ofholder activities byissuers are preferred.

Claim

A claim is a part of digital identity related to asubject. A claim can be attested by the identity subject itself, or it can be asserted by another entity.

Correlatability

When a verifiable credential scheme that has the attribute ofunlinkability, the data from the process of sharing averifiable presentations with different verifiers cannot be correlated to identify theholder.

Credential

A credential is a set ofclaims about an identitysubject. A verifiable credential is a tamper-proof credential whose authorship is cryptographically verifiable. An anonymous credential, also known as AnonCreds, is a verifiable credential that has privacy-preserving properties to enable data minimization and correlation resistance.

Credential Definition

A credential definition (also known as CRED_DEF or CLAIM_DEF) contains the public data required forcredential issuances (used by theissuer) as well ascredential validation data (used byholders andverifiers). Any number of credentials can be issued based on a single credential definition. A credential definition is generated by theissuer beforecredential any issuances and published for anyone (primarilyholders andverifiers) to use. In generating the published credential definition, related private data is also generated and held as a secret by the issuer. The secret data includes the private keys necessary to generate signedverifiable credentials that can be presented and verified using the published credential definition. A credential definition can optionally be generated such that its generated credentials can be revoked.

Credential Key Correctness Proof

A proof generated during the creation of thecredential definition and included in thecredential offer so that theholder can verify that theissuer is in control of the private data associated with the publishedcredential definition.

Credential Offer

A credential offer is a data object sent by anissuer to aholder offering to issue acredential. The credential offer contains the details about the claims theissuer intends to issue to theholder. Aholder can reply to theissuer with acredential request. A credential offer also includes anonce and aCredential Key Correctness Proof.

Credential Request

A credential request is a request from anholder towards aissuer to get a credential issued by theissuer. The credential request references a precedingcredential offer and defines the claims theholder wants to get issued, including aBlinded Secret and associatedBlinded Secrets Correctness Proof. A credential request also includes anonce that is used in issuing the credential.

Data Minimization

An attribute of verifiable data sharing schemes that considers privacy of a scheme based on the amount of data shared in a given interaction. Ideally, the minimum amount of data is shared for the purpose of the interaction. Techniques such asselective disclosure,predicates, andunlinkability, all available in AnonCreds v1.0 support the goal of privacy-preserving, minimal data sharing.

DID

A Decentralized Identifier (DID), defined by theW3C DID Core Specification, is a type of identifier that is useful in enabling verifiable, decentralized digital identity. A DID refers to any subject (e.g., a person, organization, thing, data model, abstract entity, etc.) as determined by the controller of the DID. DIDs are not used in AnonCreds itself but there must be a verifiable identifier (usually a DID) with an enforced relationship betweenschema publishers andissuers and the AnonCreds objects they publish. This is outlined in a note inthis specification section.

DID Method

DID methods specify how DID documents are created and resolved (read) on a givenverifiable data registry implementation, allowing DIDs to be created and resolved in a wide variety of storage containers. The capabilities required by DID Methods are defined in the [DID Core specification], and the (many) DID Methods are defined in theDID Methods Registry repository.

Holder

In this specification, the holder is a software component (agent) used by an entity (person, organization, etc.) in possession ofcredentials issued to them. Where “holder” is used in the specification we mean the software component. In some places where required, we clearly refer to an entity using holder software as separate from the holder software component. Holders interact withissuers to obtaincredentials, and derivepresentations from thecredentials they hold.

Issuer

An issuer is one of the three entities that interact with each other within the domain of digital identities. It can assertclaims about asubject in the form of a tamper-proof credential whose origins are cryptographically verifiable.

Issuer Identifier

An issuer identifier is a unique identifier for anissuer. It is used to identify theissuer of AnonCreds objects published to aVerifiable Data Registry.

Link secret

A link secret is a unique identifier known only to theholder used in AnonCreds to bind credentials issued to aholder to thatholder, and to demonstrate that all of the source verifiable credentials in a presentation are bound to the same link secret that is known to theholder. During issuance and presentation processes theholder's link secret is blinded with ablinding factor such that it is not correlatable, and aBlinded Secrets Correctness Proof is provided by the holder to demonstrate they know the link secret without revealing it.

Link secret is also known by the deprecated termmaster_secret in some AnonCreds source code.

Nonce

A nonce is an arbitrary unique number that is often required as an input to the generation of a cryptographic proof to ensure it is uniquely generated and once produced, cannot be replayed. Within AnonCreds, nonces are used during the issuance and presentation processes to prevent replay attacks.

Non-Revocation Proof

A non-revocation proof is a proof provided by aholder to demonstrate that a revocable credential they are presenting has not been revoked, without revealing a unique, correlatable identifier for the credential. Averifier verifies a non-revocation proof using information from therevocation registry to which thecredential belongs.

Predicates

Azero-knowledge proof predicate is a boolean assertion (operators<=,<,>,>=) in an presentation about the value of an integerclaim without disclosing the value of the claim.

Presentation Request

An AnonCreds presentation request is an object constructed by theverifier and sent to theholder defining the verifiable data that theverifier wants from theholder for some purpose.

Prover

A prover is a synonym for holder that is sometimes used in aholder-verifier interaction. In this specification, we use the term “holder” in all cases. However the underlying AnonCreds implementations use “prover” in code.

Revocation

A unilateral action by theissuer of averifiable credential issued to aholder to revoke that credential for some reason. Once an issued credential has been revoked, theholder can no longer produce anon-revocation proof for thecredential.Verifiers usually (but not always) are interested if a data is presented from a revokedcredential.

Revocation Registry

A Revocation registry is a set of objects related to one another and acredential definition that holds information about the revocation status of a set of revocable credentials issued from thecredential definition. Each revocation registry consists of arevocation registry definition and one or morerevocation registry entries. There can be 0 or more revocation registries related to acredential definition, and every issued AnonCreds revocable credential is in a revocation registry.

Revocation Registry Definition

A revocation registry definition is an object with public and private information about arevocation registry. The public part is published such that it an be resolved and used by anyone, while the private part is a secret held by theissuer for use when publishingrevocation registry entries that update the revocation status of one or more credentials.

Revocation Registry Entry

A revocation registry entry is an object that is published by theissuer to set/update the revocation status of one or more issued credentials that are in arevocation registry. Each revocation registry entry has an identifier (sometimes called atimestamp), a cryptographic accumulator that summarizes the revocation state of all the credentials in therevocation registry and, depending on theAnonCreds Method being used to publish the object, either the revocation state of all of the credentials in the registry, or the set of credentials whose revocation state has changed (“deltas”) since the last revocation registry entry was published.

Revocation Status List

A Revocation status list is an object that contains the revocation status (“revoked” or “not revoked”) of all credentials in aRevocation Registry at the time of a givenrevocation registry entry. For [[AnonCreds Methods]] that storerevocation registry entries as deltas (changes to the revocation state of credentials from the previousrevocation registry entry), the set of deltas from the initial publication of therevocation registry must be collected and used to calculate the full revocation state of all of the credentials.

Schema

A Schema is a object that defines the set ofclaims (also known as attributes) that will be populated byissuers in issuing a give type of AnonCredsverifiable credentials. Schemas have a name, version, and are published to averifiable data registry by aschema publisher using anAnonCreds Method.Credential definitions are generated from a specific schema.

Schema Publisher

A Schema publisher is an entity that publishes aSchema to averifiable data registry. The schema publisher could be the oneissuer of a type of credential, but could also be another entity that creates aSchema to be used by manyissuers to issue the same type of credential.

Selective Disclosure

Selective disclosure is the ability to minimize data the shared data from an issuedcredential in apresentation by revealing to averifier only a subset ofclaims in thecredential. The source credential is still verified by theverifier, but only the revealed values are disclosed.

Signature Correctness Proof

AZKP-based proof that can be verified to show that a signature over a message is valid, without revealing the message or signature.

Subject

A subject, also known as an identity subject, is the entity about whom theclaims in a credential are asserted. In AnonCreds, the credential subject is not formally defined incredential. Rather, the issuance of acredential is always to a specificholder. The semantics of the credential defines the relationship between theholder and the subject, with theholder frequently being the subject.

Tails File

A tails file is a part of the AnonCreds v1.0 scheme that enables aholder to produce anon-revocation proof. A tails file is a static file generated as part of the creation of arevocation registry by theissuer, published, and retrieved by theholder of a credential that is in the relatedrevocation registry. Theholder must have the tails file in order to generate anon-revocation proof for a sourcecredential they are providing in apresentation.

Unlinkability

Unlinkability is the attribute of some verifiable credentials schemes (notably AnonCreds) such that nocorrelatable identifiers are shared in carrying out verifiable credential issuance and presentation processes. Unlinkability requires that when the processes are repeated with the same or different parties (issuers,verifiers) no common unique identifiers are shared. Note that unlinkability may be lost if there are unique identifiers shared in the revealedclaim values ofpresentations.

Verifiable Data Registry

DIDs, DID documents and publishedAnonCreds objects are stored in a verifiable data registry (VDR) such that an identifier for an object can be resolved (by anyone, in most cases), and the identified object returned. A VDR can be a distributed ledger, a blockchain, a web server, database or any other type of storage system. The process of going from the identifier to discovering and resolving the object is a DID Method (for DIDs) andAnonCreds Method (forAnonCreds objects). Resolved objects must adhere to their specified data model, regardless of the discover/resolution method used and the verifiable data registry in which the objects are stored.

Verifiable Presentation

An AnonCreds verifiable presentation is a collection ofclaims andpredicates derived from one or morecredentials with an added proof that theverifier can verifier. AnonCreds enable the holder to prove it holds a claim from a VC without revealing the VC itself. Verifying a presentation shows theissuer of the sourcecredentials, to whom the credentials where issued, that theclaims have not been tampered with, and, if applicable, that the source credentials have not been revoked. AnonCreds presentations are designed to maximize the privacy of theholder sharing the presentation.

Verifier

A verifier is an entity that verifies the information from aholder in apresentation.

Zero-knowledge proof

In cryptography, a zero-knowledge proof is a method by which an entity can prove that they know a certain value without disclosing the value itself. Zero-knowledge proofs in AnonCreds enable a number of privacy-preserving capabilities.

• Prove knowledge of the value of thelink secret related to given ablinded link secret.

• Share data from multiplecredentials in a singleverifiable presentation without revealing to theverifier any correlatable identifiers.

• Useselective disclosure to reveal only necessaryclaims in averifiable presentation.

• Usepredicates to minimize the data shared by theholder, such as proving based on a date of birthclaim that they are older than 18without sharing their date of birth.

• Prove that the sourcecredentials shared in a presentation have not been revoked without sharing unique identifiers for thecredentials.

§ Cryptographic Notations

This specification contains the cryptographic calculations necessary to produce the data objects exchanged in using Hyperledger AnonCreds, and to verify the various proofs embedded in those objects. The following is information about the notations used in displaying the cryptographic calculations:

a || b : Denotes the concatenation of octet stringsa andb.

I \ J : For setsI andJ, denotes the difference of the two sets i.e., all the elements ofI that do not appear inJ, in the same order as they were inI.

X[a..b] : Denotes a slice of the arrayX containing all elements from and including the value at indexa until and including the value at indexb. Note when this syntax is applied to an octet string, each element in the arrayX is assumed to be a single byte.

range(a, b) : For integersa andb, witha <= b, denotes the ascending ordered list of all integers betweena andb inclusive (i.e., the integersi such thata <= i <= b).

length(input) : Takes as input either an array or an octet string. If the input is an array, returns the number of elements of the array. If the input is an octet string, returns the number of bytes of the inputted octet string.

H(...) : Any hash function.

Terms specific to pairing-friendly elliptic curves are:

E1, E2 : elliptic curve groups defined over finite fields. This document assumes thatE1 has a more compact representation thanE2, i.e., becauseE1 is defined over a smaller field thanE2.

G1, G2 : subgroups ofE1 andE2 (respectively) having prime orderr.

GT : a subgroup, of prime orderr, of the multiplicative group of a field extension.

e :G1 x G2 -> GT a non-degenerate bilinear map.

r : The prime order of theG1 andG2 subgroups.

P1, P2 : points onG1 andG2 respectively. For a pairing-friendly curve, this document denotes operations inE1 andE2 in additive notation, i.e.,P + Q denotes point addition andx * P denotes scalar multiplication. Operations inGT are written in multiplicative notation, i.e.,a * b is field multiplication.

§ AnonCreds Setup Data Flow

The following sequence diagram summarizes the setup operations performed by aSchema Publisher, theIssuer (one required and one optional) in preparing to issue an AnonCred credential based on providedSchema, and the one setup operation performed by eachHolder. On successfully completing the operations, theIssuer is able to issue credentials based on the givenSchema to theHolder. The subsections below the diagram detail each of these operations.

§ Schema Publisher: Publish Schema Object

Each type of AnonCred credential is based on aSchema published to a VerifiableData Registry (VDR), an instance of Hyperledger Indy in this version ofAnonCreds. TheSchema is defined and published by theSchema Publisher. Any issuerwho can reference theSchema (including theSchema Publisher) MAY issuecredentials of that type by creating and publishing aCredential Definition based on theSchema. This part of the specification covers the operation to create andpublish aSchema. The flow of operations to publish aSchema is illustrated intheSchema Publisher: Publish Schema section of theAnonCreds Setup DataFlow sequence diagram.

TheSchema is a JSON structure that can be manually constructed,containing the list of attributes (claims) that will be included in eachAnonCreds credential of this type. The following is an exampleSchema:

{"issuerId":"https://example.org/issuers/74acabe2-0edc-415e-ad3d-c259bac04c15","name":"Example schema","version":"0.0.1","attrNames":["name","age","vmax"]}

• issuerId - theIssuer Identifier of the schema. MUST adhere toIssuer Identifiers rules.
• name (string) - the name of the schema
• version (string) - the schema version as a documentation string that it’s not validated. The format is up to each implementor or publisher. For example, Indy usesSemantic Versioning
• attrNames (str[]) - an array of strings with each string being the name of an attribute of the schema

Once constructed, theSchema is published to a Verifiable Data Registry(VDR) using the Schema Publishers selectedAnonCreds Objects Method.For example, seethisSchema that is published onthe Sovrin MainNet instance of Hyperledger Indy. TheschemaId for that objectis:Y6LRXGU3ZCpm7yzjVRSaGu:2:BasicIdentity:1.0.0.

The identifier for theschema is dependent on where theSchemais published and theAnonCreds method used.

§ Issuer Create and Publish Credential Definition Object

Each Issuer of credentials of a given type (e.g. based on a specificSchema) mustcreate aCredential Definition for that credential type. The flow of operations to create andpublish aCredential Definition is illustrated in theIssuer: Create, Store and Publish Credential Definitionsection of theAnonCreds Setup Data Flow sequencediagram.

In AnonCreds, theCredential Definition andCredential Definition identifier include the following elements.

• A link to the Issuer of the credentials via the DID used to publish theCredential Definition.
• A link to theSchema upon which theCredential Definition is based (the credential type).
• A set of public/private key pairs, one per attribute (claim) in thecredential. The private keys will later be used to sign the claims whencredentials to be issued are created.

• Other information necessary for the cryptographic signing of credentials.
• Information necessary for the revocation of credentials, if revocation is tobe enabled by the Issuer for this type of credential.

We’ll initially cover the generation and data for aCredential Definition created without theoption of revoking credentials. In the succeedingsection, we describe theadditions to the generation process and data structures whencredential revocation is enabled for a givenCredential Definition.

§ Retrieving the Schema Object

Prior to creating aCredential Definition, the Issuer must get an instance of theSchema upon which theCredential Definition will be created. If the Issueris also theSchema Publisher, they will already have theSchema. If not, the Issuer must request that information from theVDRon which theSchema is published. In someAnonCreds Objects there is a requirement that theSchema andCredential Definitionmust be on the sameVDR.

§ Generating a Credential Definition Without Revocation Support

TheCredential Definition is a JSON structure that is generated using cryptographic primitives(described below) given the following inputs.

• ASchema and identifier for theschema for the credential type.
• Atag, an arbitrary string defined by the Issuer, enabling an Issuer tocreate multipleCredential Definitions for the sameSchema.
• An optional flagsupport_revocation (defaultfalse) which if truegenerates some additional data in theCredential Definition to enable credentialrevocation. The additional data generated when this flag istrue is coveredin thenext sectionof this document.

The operation produces two objects, as follows.

• ThePrivate Credential Definition, an internally managed object that includes the private keysgenerated for theCredential Definition and stored securely by the issuer.
• TheCredential Definition, that includes the public keys generated for theCredential Definition, returned to the calling function and then published on a VDR(currently Hyperledger Indy).

The following describes the process for generating theCredential Definition andPrivate Credential Definition data.

• Build a credential schema using the schema definition.
• Build a non-credential schema that contains the single attributemaster_secret, that will be used to hold the holder’s blinded link secret. The non-credential schema attribute is included in all AnonCreds verifiable credentials.
• Generate random 1536-bit primes$p^{\mathrm{\prime }}$p′,$q^{\mathrm{\prime }}$q′, such that$p\leftarrow 2p^{\mathrm{\prime }}+1$p←2p′+1 and$q\leftarrow 2q^{\mathrm{\prime }}+1$q←2q′+1 are primes too.$p^{\mathrm{\prime }}$p′,$q^{\mathrm{\prime }}$q′, and$2p^{\mathrm{\prime }}+1$2p′+1,$2q^{\mathrm{\prime }}+1$2q′+1 areSophie Germain and Safe primes.
• Compute$n\leftarrow pq$n←pq.
• Compute random$x_z,x_{R_1},\mathrm{.}\mathrm{.}\mathrm{.},x_{R_l}$xz​,xR1​​,...,xRl​​ in the range of safe primes, using the non-credential and credential schema attributes.
• Compute random quadratic residue$S$S modulo$n$n (select a random number from$1$1 to$n$n, and square it$modn$modn).
• Compute$Z\leftarrow S^{x_z}(modn)$Z←Sxz​(modn), and$\{R_i=S^{x_{R_i}}(modn){\}}_{1\le i\le l}${Ri​=SxRi​​(modn)}1≤i≤l​
• Credential Definition public key is$P_k=(n,S,Z,\{R_i{\}}_{i\le i\le l})$Pk​=(n,S,Z,{Ri​}i≤i≤l​) and the private key is$s_k=(p,q)$sk​=(p,q)

Here is the rust implementation of the above process.

ThePrivate Credential Definition produced by the generation process has the following format:

{"p_key":{"p":"123...782","q":"234...456"},"r_key":null}

TheCredential Definition has the following format (based on thisexampleCredential Definition on the SovrinMainNet):

{"issuerId":"did:indy:sovrin:SGrjRL82Y9ZZbzhUDXokvQ","schemaId":"did:indy:sovrin:SGrjRL82Y9ZZbzhUDXokvQ/anoncreds/v0/SCHEMA/MemberPass/1.0","type":"CL","tag":"latest","value":{"primary":{"n":"779...397","r":{"birthdate":"294...298","birthlocation":"533...284","citizenship":"894...102","expiry_date":"650...011","facephoto":"870...274","firstname":"656...226","link_secret":"521...922","name":"410...200","uuid":"226...757"},"rctxt":"774...977","s":"750..893","z":"632...005"}}}

TheCredential Definition contains a cryptographic public key that can be used toverify CL-RSA signatures over a block ofL messagesm1,m2,...,mL. TheCredential Definition contains a public key fragment for each message being signed bysignatures generated with the respective private key. The length of the block ofmessages,L, being signed is defined by referencing a specific Schema with acertain number of attributes,A = a1,a2,.. and settingL toA+1. Theadditional message being signed as part of a credential is for alink_secret(called thelink secret everywhere except in the existing open sourcecode and data models) attribute which is included in all credentials. This valueis blindly contributed to the credential during issuance and used to bind theissued credential to the entity to which it was issued.

All integers within the aboveCredential Definition example json are shown with ellipses (e.g.123...789). They are 2048-bit integers represented as617 decimal digits. These integers belong to an RSA-2048 group characterised by then defined in theCredential Definition.

• issuerId - theIssuer Identifier of the credential definition. MUST adhere toIssuer Identifiers rules.
• schemaId - (string) The identifier of theSchema on which theCredential Definition is based. The format of the identifier is dependent on theAnonCreds Objects Method used in publishing theSchema.
• type - (string) The signature type of theCredential Definition. For this version of AnonCreds the value is alwaysCL.
• tag (string) - the tag value passed in by theIssuer to an AnonCred’sCredential Definition create and store implementation.
• value - (object) an Ursa native object with theprimary andrevocation fields.
  • primary is the data used for generating credentials.
    • n is a safe RSA-2048 number. A large semiprime number such thatn = p.q, wherep andq are safe primes. A safe primep is a prime number such thatp = 2p'+ 1, wherep' is also a prime. Note:p andq are the private key for the public CL-RSA key thisCredential Definition represents.
    • r is an object that defines a CL-RSA public key fragment for each attribute in the credential. Each fragment is a large number generated by computings^{xri} wherexri is a randomly selected integer between 2 andp'q'-1.
      • master_secret (also known aslink secret, but kept as master_secret for backwards compatibility) is the name of an attribute that can be found in eachCredential Definition. The associated private key is used for signing a blinded value given by theHolder to theIssuer during credential issuance, binding the credential to theHolder.
      • The rest of the attributes in the list are those defined in theSchema.
      • The attribute names are normalized (lower case, spaces removed) and listed in theCredential Definition in alphabetical order.
    • rctxt is equal tos^(xrctxt), wherexrctxt is a randomly selected integer between2 andp'q'-1. (I believe this is used for the commitment scheme, allowing entities to blindly contribute values to credentials.)
    • s is a randomly selected quadratic residue ofn. This makes up part of the CL-RSA public key, independent of the message blocks being signed.
    • z is equal tos^(xz), wherexz is a randomly selected integer between2 andp'q'-1. This makes up part of the CL-RSA public key, independent of the message blocks being signed.

The identifier for theCredential Definition is dependent on where theCredential Definition is published and theAnonCreds method used.

§ Generating a Credential Definition With Revocation Support

The issuer enables the ability to revoke credentials produced from aCredential Definition bypassing to theCredential Definition generation process the flagsupport_revocation astrue.When using revocation in a credential, private key material is addedto thePrivate Credential Definition to allow the issuer torevoke credentials, and public key material is added to theCredential Definition to allow a verifier to check revocationstatus. The following describes the fields added to thePrivate Credential Definition and theCredential Definition.

The revocation scheme uses a pairing-based dynamic accumulator definedas a variant of theCKS scheme but with aType 3 elliptic curve pairing instead of a Type 1 pairing. The curve$E$E isBN254, which is definedover a 254-bit prime$p$p. The pairing is an Ate pairing$e:G_1\times G_2\to G_T$e:G1​×G2​→GT​ where$G_1=E({\mathbb{F}}_p)$G1​=E(Fp​),$G_2=E({\mathbb{F}}_{p^2})$G2​=E(Fp2​), and$G_T$GT​ is the group of$q^{\text{th}}$qth rootsof unity in${\mathbb{F}}_{p^{12}}$Fp12​ where$q=\mathrm{\mid }E({\mathbb{F}}_p)\mathrm{\mid }$q=∣E(Fp​)∣, whichis another 254-bit prime.

In the amcl library used for the elliptic curve arithmetic, points arerepresented using projective co-ordinates, i.e. a point$(X\mathrm{/}Z,Y\mathrm{/}Z)$(X/Z,Y/Z) onthe curve$E$E is mapped to a projective point$(X:Y:Z)$(X:Y:Z).Additionally, the big-integer co-ordinates are strings of 64hexadecimal characters, meaning there are up to 64 * 4 - 254 = 2 bits of‘excess’ in each encoding. The library includes the excess number ofbits as an integer (i.e.1 or2) before the hexadecimalstring. The upshot is:

• Elements of$G_1$G1​ are encoded as three 64-characterstrings of hexadecimal characters, each preceded by the excess, e.g.1 1D1...A04 1 146...8BC 1 095...8A8.
• Elements of$G_2$G2​ are encoded as six 64-characterstrings of hexadecimal characters, each preceded by the excess.1 104...EC9 1 01A...FC2 1 226...1EB 1 234...D08 1 095...8A8 1 000...000.

§ Private Revocation Keys

APrivate Credential Definition with revocation enabled has the following format. In this, thedetails of thep_key element are omitted, as they are the same as was coveredinthe section above. The implementation can be found in theanoncreds-clsignatures-rs repository.

{"p_key":{"p":"123...782","q":"234...456"},"r_key":{"x":"332...566","sk":"992...237"}}

• r_key is an object defining the revocation private key for the credential.
  • x is an integer modulo$q$q
  • sk is an integer modulo$q$q

The value$q$q is the order of the group$G_1=E({\mathbb{F}}_p)$G1​=E(Fp​) on the curve BN254 (see above:$q$q is a 254-bit prime).x andsk are used to generate parts of the revocation public key as described below.

§ Public Revocation Keys

ACredential Definition with revocation enabled has the following format (fromthisexample Credential Definition on theSovrin MainNet). In this, the details of theprimary element are omitted, asthey are the same as was covered above.

{"issuerId":"did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM","schemaId":"did:indy:sovrin:F72i3Y3Q4i466efjYJYCHM/anoncreds/v0/SCHEMA/state_license/4.2.0","type":"CL","tag":"latest","value":{"primary":{...},"revocation":{"g":"1 154...813 1 11C...D0D 2 095..8A8","g_dash":"1 1F0...3B5 1 229...41D 1 04B...F7D 1 061...8B7 2 095...8A8 1 000...000","h":"1 131...0DD 1 0D5...66E 2 095...8A8","h0":"1 1AF...246 1 127...361 2 095...8A8","h1":"1 242...F14 1 1AC...2FF 2 095...8A8","h2":"1 072...7A1 1 09E...622 2 095...8A8","h_cap":"1 196...C53 1 238...38B 1 196...C7E 1 198...D31 2 095...8A8 1 000...000","htilde":"1 1D5...797 1 034...232 2 095...8A8","pk":"1 0E7...A88 1 007...4B8 2 095...8A8","u":"1 18E...44B 1 018...F71 1 0D8...2C2 1 003...4CF 2 095...8A8 1 000...000","y":"1 068...F6B 1 16C...F7E 1 01F...68A 1 1E3...9F9 2 095...8A8 1 000...000"}}}

In the following, only therevocation item is described, as the rest of items (primary,ref, etc.) are described in the previous section of this document.

• revocation is the data used for managing the revocation status ofcredentials issued using thisCredential Definition
  • g is a generator for the elliptic curve group$G_1$G1​
  • g_dash is a generator for the elliptic curve group$G_2$G2​
  • h is an elliptic curve point selected uniformly at random from$G_1$G1​
  • h0 is an elliptic curve point selected uniformly at random from$G_1$G1​
  • h1 is an elliptic curve point selected uniformly at random from$G_1$G1​
  • h2 is an elliptic curve point selected uniformly at random from$G_1$G1​
  • h_cap is an elliptic curve point selected uniformly at random from$G_2$G2​
  • htilde is an elliptic curve point selected uniformly at random from$G_1$G1​
  • pk is the public key in$G_1$G1​ for the issuer with respect to this accumulator, computed asg^sk (in multiplicative notation), wheresk is fromr_key above
  • u is an elliptic curve point selected uniformly at random from$G_2$G2​
  • y is the an elliptic curve point in$G_2$G2​, computed ash_cap^x (in multiplicative notation), wherex is fromr_key above

§ Publishing the Credential Definition on a Verifiable Data Registry

Once constructed, theCredential Definition is published by the Issuer to aVerifiable Data Registry using the issuers preferredAnonCreds Objects.

For example, seethisCredential Definition that is publishedin the Sovrin MainNet instance of Hyperledger Indy. Note that the contents of theCredential Definition that have are published to the Hyperledger Indy ledger, do not exactly match theCredential Definition data model. The specificAnonCreds Objects can describe how to resolve the contents stored on the ledger into theCredential Definition data model.

§ Issuer Create and Publish Revocation Registry Objects

Once theissuer has created aCredential Definition with revocationenabled, theissuer must also create and publish aRevocation Registry Definition andcreate and publish the firstRevocation Status List for the registry.

In this section, we’ll cover the create and publish steps for eachof theRevocation Registry Definition andRevocation Status List objects. The creation andpublishing of theRevocation Registry Definition includes creating and publishing theTAILS_FILE for theRevocation Registry.

§ Creating the Revocation Registry Object

A secure process must be run to create the revocation registry object, takingthe following input parameters.

• revocDefType: the type of revocation registry being created. This is alwaysCL_ACCUM
• credDefId: the ID of theCredential Definition to which theRevocation Registry is to be associated
• tag: an arbitrary string defined by the [ref: issuer], enabling an [ref: issuer] to create multipleRevocation Registry Definitions for the sameCredential Definition.
• maxCredNum: The capacity of theRevocation Registry, a count of the number ofcredentials that can be issued using theRevocation Registry.
• tailsLocation: A URL indicating where theTAILS_FILE for theRevocation Registry will be available to allholders of credential issued using this revocation registry.

Three outputs are generated from the process to generate theRevocation Registry: theRevocation Registry object itself, theTAILS_FILE content, and thePrivate Revocation Registry object.

§ Revocation Registry Definition Object Generation

TheRevocation Registry Definition object has the following data model. This example is fromthis transaction on theSovrin MainNet and instance of Hyperledger Indy.

{"issuerId":"did:web:example.org","revocDefType":"CL_ACCUM","credDefId":"Gs6cQcvrtWoZKsbBhD3dQJ:3:CL:140384:mctc","tag":"MyCustomCredentialDefinition","value":{"publicKeys":{"accumKey":{"z":"1 0BB...386"}},"maxCredNum":666,"tailsLocation":"https://my.revocations.tails/tailsfile.txt","tailsHash":"91zvq2cFmBZmHCcLqFyzv7bfehHH5rMhdAG5wTjqy2PE"}}

The items within the data model are as follows:

• issuerId - theIssuer Identifier of the revocation registry. MUST adhere toIssuer Identifiers rules and MUST be the sameissuerId as theCredential Definition on which theRevocation Registry is based.
• revocDefType - the type of revocation registry (This is currently alwaysCL_ACCUM)
• credDefId - The id of theCredential Definition on which theRevocation Registry is based.
• tag - an arbitrary string defined by the [ref: issuer], enabling an [ref: issuer] to create multipleRevocation Registry Definitions for the sameCredential Definition.
• value - The value of the revocation registry definition
  • publicKeys - Public keys data for signing the accumulator; the public key of a private/public key pair
    • accumKey - Accumulator key for signing the accumulator
      • z - a public key used to sign the accumulator (described further below)
  • maxCredNum - The maximum amount of Credentials that can be revoked in the Revocation Registry before a new one needs to be started
  • tailsLocation - The URL pointing to the related tails file
  • tailsHash - The hash of the tails fileTAILS_FILE (see also:next section) resulting from hashing the tails file version prepended to the tails file as SHA256 and then encoded to base58.

As noted, most of the items come directly from the input parameters provided bytheissuer. ThezRevocation Registry accumulator public key isgenerated using (TODO: fill in details) algorithm. The use of the accumulatorpublic key is discussed in the Credential Issuance section, when the publicationof revocations is described. The calculation of the tailsHash is described inthenext section onTAILS_FILEgeneration.

The identifier for theRevocation Registry is dependent on where theRevocation Registry is published and theAnonCreds method used.

§ Tails File and Tails File Generation

The second of the outcomes from creating of aRevocation Registry is aTAILS_FILE. The contents of aTAILS_FILE is an array of calculatedpoints on curveG2, one for each credential in the registry. Thus, if theRevocation Registry has a capacity (maxCredNum) of 1000, theTAILS_FILE holdsan array of 1000G2 curve points. Each credential issued using theRevocation Registry isgiven its own index (1 to the capacity of theRevocation Registry) into the array,the index of the point for that credential. The contents of theTAILS_FILE is needed by theholder to produce(if possible) a “proof of non-revocation” to show their issued credential hasnot been revoked.

The process of generating the points that populate theTAILS_FILE aretail[index] = g_dash * (gamma ** index)

The process for hashing theTAILS_FILE is as follows:

• Append the tails file version and all the bytes ofG2 curve points one by one into a hasher.
• Compute the hash digest usingSHA256 hashing algorithm.

The SHA256 hash of the array of points is returned to be inserted into thetailsHashitem of theRevocation Registry object (as described in theprevioussection). Typically, the array is streamed into afile (hence, the term “Tails File”) and published to aURL indicated bythetailsLocation input parameter provided by theissuer.

The format of aTAILS_FILE is as follows:

• First two bytes are version number(currently0u8 2u8)
• A list of the points, one per credential in the Revocation Registry. Each point is a collection of three integers implemented as points in 3 dimensions as perECP2. Each point is 3x4 = 12 bytes long.

Thus the total size of a Tails File is 2+ 12*Size of the Revocation Registry+6 (the L+1 entry).

While not required, the Hyperledger Indy community has created a component, the “Indy TailsServer,” which is basically a webserver for tails files.Holders get thetailsLocation during theissuance process, download theTAILS_FILE (ideally) once and cache itfor use when generating proofs of non-revocation when creating a presentationthat uses its revocable verifiable credential. How theTAILS_FILE isused is covered elsewhere in this specification:

• in the section about theissuer publishing credential revocationstate updates, and
• in the section aboutholders creating a proof of non-revocation.

§ Revocation Registry Definition Object Generation

In addition to generating theRevocation Registry object, aPrivate Revocation Registry object is generated and securely stored by theissuer. The data model and definition of the items in thePrivate Revocation Registry is as follows:

§ Publishing the Revocation Registry Object

Once constructed, theRevocation Registry is published by theissuer in aVerifiable Data Registry using the issuer’sAnonCreds Objects. For example, seethisRevocation Registry that is publishedon the Sovrin MainNet instance of Hyperledger Indy. The binaryTAILS_FILE associated with theRevocation Registry can be downloaded from thetailsLocation in theRevocation Registry object.

§ Creating the Initial Revocation Status List Object

PublishedRevocation Status List objects contain the state of theRevocation Registry at a given point in time such thatholders can generate aproof of non-revocation (or not) about their specific credential andverifiers can verify that proof. An initialRevocation Status List isgenerated and published immediately on creation of theRevocation Registry so thatit can be used immediately byholders. Over time, additionalRevocation Status List objects are generated and published as the revocation status ofone or more credentials within theRevocation Registry change.

A secure process must be run to create the initialRevocation Status List object,taking the following input parameters.

• revRegId: the ID of theRevocation Registry for which the initialRevocation Status List is to be generated.
  • The process uses this identifier to find the associatedPrivate Revocation Registry to access the information within that object.
• revocationList - A bit array of lengthmaxCredNum that indicates whether a credentialis initially revoked or not. The value of1 indicates the credential isinitially revoked, the value of0 indicates the credential is initially unrevoked.

The process collects from the identifiedPrivate Revocation Registry information tocalculate the cryptographic accumulator value for the initialRevocation Status List, including:

• revocDefType: the type of revocation registry. This is currently alwaysCL_ACCUM
• maxCredNum: The capacity of theRevocation Registry, a count of the number ofcredentials that can be issued using theRevocation Registry.
• tailsArray: The contents of theTAILS_FILE, the array of primes,one for each credential to be issued from theRevocation Registry.
• privateKey: The accumulator private key for theRevocation Registry.

With the collected information, the initial cryptographic accumulator for theRevocation Registry can be created. The format of the identifier for theRevocation Status List is dependent on theAnonCreds Objects Methodused by the issuer.

In simple terms, the cryptographic accumulator at any given point in time is the(modulo) product of the primes for each non-revoked credential in theRevocation Registry.

If all of the credentials are initially revoked (revocationList only contains1 values), the accumulator value is0.

The accumulator is calculated using the following steps:

THe following is an example of an initial, publishedRevocation Status List object:

{"revRegDefId":"4xE68b6S5VRFrKMMG1U95M:4:4xE68b6S5VRFrKMMG1U95M:3:CL:59232:default:CL_ACCUM:4ae1cc6c-f6bd-486c-8057-88f2ce74e960","revocationList":[0,1,1,0],"currentAccumulator":"21 124C594B6B20E41B681E92B2C43FD165EA9E68BC3C9D63A82C8893124983CAE94 21 124C5341937827427B0A3A32113BD5E64FB7AB39BD3E5ABDD7970874501CA4897 6 5438CB6F442E2F807812FD9DC0C39AFF4A86B1E6766DBB5359E86A4D70401B0F 4 39D1CA5C4716FFC4FE0853C4FF7F081DFD8DF8D2C2CA79705211680AC77BF3A1 6 70504A5493F89C97C225B68310811A41AD9CD889301F238E93C95AD085E84191 4 39582252194D756D5D86D0EED02BF1B95CE12AED2FA5CD3C53260747D891993C","timestamp":1669640864487}

The items in the data model are:

• revRegDefId: the identifier of the associatedRevocation Registry Definition. Theformat of the identifier is dependent on theAnonCreds Objects Methodused by the issuer.
• revocationList: Bit array defining the status of the credential in the [ref: Revocation Registry]. A value of1 means the credential is revoked, a value of0 means the credential is not revoked.
• currentAccumulator: the calculated cryptographic accumulator reflecting the initial state of theRevocation Registry
• timestamp: the timestamp at which the accumulator value is valid

§ Publishing the Initial Initial Revocation Status List Object

Once constructed, the initialRevocation Status List is published by theissuer in aVerifiable Data Registry using their selectedAnonCreds Objects Method.

It is not required for theVerifiable Data Registry to store the revocation list as defined in this model. For example, the Indy ledger uses deltas (Revocation Registry Entries) to store the change in revoked/un-revoked indices instead of storing the entire revocation list. It is also possible to compress therevocationList entry using e.g. GZIP to reduce the size on the ledger.

§ Holder Create and Store Link Secret

To prepare to use AnonCreds credentials, theHolder must create alink secret, a unique identifier that allows credentials issued to aHolder to be bound to thatHolder and presented withoutrevealing a unique identifier, thus avoiding correlation of credentials byVerifiers. Thelink secret is kept private by theHolder. Thelink secret is used during the credential issuanceprocess to bind the credential to theholder and in the generation of apresentation. For the latter, it allows theholder to create a zeroknowledge proof that they were issued the credential.This proof demonstrates knowledge thelink secret and prove that it is one of the signed credential attributes, without revealing thelink secret to theverifier. The details of howthelink secret is used to do this is provided in the issuance,presentation generation and verification sections of this specification.

Thelink secret is a sufficiently random unique identifier. Forexample, in the Hyperledger Indy implementation, thelink secret isproduced by a call to the Rustuuid Crate’snew_v4() method toachieve sufficient randomness.

Once generated, thelink secret is stored locally by theHolder for use in subsequent issuance and presentation interactions. If lost,theHolder will not be able to generate a proof that the credential wasissued to them. Theholder generates only a singlelink secret, using it for all credentials theholder is issued. Thisallows forverifiers to verify that all of the credentials used ingenerating a presentation with attributes from multiple credentials were allissued to the sameHolder without requiring theHolder todisclose the unique identifier (link secret) that binds thesecredentials together.

There is nothing to stop aHolder from generating multiplelink secrets and contributing them to different credential issuance processes.However, doing so prevents theHolder from producing a presentationcombining credentials issued to distinctlink secrets that can beproven to have been issued to the same entity. It is up to theVerifierto require and enforce the binding between multiple credentials used in apresentation.

§ AnonCreds Issuance Data Flow

The issuance of an anonymouscredential requires several steps and involves the rolesissuer,holder as well as theVerifiable Data Registry (see diagram below).

Theissuer prepares aCredential Offer for theholder (step 1). ACredential Offer includes a commitment about thecredential (referencing aPublic Credential Definition) theissuer is intending to issue to theholder. Theissuer sends theCredential Offer to theholder (step 2), who evaluates the offer (step 3) and fetches data about the offer (thePublic Credential Definition) from theVerifiable Data Registry (steps 4-7).

Using the data from theCredential Offer and thePublic Credential Definition retrieved from theVerifiable Data Registry, theholder prepares aCredential Request (step 8), a formal request to theissuer to issue acredential based on the givenPublic Credential Definition to theholder. TheCredential Request includes a cryptographic commitment to theholder'slink secret. Theholder sends theCredential Request to theissuer (step 9).

Theissuer verifies and decides whether to accept theCredential Request (step 10) and if so, prepares thecredential (step 11). Theissuer sends thecredential to theholder (step 12). Theholder then removes the blinding factor from the credential (step 13), verifies thecredential and (usually) securely stores it (step 14).

Details about each step in the issuance process are covered in the following sections.

§ Credential Offer

The AnonCreds issuance process begins with theissuer constructing and sending aCredential Offer to the potentialholder. The Credential Offer contains the following JSON elements:

{"schema_id": string,"cred_def_id": string,"nonce": string,"key_correctness_proof": <key_correctness_proof>}

• schema_id: The ID of theSchema on which thePublic Credential Definition for the offeredCredential is based.
• cred_def_id: The ID of thePublic Credential Definition on which theCredential to be issued will be based.
• nonce: A random number generated for one time use by theissuer for preventing replay attacks and authentication between protocol steps. Thenonce must be present in the subsequentCredential Request from theholder.
• key_correctness_proof: The Fiat-Shamir transformation challenge value in the non-interactive mode ofSchnorr Protocol. It is calculated by theissuer as the proof of knowledge of the private key used to create theCredential Definition. This is verified by theholder during the creation ofCredential Request.

The JSON content of thekey_correctness_proof is:

"key_correctness_proof":{"c":"103...961","xz_cap":"563...205","xr_cap":[["<attribute 1>","821...452"],["master_secret","156...104"],["<attribute 1>","196...694"]]}

The values in the proof are generated as follows:

• c: (aBigNumber) can be viewed as the committed value derived from the hash of the concatenated byte values in the process ofcreating the Credential Definition.

$$c=H(z\mathrm{\mid }\mathrm{\mid }{r}_i\mathrm{\mid }\mathrm{\mid }\tilde{z}\mathrm{\mid }\mathrm{\mid }\widetilde{r_i})$$c=H(z∣∣ri​∣∣z~∣∣ri​~​)

where

• $z=s^{x_z}Modn$z=sxz​ Mod n where$z$z,$s$s and$n$n are values in thePublic Credential Definition

• $r_i$ri​ are the values in the$r$r map inPublic Credential Definition, individual attribute public keys

• $\tilde{z}$z~ is similar to$z$z which equals to$s^{\widetilde{x_z}}modn$sxz​~​ mod n, where$\widetilde{x_z}$xz​~​ is a randomly selected integer between$2$2 and$p^{\mathrm{\prime }}{q}^{\mathrm{\prime }}-1$p′q′−1

• $\widetilde{r_i}$ri​~​ is similar to$r$r, which equal to$s^{\widetilde{x_i}}modn$sxi​~​ mod n, where$\widetilde{x_i}$xi​~​ are randomly selected integers between$2$2 and$p^{\mathrm{\prime }}{q}^{\mathrm{\prime }}-1$p′q′−1

• xz_cap:$\widehat{x_z}=c{x}_z+\widetilde{x_z}$xz​^​=cxz​+xz​~​

• xr_cap:{(attributei​,cri​+ri​~​)}1<i<L​ for$L$L attributes

Bothxz_cap and the second element in the tuple of thexr_cap vectorareBigNumbers.

Theissuer sends theCredential Offer to theholder.

§ Credential Request

ACredential Request is a formal request from aholder to anissuer to get acredential based on theCredential (and the referencedPublic Credential Definition) sent by theissuer to theholder.

On receipt of theCredential Offer, theholder retrieves thereferencedPublic Credential Definition from aVerifiable Data. The holder MAY want to retrieve theSchema referenced intheCredential Offer and verify the consistency between the list ofattributes in theSchema and in thePublic Credential.

In addition, theholder also requires access to theirlink.

The nonce of theCredential Offer is used to generate the proof of correctnessfor blinded credential secrets, where it is hashed with the blinded secrets tocreate the proof which is sent to theissuer.

§ Verifying the Key Correctness Proof

Theholder must first verify thekey_correctness_proof in theCredential Offer using data from the referencedPublic Credential Definition. Thekey_correctness_proof data is described in theprevioussection about theCredential Offer.

Thekey_correctness_proof verification is as follows:

1. Check that all attributes inPublic Credential Definition andmaster_secret (anattribute that will be related to thelink secret) are included inxr_cap.
2. Compute$c^{\mathrm{\prime }}$c′, where$c^{\mathrm{\prime }}=H(z\mathrm{\mid }\mathrm{\mid }{r}_i\mathrm{\mid }\mathrm{\mid }\widehat{z^{\mathrm{\prime }}}\mathrm{\mid }\mathrm{\mid }\widehat{r_i^{\mathrm{\prime }}})$c′=H(z∣∣ri​∣∣z′^∣∣ri′​^​).
3. If$\widehat{z^{\mathrm{\prime }}}==\tilde{z}$z′^==z~ and$\widehat{r_i^{\mathrm{\prime }}}==\widetilde{r_i}$ri′​^​==ri​~​, then$c^{\mathrm{\prime }}==c$c′==c. The proof is accepted.

For$\widehat{z^{\mathrm{\prime }}}$z′^, we first find the multiplicative inverse of$z$z

$$z^{-1}z=1(Modn)$$z−1z=1 (Mod n)

Then

$$\widehat{z^{\mathrm{\prime }}}=z^{-c}{s}^{\widehat{x_z}}(Modn)$$z′^=z−csxz​^​ (Mod n)

$$=z^{-c}{s}^{c{x}_z+\widetilde{x_z}}(Modn)$$=z−cscxz​+xz​~​ (Mod n)

$$=z^{-c}{z}^c{s}^{\widetilde{x_z}}(Modn)$$=z−czcsxz​~​ (Mod n)

$$\widehat{z^{\mathrm{\prime }}}=\tilde{z}$$z′^=z~

The same can be derived for all$\widehat{r_i^{\mathrm{\prime }}}$ri′​^​ by finding the multiplicative inverse of$r_i$ri​, where {1 < i < L} for$L$L attributes.

§ Constructing the Credential Request

Theholder constructs the followingCredential Request JSON structure:

{"prover_did":"BZpdQDGp2ifid3u3Up17MG","cred_def_id":"GvLGiRogTJubmj5B36qhYz:3:CL:8:faber.agent.degree_schema","blinded_ms":{        # Structure detailed below},"blinded_ms_correctness_proof":{        # Structure detailed below},"nonce":"604812518357657692681285"}

• entropy: a required string.
  • Calledprover_did in earlier AnonCreds implementations, and calledprover_id inUrsa,entropy is arandom alphanumeric string generated by theholder and used by theissuer to add entropy in generating the credential signature. Thevalue is combined by theissuer with the credential revocation index(cred_idx) if the credential is revocable, and the resulting string is hashedto create thecredential_context, an input to the credential signingprocess. Thecredential_context is them2 item in the issued verifiablecredential signature.
  • Historically in Aries agent implementations, theprover_did was populated bytheholder with aDID they hold, usually the DIDCommpeer-to-peer DID shared by the theholder to theissuer.However, the item is not verified by theissuer as a DID nor as an identifierfor theholder, and as such an random string is sufficient.
  • Theholder can verify the provideentropy value was used by the[[ref: issuer] in generating the signature by combiningentropy with thecred_idx value from the issuer (if the credential is revocable), hashingthe resulting string and checking that the hash matchesm2 in thecredential signature.
• cred_def_id: The ID of thePublic Credential Definition on which theCredential to be issued will be based.
• blinded_ms: Thelink secret in its blinded form. Described in detail in the sectionBlinding the Link Secret (below).
• blinded_ms_correctness_proof: TheBlinded Secrets Correctness Proof of the blindedlink secret. Described in detail in the sectionThe Blinded Link Secret Correctness Proof (below).
• nonce: Used for preventing replay attacks and authentication between protocol steps. Theholder creates an 80 bit nonce in the request which is a randomlygenerated number.

Once constructed, theholder sends theCredential Request to theissuer, who then can reply to theholder by sending an issued credential.

§ Blinding the Link Secret

Theholder generates ablinding factor and uses this to create a cryptographic commitment to theirlink secret. This is theblinded_ms (blinded link secret) in theCredential Request. Theblinded_ms will be signed by theissuer along with the rest of the credential attributes to create a blinded Signature. Theholder removes theblinding factor from the blinded Signature to retrieve the Credential Signature over their unblindedlink secret and the credential attributes.

During presentations, theholder can prove knowledge of thelink secret within credential or set of credentials being presented, without revealing thelink secret itself. This is the capability that enables the binding of thecredentials to each other and to theholder without revealing a correlatable identifier.

Theblinding factor is a secret generated by theholder for blindingthelink secret before sending it to theissuer. Theblinding factor,$v$v is created by selecting a random integer that is less than the order of the RSA group,n.

The process of blinding the link secret uses theissuer'sCredentialPrimaryPublicKey,$P$P, which is included in thePublic Credential Definition,and containsz,r,s andn (describedhere). Whiler containsthe public keys for all of the attributes to be signed, the only one of interestin this process is$r_{lin{k}_{s}ecret}$rlinks​ecret​

Thelink secret,$A_l$Al​ is blinded by

$A_{bl}=r_{linksecret}^{A_l}Modn$Abl​=rlinksecretAl​​ Mod n

$A_{bl}$Abl​ is multiplied by theblinding factor,$v^{\mathrm{\prime }}$v′,

$(s^{v^{\mathrm{\prime }}}\times A_{bl})Modn$(sv′×Abl​) Mod n

The resulting blinded link secret data structure inserted into theCredential Offer is defined as follows:

"blinded_ms":{"u":"331...544","ur":null,  # Populated when the credential definition supports revoation"hidden_attributes":["master_secret"],"committed_attributes":{}}

Where:

• u:$u=(s^{v^{\mathrm{\prime }}}\times A_{bl})Modn$u=(sv′×Abl​) Mod n
• ur: isnull if revocation is not active for the [[ref: Public Credential Definition], and if revocation is active$u_r=h_2^{s_r^{\mathrm{\prime }}}$ur​=h2sr′​​ where$s_r^{\mathrm{\prime }}$sr′​ is randomly selected quadratic residue of order of the bilinear groupsq and$h_2$h2​ is part of the revocation public key.
• hidden_attributes: is an array of hidden attributes from the list of [[ref: Public Credential Definition]. For AnonCreds v1.0, it is always a single entry oflink_secret.
  • Theholder's blindedlink secret is a default hidden attribute in AnonCreds, meaning it is not explicitly defined in theSchema list of attributes but is included in both thePublic Credential Definition and all issuedcredentials. Whilst it is cryptographically possible to have multiple hidden attributes, in this version of AnonCreds, onlylink secret is used.
• committed_attributes: An empty list of attributes in this version of AnonCreds.

§ The Blinded Link Secret Correctness Proof

In addition to creating the blinded link secret, theholder also creates a blinded link secret correctness proof and inserts it into theCredential Request. The data structure for the blinded link secret correctness proof is as follows:

"blinded_ms_correctness_proof":{"c":"702...737","v_dash_cap":"202...924","m_caps":{"master_secret":"907...913"},"r_caps":{}}

The values in the proof are generated as follows:

• c: (aBigNumber) can be viewed as the committed value derived from the hash of the concatenated byte values in the process ofcreating the Credential Definition and thenonce value .

$$c=H(u\mathrm{\mid }\mathrm{\mid }\tilde{u}\mathrm{\mid }\mathrm{\mid }{n}_0)$$c=H(u∣∣u~∣∣n0​)

where

• $u$u is described above.
• $\tilde{u}=s^{{\tilde{v}}^{\mathrm{\prime }}}\times r_{linksecret}^{\widetilde{A_l}}modn$u~=sv~′×rlinksecretAl​~​​ mod n where${\tilde{v}}^{\mathrm{\prime }}$v~′ is randomly selected 3488-bit value and$\widetilde{A_l}$Al​~​ is 593-bit value by referenceAnonymous credentials with type-3 revocation by Dmitry Khovratovisch, Michael Lodder and Cam Parra
• $n_0$n0​ is the nonce value.
• v_dash_cap:$\widehat{v^{\mathrm{\prime }}}\leftarrow \widetilde{v^{\mathrm{\prime }}}+c{v}^{\mathrm{\prime }}$v′^←v′~+cv′, where$v^{\mathrm{\prime }}$v′ is the blinding factor and$\widetilde{v^{\mathrm{\prime }}}$v′~ is a 3488-bit random number.
• m_caps:$\{\widehat{m_i}\leftarrow \widetilde{m_i}+c{m}_i{\}}_{i\in A_h}${mi​^​←mi​~​+cmi​}i∈Ah​​, where$A_h$Ah​ is the set of all hidden attributes.
• r_caps: is an empty structure in this version of AnonCreds.

§ Issue Credential

After theissuer receives theCredential Request from theholder, theissuer processes theCredential Request and decides whether to issue the credential as requested in theCredential Request to theholder. In this section, we’ll cover issuing a credential that cannot be revoked, and then cover the additional steps/data elements in issuing a credential that can be revoked.

§ Verifying the Credential Request

Before deciding to issue the credential, theissuer must first verify theCredential Request from theholder by using the nonce from credential offer ($n_0$n0​) to verify the blinded link secret correctness proof.

Theblinded_ms_correctness_proof is verified byissuer. Theblinded_ms_correctness_proof verification is as follows:

1. Compute$c^{\mathrm{\prime }}$c′, where$c^{\mathrm{\prime }}=H(u\mathrm{\mid }\mathrm{\mid }\widehat{u}\mathrm{\mid }\mathrm{\mid }{n}_0)$c′=H(u∣∣u^∣∣n0​).
2. If$\widehat{u}==\tilde{u}$u^==u~, then$c^{\mathrm{\prime }}==c$c′==c. The proof is accepted.

For$\widehat{u}$u^, we first find the multiplicative inverse of$u$u

$$u^{-1}u=1(Modn)$$u−1u=1 (Mod n)

Then

$$\widehat{u}=u^{-c}\times r_{linksecret}^{\widehat{m}}\times s^{\widehat{v^{\mathrm{\prime }}}}(Modn)$$u^=u−c×rlinksecretm^​×sv′^ (Mod n)

$$=u^{-c}\times r_{linksecret}^{\widetilde{A_l}+c{A}_l}\times s^{\widetilde{v^{\mathrm{\prime }}}+c{v}^{\mathrm{\prime }}}(Modn)$$=u−c×rlinksecretAl​~​+cAl​​×sv′~+cv′ (Mod n)