Web Credentials

Web Credentials are based on the W3C Verifiable Credential (VC) data model for expressing cryptographically secure digital credentials on the web. VC provide a data sharing model where signed and linked data can be used to establish trust across contexts.

The VC data model defines two concrete data syntaxes, JSON and JSON-LD (Linked Data). We have chosen to use JSON-LD in our implementation, as it allows the VC data model to be extensible and interoperable while remaining distributed in its architecture.

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

Linked Data (LD) plays a very important role when exchanging verifiable information. JSON-LD is designed to facilitate sharing and discovering data in web-based scenarios. 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:

• @context: When two software systems exchange data, they need to use terminology that both systems understand. This is referred to as the context of their data exchange. For example, in a given context "lastName" may be an attribute that refers to a person’s surname whereas in a different context it might be the latest chronologically assigned name. Contexts map terms to URIs that explain what those terms mean in that context. The @context element is expressed as an ordered set, and all VCs 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: 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.

In addition to JSON-LD properties that are defined in the credential, Web Credentials created on MATTR VII 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).

Core Capabilities

Selective disclosure

Selective disclosure is a technique to preserve privacy in verifiable credentials using the cryptography of BBS signatures. It enables holders to present only specific parts of their credentials to verifiers, based on the content of the request.

You can read more about our work on privacy-preserving verifiable credentials on our blog.

Revocation

Credentials issued using MATTR VII have the capability to be set with a revocation status that can be checked by Verifiers while preserving the privacy of the credential holder. This status can then be updated by Issuers of those credentials to indicate if the credential is revoked or still valid. The holder is also able to use the MATTR Wallet to see the latest revocation status of their credentials at any time.

We have used a W3C specification known as Revocation List 2020 to achieve this in a simple, transparent, and interoperable way.

Refer to our Revocation tutorial to learn more about this capability.

Credential registry

Whenever a credential is created on MATTR VII, a small amount of meta-data is held about the credential. The actual Credential, including information about the subject, is typically stored in the holder’s digital wallet, though it can also be optionally held by the Issuer in the registry alongside the credential meta-data. It is only recommended to invoke this setting when it is appropriate to do so.

A valid use case for the credential registry is in the case of non-personal credentials being held and retrieved for public display, for example, a Verifiable Organization Network or a company’s registry.

Refer to our Credential Registry tutorial to learn more about this capability.

Presentations

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 spec defines a general data model for VPs, but doesn’t specify how to request specific information in a verifiable presentation. Our approach is based on the VP Request Spec at the W3C Credentials Community Group.

MATTR VII incorporates the privacy-preserving capabilities of verifiable presentations in its core capabilities.

Presentations are an area where the mobile wallet plays a very important role. While MATTR VII is used to create templates and generates requests for presentations, it’s the mobile wallet app that generates and derives these presentations and exchanges them on behalf of the user.