ADR 011: AnonCreds

Status

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 .

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 .

Identity-domain transaction types in Hyperledger Indy

Our aim is to support the functionality enabled by 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

Revocation registries for credentials are not covered under the scope of this ADR. This topic is discussed separately in 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

CLI Example:

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:<namespace>: and a resource type at the end.

• value (dict): Dictionary with Credential Definition's data if signature_type is CL:

CRED_DEF entity transaction format:

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:

CRED_DEF state format:

"credDef:<id>" -> {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_entity_id>

SCHEMA DID Document transaction format:

Schema. Option 3

Schema URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue

SCHEMA DID Document transaction format:

Schema. Option 4

Schema URL: did:cheqd:mainnet-1:N22KY2Dyvmuu2PyyqSFKue#<schema_entity_id>

SCHEMA DID Document transaction format:

SCHEMA State format:

• "schema:<id>" -> {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_entity_id>

CRED_DEF DID Document transaction format:

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.

References

• official project background on Hyperledger Foundation wiki

  • GitHub repository: Server-side blockchain node for Indy ()

  • GitHub repository: Plenum Byzantine Fault Tolerant consensus protocol; used by indy-node