JSON-LD is a lightweight Linked Data format. It is easy for humans to read and write. It is based on the already successful JSON format and provides a way to help JSON data interoperate at Web-scale.

Linked Data empowers people that publish and use information on the Web. It is a way to create a network of standards-based, machine-readable data across Web sites. It allows an application to start at one piece of Linked Data, and follow embedded links to other pieces of Linked Data that are hosted on different sites across the Web.

Using JSON-LD Credentials

The main difference between JSON-LD credentials and JSON credentials is the inclusion of a @context field within the credential payload.

In JSON-LD, the @context property can also be used to communicate other details, such as datatype information, language information, transformation rules, and so on, which are beyond the needs of this specification, but might be useful in the future or to related work.

Example of the JSON-LD @context section

{
  "@context": [
    "https://www.w3.org/2018/credentials/v1",
    "https://www.w3.org/2018/credentials/examples/v1"
  ],
  "id": "http://example.edu/credentials/58473",
  "type": ["VerifiableCredential", "AlumniCredential"],
  "issuer": "https://example.edu/issuers/565049",
  "issuanceDate": "2020-05-01T06:09:10Z",
  "credentialSubject": {
    "id": "did:cheqd:c822493c-9728-4279-bc88-a03904fff8b2",
    "alumniOf": {
      "id": "did:cheqd:66694a94-b6b3-4731-ab65-dc80bb24e58d",
      "name": [{
        "value": "cheqd University",
        "lang": "en"
      }, {
        "value": "cheqd d'Université",
        "lang": "fr"
      }]
    }
  },
  "proof": {  }
}

AnonCreds are a type or flavour of Verifiable Credentials that were originally developed by the company Evernym, and were subsequently adopted by the Sovrin Foundation as part of the 'Indy' codebase that was contributed to Hyperledger, a Linux Foundation project. This codebase was forked into the Hyperledger Indy project for ledger code, Hyperledger Ursa for cryptographic libraries, and the ledger-agnostic Hyperledger Aries codebase for agent, wallet, and credentialing code.

AnonCreds are now far more widely adopted, through organisations such as the Government of British Colombia, IDunion and the IATA Travel Pass.

How are AnonCreds different to other Credential types?

AnonCreds were designed to provide additional privacy benefits, compared with JSON and JSON-LD based Verifiable Credentials. There are a series of differences that can be summarised as follows:

• Camenisch-Lysyanskaya (ZKP CL-Signatures): a Credential format which is not defined in the W3C Verifiable Credential Data Model. Rather it is a bespoke data expression format coupled with a particular digital signature algorithm.

• Link Secrets: A mechanism to link ZKP-CL credentials to DIDs, by including a DID for the holder in the credential’s schema. Holders can prove that Credentials are not tampered with and that they are authentic, since holders are the only party that knows the Link Secrets made at the point of issuance.

• Schemas: The schemas are defined in a document and they are written to an Indy ledger where they can’t be changed. To update a schema, a new version must be created and written to the ledger for future use. This schema is fetched from the ledger by verifiers when calculating the verification.

• Credential definitions: Each issuer of a Verifiable Credential must post a credential definition that says to the world, "I intend to publish credentials from schema X, signed using keys Y[0]...Y[N], and with revocation strategy Z". This helps verifiers prove that the Credential has not been tampered with.

• Predicate proofs: Through the use of link secrets and Indy schemas, it is possible to present an assertion, such as "date_of_birth is more than 18 years ago)", without revealing any additional information.

• Privacy preserving revocation: Using cryptographic accumulators and 'tails files', revocation statuses can be queried without creating a chain of correlation through which a user's privacy can be compromised.

The ZKP-CL processing model requires that the credential’s schema is defined and posted to an Indy ledger. The credential issuer follows the pre-defined schema. They leverage the CL Signature suite to sign each statement in the credential. The credential is anchored to a link secret that is known only to the holder (stored in the holder’s software), and when the holder is issued a credential, it packages up a cryptographic commitment to the link secret within another long number that the issuer uses for the credential ID.

