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": {  }
}

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.

Overview

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

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.

AnonCreds are a type or flavour of Verifiable Credentials that were originally developed by the company , and were subsequently adopted by the as part of the 'Indy' codebase that was contributed to , a project. This codebase was forked into the project for ledger code, 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 , and the .

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.

• 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.