Exploring digital credentials

When it comes to digital credentials, there are several alternatives we can consider and, in most cases, we will hear about Verifiable Credentials (VCs), Open Badges and Blockcerts.

Their goal is to provide a trustable record of achievements that can be shared on the Web, simplifying the interaction between three entities - issuer, holder and verifier - in a model called the triangle of trusts (Figure 1).

Once digital credentials are issued, the holder needs a specific application as a vault to store them. This application can reside on a user’s device, can be hosted on a server, or could be a combination of both.

The purpose of this article is to analyze said alternatives individually to discover their peculiarities.

Verifiable Credentials

VCs are an open standard defined by W3C Verifiable Credentials Data Model, which provides a mechanism to express credentials in a way that is cryptographically secure, privacy respecting and tamper-evident.

Information is encrypted and protected by digital signatures hence not readily visible to everyone. Those in possess of the public key can verify the authenticity of the issuer and the holder.

VCs feature three main components: metadata, claims and issuer proof (Figure 2).

The metadata is used to describe properties like issuer, expiry date, representative image, and so on; a claim is a name-value statement about a subject (typically a person, but it could also be a thing) and the issuer proof is used to verify the integrity of a credential expressed as a digital signature (made with the private key of the issuer).

Here is an example:

{
  "@context": [],
  "id": "e9ea3429-b32f-44ad-b481-b9929370bb90",
  "type": [ "VerifiableCredential", "DegreeCredential" ],
  "issuer": { "id": "did:example:2d28bb79-87a9-4224-8c63-d28b29716b67" },
  "issuanceDate": "2022-01-01T00:00:00Z",
  "credentialSubject": {
    "id": "did:example:7564cb9c-165c-4857-a887-bfc2460af867",
		"degree": {
      "type": "BachelorDegree",
      "name": "Bachelor of Computer Science"
    }
   },
	"proof": { ... }
}

The code illustrates how the structure of the JSON is mapped to the components above. The Claim section, which begins with ‘credentialSubject’, indicates that the user has a computer science degree. The Issuer Proof part, not shown for space reasons, contains the cryptographic signature suite used to generate the signature (RSA, JWS, GPG, etc.) and its value.

An entity called Verifiable Data Registry (VDR) acts as an arbitrator and mediates the generation and verification of identifiers, keys, and other data (Figure 3).

VDR ensures that other entities respect the defined rules and this includes that: the credential conforms to the specification; the proof method is satisfied; and, if present, the status check succeeds. Otherwise, their requests will be denied. Different ecosystems will have different VDRs with different sets of rules, which might mean that they are unable to interoperate.

Open Badges

The IMS Global Learning Consortium currently maintains the Open Badges standard (initially developed by the Mozilla Foundation), which describes a method to incorporate non-visible metadata in PNG or SVG image files (Figure 4).

An Open Badge image may contain a variety of data, including the badge’s name, issuer, and description. All of this information is baked into the image, so only Open Badge-compatible applications can show it. Because of this visual representation, Open badges are highly portable.

Various organisations can implement Open Badges in their own way, subject to some mandatory properties that must be present to comply with the standard. Since there might be some variations in the implementation, the verification process is dependent on the Issuer.

The verification process can be done in two ways:

1. Hosted Verification — One of the metadata properties of an Open Badge is the assertion id, a URL that host the metadata in a .json file. If this URL cannot be found, the badge is not verifiable.
2. Signed Verification — Information is encrypted to ensure that the data has not been altered and that the issuer is the one who generated it. The public key used to sign the badge must be traceable to the issuer.

Verifying Open Badges may require extra expenses such as a subscription/payment to use the verification tool and reliance on third-party providers.

A badge that can be confirmed via the hosted verification process looks like this:

{
  "@context": "https://w3id.org/openbadges/v2",
  "type": "Assertion",
  "id": "https://example.org/assertion.json",
  "recipient": {
    "type": "email",
    "identity": "johndoe@example.org"
  },
  "image": "https://example.org/badge.png",
  "issuedOn": "2022-01-01T00:00:00Z",
  "badge": "https://example.org/type-of-badge-awarded.json",
  "verification": {
    "type": "hosted"
  }
}