A metaphor for this is that of a digital watermark; the link secret is like a stamp that is used to create a watermark. The stamp used to create the watermark is NOT packaged up or put in the credential in any form; all that is in the credential is very-hard-to-fake evidence that the holder possesses the stamp and is capable of generating such watermarks. Unlike non-ZKP methods, zero-knowledge methods generally do not share a correlatable identifier (such as a persistent or public DID) and also do not reveal actual signatures. Instead, they only reveal a cryptographic proof of a valid signature. This means the holder of the credential cannot be correlated just by presenting a proof of the credential (this is the primary privacy problem with public/private key cryptography that ZKP-CL Signatures were invented to solve over a decade ago).

All other non-ZKP Signature formats require a resolvable DID—which is a correlatable globally unique identifier—and also produce the same signature on all equivalent presentations, which is a second fully correlatable globally unique identifier

Why are AnonCreds a contentious issue?

AnonCreds have been the subject of heavy debate within the decentralized identity community for the following reasons:

• Interoperability: AnonCreds are intrinsically tied to Hyperledger Indy, and largely to Hyperledger Aries. Historically, they cannot be written to other Layer 1 Utilities, nor are they compliant with the W3C Verifiable Credential data model, given their core architectural differences. As such, this shoehorns adopters into a particular tech stack, which although open source, is largely reliant on the Indy/Aries community for updates, since there is no formal Standard.

• AnonCreds v1 is being proposed as a Standard and is in the process of being taken to the Internet Engineering Task Force (IETF).

• Scalability: The use of ZKP-CL signatures, whilst certainly containing benefits from a privacy perspective, are very large files which can lead to inefficiencies when used at scale in production environments.

• Hyperledger Indy has performance and scalability issues when it comes to running more than 25 nodes in terms of its throughput. Its method of revocation also generates very large files, which is very slow to compute in a low-latency environment.

Nonetheless, many proponents of SSI contend that AnonCreds are still the most production-ready Credential types at this present instance. Certainly, AnonCreds are the only off-the-shelf Credential type that can provide privacy-preserving functionality such as predicate proofs, which is why, for example, Governments such as BC-Gov are large proponents of AnonCreds.

In order to explain the concept of Verifiable Credentials, we have put together a simple explainer using the concept of an email with attachments.

Further reading

More more of a detailed and deeper understanding, we suggest starting with these external resources.

Overview

There are multiple types of Verifiable Credentials, each with their own set of benefits and features:

A Verifiable Presentation is a combination of Verifiable Credentials, bundled together into a format to present to a third party.

Like VCs, Verifiable Presentations contain proofs (i.e. they can be signed with cryptographic keys). In this regard, a major difference between VCs and Verifiable Presentations is that Verifiable Presentations are signed with cryptographic keys of the holder to prove, for example, that the actor who is sharing the Verifiable Presentation is also the credential subject of the underlying VCs.

With some credential formats like AnonCreds, holders can freely choose which information (from underlying VCs) they include in a Verifiable Presentation and thus, share with a relying party. It is even possible for holders to prove to a relying party that they possess a certain attribute or fulfil certain conditions without disclosing details (e.g. the proof that one is older than 18 without revealing the real age) via so-called 'Zero Knowledge Proofs'.

There are multiple standards used for Verifiable Presentations, that will be listed below:

Aries Present Proof

Presentation Exchange 2.0.0

What is Selective Disclosure?

Selective disclosure empowers an individual to decide which specific pieces of information, contained within a Verifiable Credential, will be disclosed to a verifier. This stands in contrast to the conventional practice of revealing all the data present in a Verifiable Credential.

For instance, Alice could selectively share only her age to confirm eligibility for purchasing products on an e-commerce platform, without divulging other personal details found in her Verifiable ID document used for verification. This approach enhances privacy and provides individuals with greater control over their personal data.

The Significance of Selective Disclosure

Selective disclosure is a crucial element of Self-Sovereign Identity (SSI) because it allows individuals to share only the essential personal information required for a transaction or interaction. This minimizes the risk of identity theft and various forms of fraud.

SD-JWTs: A Mechanism for Selective Disclosure

