# ADR 011: AnonCreds ## Status | Category | Status | | ------------------------- | ------------------------------------------------ | | **Authors** | Renata Toktar, Alexander Kolesov, Ankur Banerjee | | **ADR Stage** | DRAFT | | **Implementation Status** | Draft | | **Start Date** | 2022-06-23 | ## Summary This ADR will define how Verifiable Credential schemas can be represented through the use of a DID URL, which when dereferenced, fetches the credential schemas a resource. The identity entities and transactions for the cheqd network are designed to support usage scenarios and functionality currently supported by [Hyperledger Indy](https://github.com/hyperledger/indy-node). ## Context Hyperledger Indy is a verifiable data registry (VDR) built for DIDs with a strong focus on privacy-preserving techniques. It is one of the most widely-adopted SSI blockchain ledgers. Most notably, Indy is used by the [Sovrin Network](https://sovrin.org/overview/). ### Identity-domain transaction types in Hyperledger Indy Our aim is to support the functionality enabled by [identity-domain transactions in by Hyperledger Indy](https://github.com/hyperledger/indy-node/blob/master/docs/source/transactions.md) into `cheqd-node`. This will partly enable the goal of allowing use cases of existing SSI networks on Hyperledger Indy to be supported by the cheqd network. The following identity-domain transactions from Indy were considered: 1. `NYM`: Equivalent to "DIDs" on other networks 2. `ATTRIB`: Payload for DID Document generation 3. `SCHEMA`: Schema used by a credential 4. `CRED_DEF`: Credential definition by an issuer for a particular schema 5. `REVOC_REG_DEF`: Credential revocation registry definition 6. `REVOC_REG_ENTRY`: Credential revocation registry entry Revocation registries for credentials are not covered under the scope of this ADR. This topic is discussed separately in [ADR 007: **Revocation registry**](/node/architecture/adr-list/adr-007-revocation-registry.md) as there is ongoing research by the cheqd project on how to improve the privacy and scalability of credential revocations. ## Decision ### CL Schema CL-Schema resource can be created via `CreateResource` transaction with the follow list of parameters: MsgCreateResource: * **Collection ID: UUID ➝** (did:cheqd:...:) ➝ Parent DID identifier without a prefix * **ID: UUID ➝ specific to resource, also effectively a version number (supplied client-side)** * **Name: String (e.g., `CL-Schema1` )** ➝ Schema name * **ResourceType** ➝ `CL-Schema` * **MimeType** ➝ `application/json` * **Data: Byte\[]** ➝ JSON string with the follow structure: * **attrNames**: Array of attribute name strings (125 attributes maximum) ```jsonc { "attrNames": ["undergrad", "last_name", "first_name", "birth_date", "postgrad", "expiry_date"] } ``` CLI Example: ```jsonc cheqd-noded tx resource create-cl-schema --private-key cheqd-noded tx resource create-cl-schema zF7rhDBfUt9d1gJPjx7s1JXfUY7oVWkY\ 9cc97dc8-ab3a-4a2e-a18a-13f5a54e9096\ CLSchema1\ "{\"attrNames\":[\"last_name\", \"first_name\"]}"\ --private-key ``` ### Credential Definition \[TODO: explain that a Cred Def is simply an additional property inside of the Issuer's DID Doc] Adds a Credential Definition (in particular, public key), which is created by an Issuer and published for a particular Credential Schema. It is not possible to update Credential Definitions. If a Credential Definition needs to be evolved (for example, a key needs to be rotated), then a new Credential Definition needs to be created for a new Issuer DIDdoc. Credential Definitions is added to the ledger in as verification method for Issuer DIDDoc * **`id`**: DID as base58-encoded string for 16 or 32 byte DID value with Cheqd DID Method prefix `did:cheqd::` and a resource type at the end. * **`value`** (dict): Dictionary with Credential Definition's data if `signature_type` is `CL`: * **`primary`** (dict): Primary credential public key * **`revocation`** (dict, optional): Revocation credential public key * **`schemaId`** (string): `id` of a Schema the credential definition is created for. * **`signatureType`** (string): Type of the credential definition (that is credential signature). `CL-Sig-Cred_def` (Camenisch-Lysyanskaya) is the only supported type now. Other signature types are being explored for future releases. * **`tag`** (string, optional): A unique tag to have multiple public keys for the same Schema and type issued by the same DID. A default tag `tag` will be used if not specified. * **`controller`**: DIDs list of strings or only one string of a credential definition controller(s). All DIDs must exist. `CRED_DEF` entity transaction format: ```jsonc { "id": "", "type": "CL-CredDef", "controller": "did:cheqd:mainnet-1:123456789abcdefghi", "schemaId": "did:cheqd:mainnet-1:5ZTp9g4SP6t73rH2s8zgmtqdXyT?service=CL-Schema", "tag": "some_tag", "value": { "primary": "...", "revocation": "..." } } ``` Don't store Schema DIDDoc in the State. CredDef URL: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue` CredDef Entity URL: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue?service=CL-CredDef` `CRED_DEF` DID Document transaction format: ```jsonc { "id": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "controller": "did:cheqd:mainnet-1:IK22KY2Dyvmuu2PyyqSFKu", // CredDef Issuer DID "service":[ { "id": "cheqd-cred-def", "type": "CL-CredDef", "serviceEndpoint": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue?service=CL-CredDef" } ] } ``` `CRED_DEF` state format: `"credDef:" -> {CredDefEntity, txHash, txTimestamp}` **Note**: `CRED_DEF` **cannot** be updated. ### Rationale and Alternatives #### Schema options not used **Schema. Option 2** Schema URL: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#` `SCHEMA` DID Document transaction format: ```jsonc { "id": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "schema":[ { "id": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#schema1", "type": "CL-Schema", "controller": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "value": { "version": "1.0", "name": "Degree", "attrNames": ["undergrad", "last_name", "first_name", "birth_date", "postgrad", "expiry_date"] }, }, ] } ``` **Schema. Option 3** Schema URL: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue` `SCHEMA` DID Document transaction format: ```jsonc { "id": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "schema": { "id": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "type": "CL-Schema", "controller": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "value": { "version": "1.0", "name": "Degree", "attrNames": ["undergrad", "last_name", "first_name", "birth_date", "postgrad", "expiry_date"] }, }, } ``` **Schema. Option 4** Schema URL: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#` `SCHEMA` DID Document transaction format: ```jsonc { "id": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue", "schema":[ { "id": "cheqd-schema", "type": "CL-Schema", "schemaRef": "did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue?resource=true" } ] } ``` `SCHEMA` State format: * `"schema:" -> {SchemaEntity, txHash, txTimestamp}` `id` example: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue` #### Cred Def options not used **Cred Def. Option 2** Store inside Issuer DID Document CredDef URL: `did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#` `CRED_DEF` DID Document transaction format: ```jsonc { "@context": [ "https://www.w3.org/ns/did/v1", "https://w3id.org/security/suites/jws-2020/v1", "https://w3id.org/security/suites/ed25519-2020/v1" ], "verificationMethod": [ { "id": "did:cheqd:mainnet-1:IK22KY2Dyvmuu2PyyqSFKu#creddef-1", // Cred Def ID "type": "CamLysCredDefJwk2021", // TODO: define and register this key type "controller": "did:cheqd:mainnet-1:IK22KY2Dyvmuu2PyyqSFKu" "publicKeyJwk": { [TODO: Define structure for CL JWK] } } ], "assertionMethod": [ "#creddef-1" ] } ``` `CRED_DEF` state format: **Positive** * Credential Definition is a set of Issuer keys. So storing them in Issuer's DIDDoc reasonable. **Negative** * Credential Definition name means that it contains more than just a key and `value` field provides this flexibility. * Adding all Cred Defs to Issuer's DIDDoc makes it too large. For every DIDDoc or Cred Def request a client will receive the whole list of Issuer's Cred Defs. * Impossible to put a few controllers for Cred Def. * In theory, we need to make Credential Definitions mutable. ## References * [Hyperledger Indy](https://wiki.hyperledger.org/display/indy) official project background on Hyperledger Foundation wiki * [`indy-node`](https://github.com/hyperledger/indy-node) GitHub repository: Server-side blockchain node for Indy ([documentation](https://hyperledger-indy.readthedocs.io/projects/node/en/latest/index.html)) * [`indy-plenum`](https://github.com/hyperledger/indy-plenum) GitHub repository: Plenum Byzantine Fault Tolerant consensus protocol; used by `indy-node` ([documentation](https://hyperledger-indy.readthedocs.io/projects/plenum/en/latest/index.html)) * [Indy DID method](https://hyperledger.github.io/indy-did-method/) (`did:indy`) * [Indy identity-domain transactions](https://github.com/hyperledger/indy-node/blob/master/docs/source/transactions.md) * [Hyperledger Aries](https://wiki.hyperledger.org/display/ARIES/Hyperledger+Aries) official project background on Hyperledger Foundation wiki * [`aries`](https://github.com/hyperledger/aries) GitHub repository: Provides links to implementations in various programming languages * [`aries-rfcs`](https://github.com/hyperledger/aries-rfcs) GitHub repository: Contains Requests for Comment (RFCs) that define the Aries protocol behaviour * [W3C Decentralized Identifiers (DIDs)](https://www.w3.org/TR/did-core/) specification * [DID Core Specification Test Suite](https://w3c.github.io/did-test-suite/) * [Cosmos blockchain framework](https://cosmos.network/) official project website * [`cosmos-sdk`](https://github.com/cosmos/cosmos-sdk) GitHub repository ([documentation](https://docs.cosmos.network/)) * [Sovrin Foundation](https://sovrin.org/) * [Sovrin Networks](https://sovrin.org/overview/) * [`libsovtoken`](https://github.com/sovrin-foundation/libsovtoken): Sovrin Network token library * [Sovrin Ledger token plugin](https://github.com/sovrin-foundation/token-plugin) --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.cheqd.io/node/architecture/adr-list/adr-011-anoncreds.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.