Personal information (PII) included in Open Badge metadata may include last name, email address (like above), phone number and evidence. Most badge platforms do not display this data publicly, and the achievements can be secured through an authorization login. However, an Open Badge image file contains this information and can be opened and viewed.

In 2018, Mozilla recognized that badges alone do not attract users unless they are strongly linked to learning program offerings. For these reasons, they created the Open Badge Infrastructure (OBI), which allows developers to integrate badge services within existing applications, websites, or social networks through open APIs; enabling them to support third-party endorsements on issuer badges or personal badges.

Blockcerts

Blockcerts is an open standard offered by MIT Media Lab used to digitally express a certificate and store it in a blockchain so that it can be always verified without the need to contact the issuing institution or platform (Figure 5). Blockcerts aim to give individuals full control over their educational and professional credentials and provide institutions with a secure, tamper-proof way to issue and verify them.

The blockchain contains the document’s digital fingerprint (hash) and does not store any private information. The information recorded in the blockchain cannot be used to deduce the contents of the certificate but only the integrity. Only the certificate’s owner can choose to communicate the information on it with a third party, such as a potential employer.

Three repositories make up the architecture:

1. Cert-schema — Describes the data standard for digital certificates. The schema was kept close to the Open Badge specification intentionally (forked from IMSGlobal/cert-schema).
2. Cert-issuer — Creates a hash of a certificate, issues it, and broadcasts a Bitcoin transaction from the issuer’s address to a recipient’s address, embedding it in the OP_RETURN field.
3. Cert-viewer — This allows users to view and verify digital certificates after they have been issued. The viewer code also allows users to request certificates and create new Bitcoin identities.

The verification process can take place both on the platforms that adopt the standard and via the default tool Blockcerts Universal Verifier.

Storing data on the blockchain may require a large amount of computing power and financial costs. To increase the level of security and reduce the cost of these information processing operations, the standard aggregates all certificates issued that day and stores the electronic fingerprints as a single record by linking them mathematically (Merkle Tree).

In 2016, an article on medium.com published by MIT Media Lab stated:

The blockchain is not a simple solution that will fix everything that is wrong with today’s credentials. But it does offer some possibilities for improving the system we have today–and that’s what we are excited to explore.

Comparison

Based on the previous observations, we can make a comparison table between the listed standards and thus get a more general view and a clearer picture of the situation.

Feature	Verifiable Credentials	Open Badges	Blockcerts
Organization that governs the standards	W3C	IMS Global and Mozilla Foundation	MIT Media Lab
Applications	Wide range of fields from healthcare to travel	Mostly in education and employment to some extent	Mostly in education
File Format	JSON - Human and machine readable	PNG/SVG - Fixed image format	JSON - Machine readable and human readable with viewer
Tamper-evident	Yes	No - Display could be changed, since data hosted elsewhere	Yes - Blockchain-enabled verification
Verification	Built-in through digital signatures	Requires third-party tools that could entail additional costs and dependencies	Requires a tool that can be implemented on platforms or found on the main page

Everyone can see the benefits of reliable digital credentials, especially when they protect privacy and improve convenience for everyone involved. However, it is up to us whether those records will be accessible and verifiable independent of a particular vendor’s infrastructure.

---

References

• W3C Verifiable Credentials Data Model
• Open Badges Specification
• Blockcerts - Quick start
• An Update on Badges and Backpack - Mark Surman, Executive Director, Mozilla
• Compare and Contrast: OpenBadges vs Verifiable Credentials - Affinidi Pte. Ltd.
• Open Badges as Verifiable Credentials - Kerri Lemoie
• Clarification of the Verifiable Data Registry (VDR) (GitHub issue)
• Verifiable Credentials - how does it work? Understanding key VC principles - Petteri Stenius
• Blockcerts are friends of Open Badges - Doug Belshaw
• What we learned from designing an academic certificates system on the blockchain - MIT Media Lab