Platform Core – Verifiable Credentials

Table of Contents

Introduction

Verifiable Credentials are a W3C standard data model for expressing cryptographically secure digital credentials on the web.

Though they are both part of the VC data model, Verifiable Credentials (VCs) are distinct from Verifiable Presentations (VPs). Presentations are typically generated or derived from VCs and presented by credential holders for the purposes of verification.

The VC data model defines two concrete data syntaxes, JSON and JSON-LD. JSON-LD allows the VC data model to be extensible and interoperable while remaining distributed in its architecture.

When combined with DIDs, VCs provide a decentralized data sharing model where interconnected webs of signed and linked data can be used to establish trust across contexts.

To learn more about our apporach to VCs, read our blog, "JWT vs Linked Data Proofs: comparing Verifiable Credentials".

JSON-LD

Linked Data plays a very important role when it comes to exchanging verifiable information. JSON-LD is designed to faclitate sharing and discovering data in web-based environments. There are several available guides online that describe JSON-LD in detail. We're going to focus on two required properties of JSON-LD that consistently show up in the VC data model, namely @context and type.

@context

@context: When two software systems need to exchange data, they need to use terminology that both systems understand. Credentials contain attributes and values that are defined by basic terminology, i.e. in a given context, "lastName" may be an attribute that refers to a person's surname. Contexts map terms that are used in VCs and VPs to URIs that explain what those terms mean in that context. @context is expressed as an ordered set, and all credentials share the same common context that always appears first in the set, https://www.w3.org/2018/credentials/v1. Contexts are often cached for the sake of performance.

type

type: Related to @context, the type property expresses what kind of information is in the document: is it a verifiable credential? Is it a presentation? Is it an object containing credentials, or presentations? For convenience and semantic interoperability, type is often specified as a set of terms that are defined in the JSON-LD @context.

Usage

The MATTR Platform utilizes Verifiable Credentials extensively in our Platform Core. Core allows our users to create, store, retrieve, manage, and delete Verifiable Credentials.

In addition to JSON-LD properties that are defined in the credential, VCs created on our platform will often include the DID & in some cases the domain name of the issuer, as well as some kind of identifier for the subject (typically also a DID).

NOTE: We have developed an experimental feature in our platform around Zero-Knowledge Proofs (ZKP). It's a technique to implement privacy-preserving selective disclosure in verifiable credentials using the cryptography of BBS+ signatures. As ZKPs are experimental, they only work with did:key method at this point. To experiment with this feature, use your API endpoint to create a DID with "method":"key" and "keyType":"bls12381G2" parameters set. If you create a Verifiable Credential using this new DID as the issuer DID, the platform will automatically detect this capability and create a ZKP-enabled BBS+ credential for you. Our Mobile Wallet App can detect if ZKP is enabled in a credential, and upon request for verification, will use that information to derive a new credential presentation that selectively discloses the required info using ZKP. You can read more about our work on privacy-preserving verifiable credentials on our blog.

For more detail on our Verifiable Credential capabilities, check out the API Reference Docs.