A Selective Disclosure JSON Web Token (SD-JWT) is a subtype of JSON Web Token wherein the claims within the body are hashed, rendering them unreadable without proper disclosure. The original values of the claims can be unveiled by providing the necessary disclosures.

How it Operates

When presenting a conventional credential via JWT, the claims are plainly visible to the verifier. In contrast, with an SD-JWT credential, claims are encrypted in a hashed format, ensuring their unreadability. The holder can then choose which claims to reveal to the verifier by providing plain text key-value pairs (referred to as disclosures) alongside the SD-JWT. The verifier can hash these disclosures and compare them to the values in the SD-JWT, thereby verifying the inclusion of the claim in the SD-JWT. Additionally, SD-JWTs allow for the inclusion of decoy hashes in the credential, serving as dummy values to obfuscate the actual number of claims in the credential.

JSON Web Token (JWT) is an open standard () that defines a compact and self-contained way for securely transmitting information between parties as a JSON object.

This information can be verified and trusted because it is digitally signed.

JWTs are widely used in legacy identity infrastructure, underlying the frameworks used by and . As such, there is a plethora of software libraries and toolkits for developers to build upon using JWT, making their adoption far more seamless than other Verifiable Credential formats.

A "", in an everyday sense, is an attestation, evidence or proof of qualification, competence or authority issued to an entity, either individual or person, by a third party with relevant authority or assumed competence to do so. This may be evidence of authority, status, rights, entitlement to privileges, or the like, usually in a written form.

Historically, we have relied on public issuing bodies to verify our identities — i.e. passports, driving licence, birth certificates, etc. These credentials go on throughout our lives, being issued to us or requested by us at times we need them. We provide them to others regularly, without ever wondering what happens to them, where they now sit, and how long they’ll be retained.

Essentially credentials are a means to verify identity.

What is a Verifiable Credential?

A Verifiable Credential ("VC") is a tamper-evident data file with a set of claims about a person, organisation, or thing that can be cryptographically verified. These verifiable credentials can be used to build , which can also be cryptographically verified.

Okay, stop there, let's simplify what this technical language means.

A familiar concept: Email

Let's imagine something we're all familiar with.

Here's a classic email with some attachments.

This is how most people are familiar with sending information about themselves digitally.

I am sure everyone reading this has had to attach a photocopy of their passport to an email, in order to prove that they are who they claim to be. Or alternatively, has attached their CV to an email to prove their work and education records, either as a word document or PDF.

The problem with this system, is that it is not currently possible to check the validity of an attachment sent via email. Word Documents, PDFs, JPEGs etc have no security features that allows a third party to check if they were legitimate or not.

Let's take the example of the CV. You receive it as an attachment, you read it, and to check the validity you need to contact the references which are generally at the bottom of the CV to check whether this person really did all the things they claim to have done.

This is time consuming, and frequently, owing to the lack of trust in these data formats, can be susceptible to fraud.

How do Verifiable Credentials change this?

A Verifiable Credential is a digital file that stores data. However, importantly it is designed to hold two core types of data:

• Claims

A claim is an attestation about something. It could say that "I went to Oxford University".

• Proofs

The verification key material and the Decentralised Identifier ("DID") enable the issuer to essentially sign the claims in the credential, to vouch for their autheneticity.

Why is this useful and important?

Verifiable Credentials change the way that data can be trusted when presented. This is because when you receive a Verifiable Credential, you are able to check, without contacting another party:

1. Whether that data was issued by a specific issuer;

2. That the data hasn't been tampered.

Unlike attachments in an email, which are data files that need to be independently verified, to trust their contents; Verifiable Credentials enable that verification innately, through the use of Decentralised Identifiers. This is a powerful component for building trust in a decentralised Web 3.0.

Therefore, you can reach the definition:

A Verifiable Credential ("VC") is a tamper-evident data file with a set of claims about a person, organisation, or thing that can be cryptographically verified. These verifiable credentials can be used to build Verifiable Presentations, which can also be cryptographically verified.

For more information, please see the Verifiable Credential Data Model Specification below: