Digital Identity and Verifiable Claims

Ramya Donekal, June 13, 2019

This article was originally published on Linkedin

We are all familiar with Identity and Access Management. IAM has been very early on identified as a candidate blockchain use case. A well known example is “Know Your Customer” more commonly known as KYC. The Hyperledger Fabric provides the Fabric-CA to issue credentials to participating agents and users in a permission-ed blockchain. In 2016, I had worked on a blockchain project around private-equity, where all identities and permissions to access the “equity contract” were driven by the blockchain smart contracts.

Before we proceed further, we have to understand a few terms like claim and credential.

Claims and Credentials

A claim is an assertion about a thing or statement without necessarily providing proof or evidence. For example a potential employee could claim to be an electrical engineer.

A claim cannot be verified if it is not supported by evidence. The supporting evidence is usually in the form of one or more credentials such as a University degree, on-the-job training certificate from a company, letters of reference etc. A credential is a qualification or testimonial that is issued by an entity to a business, thing or individual. For example, a quality certificate issued by a manufacturer for an IoT device, an insurance certificate issued to a business by an insurer are all examples of credentials. A claim may be supported by one or more credentials.

Identity

Identity is often associated with some credentials issued by an organization, agency or computer application. For example, a person may have a login/password for accessing their Facebook account, credentials provided by their employer for accessing enterprise applications, a government agency issued identity such as a driver’s license or password for accessing public services etc.

A person’s identity is usually a set of claims made by the person, and usually backed by a set of credentials in support of those claims. A set of claims/credentials can be presented to an entity to issue new credentials that can be used as proof of identity and/or perform certain actions based on privileges granted by the issuing entity. For example, an individual could present his/her birth certificate and proof of residency to the DMV to obtain a driver’s licence which doubles as proof of identity and license to operate a vehicle.

Traditionally, people carry physical identities such as the passport book, driver’s license card, diplomas and degree certificates, birth certificates and the like to submit as proofs of identity to interested parties. With the digital age, new forms of digital identity such as fingerprints, retina scans, user-id/passwords, digital certificates, digital passports have evolved.

What is self-sovereign Identity

There are various models for managing identity and access, and fall into centralized, federated and self-sovereign (self managed).

In the centralized model, the credentials are issued by a central entity or authority. Corporations provide and maintain identity credentials for enterprise access, Government agencies issue identity credentials to access public services, and in both the above cases, a user’s identity is under the control of the issuing entity.

However, as individuals require access to multiple services and applications, managing credentials issued by multiple entities could get complex. In a federated model, multiple entities can subscribe to the same (unique) set of credentials that an individual owns, or multiple credentials issued by various entities can be mapped to one set of credentials. Usually a broker provides such a service. Examples include a “single sign-on” service or a “Facebook account” that many entities trust.

In traditional identity management systems, an individual’s, entity’s or thing’s identity is centrally managed by the issuing agent. Now, for instance, if the DMV decides to revoke an individual’s driver’s license, that individual has lost his/her identity which is typically used to check-in at the airport or present to a front desk in a hotel. If a person visit’s a bar where an ID check is required to serve a drink, usually, folks present their driver’s license. Even if the license carries information about the date-of-birth, if the license has expired, most often, the bar will refuse to honor the card.

Distributed Self Sovereign

If an individual, organization or thing can manage its identity (claims and credentials) along with the rights to present such information fully or partially to any other party, it can be considered as self-sovereign identity management. Such an identity management approach can enable the identity holder to have a uniform approach to share credentials universally with any local or foreign entity.

DIDs and Verifiable Claims

Decentralized Identifiers are a new type of identifier for verifiable, “self-sovereign” digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. This is an example of a DID that has been proposed to establish the identity of a supplier in the “Trust Your Supplier” solution built by Chainyard.

did:tys:2XhdfxCGMpz7MHEKBwbadCZd6aBd

DIDs follow the URN (uniform resource name) notation i.e. scheme:namespace:value. The scheme is did. In the above example, the namesspace is “tys”. DIDs resolve to DID Documents which specify the details and usage of that specific DID. For more information check the DID specification by clicking here.

No alt text provided for this image

The value associated with the DID can be any value such as a uuid, random number, base64, public key or base 58 encoded hexa or decimal string. The TYS DID is a base58 string of a public key hash. The following sample code generates a TYS base58 encoded did.

No alt text provided for this image

Along with DID, came the “Verifiable Claims” specification. As per the verifiable claim spec, a verifiable credential can represent all of the same information that a physical credential represents. The verifiable claim has to to adhere to a minimum required format that must include among others, public keys, digital signatures, key generation method, authentication schemes, authorization schemes, DIDs and their type etc.

A verifiable credentials can be used to generate presentations that make it easy to present credentials to stakeholders. The specification is a candidate submission with the W3C. For more information about claims and verifiable claims,click here.

The DID Method Registry

The DID Method Registry maintains a list of companies that have published their DID specification. Enterprises and entities can choose to adopt one of the published specs or define their own version. The document provides a method for registering a new spec. For example, the TYS specification is available at this link and has provisional approval. We still have to complete the implementation and ensure that any changes to the DID Method Document specification is addressed and the methods defined are implemented.

