2 of 11

Example uses of VCs

Using an electronic prescription

The prescription is written in the form of a VC, where you are the subject, the doctor is the issuer, and the contents are the drugs that have been prescribed to you.

Opening a bank account

The bank trusts the government and accepts your VC to issue you a new VC that provides your bank account details, and you add this to your set of VCs on your mobile phone.

2.5 days

Receiving a free local access pass

You have a VC issued by the local senior citizen center and your mobile phone transfers a copy of your bus pass VC to the operator, who then grants you free access to the bus.

VCs can be used for much more because they are digital.

3 of 11

Lead

Issuer

The entity that issues VCs to users.

Subject

The entity whose properties are stored in the VC.

Holder

The entity that is currently holding the VC and presents it to the Verifier.

The VC ecosystem

The entities and roles in the VC ecosystem.

The overall architecture of VCs, in which the holder sits at the center—the essence of user-centric design.

Verifier

The entity that receives the VCs from the Holder and provides benefits in return.

Wallet

The entity that holds the VCs for the Holder.

Holder’s Agent

The software that interacts with the VC ecosystem on behalf of the Holder.

Verifiable Data Registry

An internet-accessible registry that holds all the essential data and metadata that enables the VC ecosystem to operate.

4 of 11

The VC trust model

Specific trust relationships in the VC trust model

The VC trust model, where holders are at the center, and verifiers only need to trust issuers (and the verifiable data registry trusted by all parties).

The FIM architecture places the IDP at the center of the ecosystem, whereas the VC architecture places the holder at the center of the ecosystem.

The credential can be digitally signed and the digital signature can be cryptographically verified.

Federated identity management

5 of 11

Syntactic representations

The two syntactic representations defined by the VC data model 1.0 specification are based on JavaScript Object Notation (JSON), which is a simplification of the syntax used to represent collections of data items in the JavaScript programming language.

JSON-LD

JWT

Server

JSON-LD representation and the JWT representation.

6 of 11

Basic VC properties

VC claim

VC metadata

Proof

The most basic VC needs to hold only six pieces of information.

The structure of a basic VC, showing the metadata component, the claim component, and the proof component.

Context—When people communicate, they need to know what language and vocabulary to use.

Type—The type property contains a list of URIs that assert what type of VC this is.

ID—The ID property is the unique identifier of this VC, created by the issuer.

Issuer—The issuer property uniquely identifies the issuer.

Credential Subject—This property contains the claims the issuer is making about the subject. It consists of the ID of the subject and the set of properties the issuer is asserting about the subject.

Proof—For a credential to be verifiable, it needs a signature, referred to more generally in the VC Data Model spec as a proof.

7 of 11

Verifiable presentations

Set of VCs

VP metadata

Proof

A VP is one way a holder may combine several VCs to send to a verifier.

A basic VP that contains a group of VCs plus metadata about them.

It is very similar to a VC in that it contains metadata about the presentation plus a proof signed by the holder. The notable differences between a VC and a VP are:

the issuer property is missing
id property is optional

It is very similar to a VC in that it contains metadata about the presentation plus a proof signed by the holder. However, the contents are now a set of VCs rather than a set of claim.

Similar to VCs, a VP may contain multiple proofs.

8 of 11

More advanced VC properties

VCs were developed using an open-world model, meaning anyone can add any property to a VC that is suitable for their application needs. Nevertheless, there are several properties that VCWG thought would be generally useful for a range of applications.

Evidence

The evidence property is designed for the issuer to help the verifier determine the level of confidence it can have in the claims inside the VC.

When the holder is not the subject

For security purposes, both the subject and the issuer should give their permission for the VC to be transferred. The VCWG is standardizing a way for the issuer to mandate that the VC must not be transferred.

Most physical VCs today are governed by terms of use.

Disputes

In some cases, the VCs that exist are false, and the rightful subject wants them to be revoked.

Refresh service

VCs are designed to have a limited lifetime for several reasons.

Anyone can extend a VC in any way they wish – interoperability issue.

9 of 11

10 of 11

Hurdles to adoption

Today’s federated identity management infrastructures give issuers (IDPs) great power because they are at the center of the ecosystem. VCs turn this model on its head and place users at the center. So, issuers will need to see some financial benefit before they are willing to move.

11 of 11

Pando DID: pando.network

KEN Labs Research: kencloud.com

info@pando.network

twitter.com/KenLabs_Web3

THANK YOU

WATCHING