Once a DID Method Specification has been published, the method end-points have to be resolvable through a DID Resolver (driver). DID API calls use the REST specification. A DID Resolver will help resolve a DID as shown in this example code.

tysDID.resolve(did:tys:2XhdfxCGMpz7MHEKBwbadCZd6aBd)

will resolve to a TYS Supplier DID/DID Document. The resolver has to provide the following REST operations:

  • Create or Resolve
  • Update
  • Query or Read
  • Revoke
  • Delete
  • Additional operations included in TYS are getList, getDocument etc.

The following shows a sample representative query result:

No alt text provided for this image

The TYS Specific driver will be wrapped into “Universal Resolver” that can resolve a DID issued by any conforming organization. DID resolver can be written any language that can be wrapped into the Universal Resolver.A very nice article by Markus Sabadello on the universal resolver can be found here. The Decentralized Identity Foundation aka DIF is driving the initiative.

Key Personas

Before we proceed further, some concepts and roles need to be ironed out. The following personas are usually involved in an identity management scheme.

The Credential holder, the Relying Party, The Credential Issuer, The Credential Verifier or one that can attest to it.

No alt text provided for this image

The Credential holder is an individual, agency, business or thing that holds a credential. Examples include an individual holding a university degree, a business entity carrying business insurance, an IoT device that holds a manufacturer issued proof-of-existence.

Credentials are issued by some individual or entity and are also known as the Issuing Agent or Issuer. The university that issues the degree, the DMV that issues the driver’s license or the manufacturer that signs the IoT certificates are all issuers.

Verifiers are entities and agents who can attest the credential. Sometimes the verifier and issuer are one and the same. However, when I graduated back in the 80’s, my degree was a paper diploma issued by my alma mater BITS Pilani. I had copies of my degree attested by a lawyer or a gazetted officer. In the US, third party agencies are used to verify information submitted.

Finally, the entity, be it a loan officer, an employer or the TSA, all trust the credentials that the identity holder submits. They are the Relying Party and trust the information submitted.

There may be additional personas depending on the application and the implementation of the platform. For example, in Hyperledger Indy, there are stewards or trust anchors and agents.

Credential Ownership and Sharing

In self-sovereign identity, the Identity Holder holds the rights to completely, partially or not share their identity(s) with a relying party. Issuers hold the rights to revoke an issued credential.

Let us take the case of the bar. Instead of sharing the whole driver’s license to prove age, the identity holder can turn on just the verified credential supporting his/her age to the hostess. The credential issuer has authority to revoke a credential if necessary. For example, the DMV can revoke the driver’s license if there was a DUI conviction.

Applications and Use Cases to Supply Chain Problems

The concept of DIDs and verifiable credentials have many applications. The most common one is KYC or Know Your Customer are there are initiatives such as Hyperledger Indy yo make that happen.

There are several fit for purpose implementations focused on identity management such as SovrinDigital BazaarVeres One, TYS and uPort and one can go to their websites to understand more.

Sovrin is a public implementation of the Hyperledger Indy open source project, an open source project for decentralized self sovereign identity management. Sovrin is managed by the Sovrin Foundation. The original code for Hyperledger Indy was contributed by Evernym.

Veres One is a fit-for-purpose special purpose blockchain that has been optimized for managing identities on the internet.

Digital Bazaar is focused on providing a public blockchain called Bedrock is an application platform that helps you get your ideas to market quickly by reducing the engineering effort of launching a new product. The company also provides solutions for verifiable credentials management. Manu Sporny, its founder has been a key figure in the evolving digital identity and verifiable credentials initiatives.

uPort is a blockchain platform built on Ethereum. uPort’s open identity system allows users to register their own identity on Ethereum, send and request credentials, sign transactions, and securely manage keys & data.

At Chainyard, we are working on a Supplier Identity Platform known as “TYS” or Trust Your Supplier. TYS provides DIDs for supplier identities and verifiable credentials that the supplier holds. TYS is pre-production state and will be going live in a few weeks.

DID Use Cases

There are many other applications for DID and verifiable credentials. Imagine high value items and luxury goods. If each of the Luxury items had a DID issued by its manufacturer along with verifiable credentials, the blockchain along with supporting technologies (BIVA) can be deterrent against fraud and counterfeiting.

In the US, a person can buy used vehicles. The identity of a car is the VIN number. What if the car was issued verifiable credentials associated with DIDs around service records, inspections, factory authorized replacements and manufacturer certification?

DIDs can be expanded to be applied to vintage cars, high value art — many of these exist for a long long time, long after their original and subsequent owners lifetimes.

The United Nations deals with several problems from tracking and issuing credentials to displaced peopletracking endangered species to name a few.

Horse owners involved in the owning, training and racing of highly valuable horses could provide digital identities to their animals or even closer — every pet has a digital identity.

The Blockchain and SSI

The following diagram shows how the SSI and Blockchain are conceptually implemented.

No alt text provided for this image

Depending on the blockchain technology used, the physical documents that the did document refers to may be stored on-chain or an off-chain database. For example, TYS is implemented on the IBM Blockchain Platform based on Hyperledger Fabric. It has capability to not only issue DIDs and DID Documents, but also store the physical documents that the DID Document refers to. The Physical Documents and PII (personally identifiable information) data are stored off-chain due to regulatory compliance requirements.

Back to top