We released a simpler, more accessible pricing model – check it out on our pricing page!

Share on facebook
Share on twitter
Share on linkedin

Trinsic Basics: The Verifiable Credentials Model

At the core of every self-sovereign identity (SSI) use case is what we call the verifiable credentials model. This simple yet effective model helps conceptualize how verifiable credentials are exchanged between people and organizations. In the SSI community, you will often hear the verifiable credentials model referred to as the “Trust Triangle”.

Often called the "Trust Triangle," this classic diagram helps conceptualize the verifiable credential model.

Roles in SSI

In the verifiable credentials model, there are three roles: issuer, holder, and verifier.

 

  • Issuer: The issuer is the person or organization that creates the verifiable credential and gives it (i.e., issues it) to another person, organization, or thing. An example of an issuer would be a DMV which issues driver’s licenses.
  • Holder: The holder is the person or organization to whom the verifiable credential was issued to. The holder keeps the verifiable credential in their digital wallet. An example of a holder would be the citizen that received his or her driver’s license from the DMV.
  • Verifier: The verifier is the person or organization that gets information shared with them. They can authenticate the information they receive instantaneously. An example of a verifier would be the security agent at the airport that asks to see a person’s driver’s license to verify their identity.
In this example, the DMV issues the holder a driver's license as a verifiable credential which the holder then presents to the security agent at the airport (the verifier). The security agent does not need to contact the DMV to verify if the driver's license is a valid credential.

The power of verifiable credentials

Verifiable credentials are unique from other digital documents in that they allow the verifier to know the following four things without having to interact with the issuer at all:

 

  1. The original issuing entity (the source of the data)
  2. It was issued to the entity presenting it (the subject of the data)
  3. It hasn’t been tampered with (the veracity of the data)
  4. Whether the issuer revoked the credential as of a particular point in time (the status of the data)

 

The standards and protocols associated with verifiable credentials and supporting technology make it possible for verifiers to make more informed “trust decisions” when accepting information from holders online. Based on the four factors above, verifiers can better determine to trust the information in the credential or not.

Use case diversity

The verifiable credentials model is quite flexible in the number and types of use cases it supports. In the example above, we highlighted the use case of digital driver’s licenses, but this same model could apply to a numberless amount of use cases where sharing identifying information is important. Here are a few examples:

 

  • Medical insurance credential: In this example, an insurance organization would be the issuer, a person would be the holder, and a doctor’s office could be the verifier.
  • Login credential: When a person is creating an account with a company online, the company would issue the person his or her login credential. From that moment on, the person can use the login credential to access their account, eliminating the need for usernames and passwords.¹ Check out how Trinsic issues login credentials to its customers.
  • University diploma credential: As an issuer, the university would send its graduates their digital diplomas which they could then use to apply for jobs online. Trinsic has written a tutorial on how to set up this specific use case in Trinsic Studio.

 

The SSI use cases above are pretty straightforward, but the verifiable credentials model allows for more complex situations as well. For example, SSI enables the concept of guardianship if a person does not have the ability to control their own wallet (e.g., the person is a child, has dementia, is a refugee, etc.).

 

Further, in the verifiable credentials model the holder does not necessarily need to be a person. Verifiable credentials can be issued to organizations or things. This includes licensing and accreditations for businesses as well as supply chain-related documentation for products. SSI and verifiable credentials enable digital, trusted interactions which were not possible online before.

Build your own use case

No matter your specific use case, Trinsic’s APIs make it easy for developers to integrate SSI.

 

  • Credentials API: Our core API enables developers to have a turnkey way to issue, verify, and manage verifiable credentials on any Hyperledger Indy network. Check out our documentation or one of our reference applications to get started.
  • Wallet API: An API for creating and managing cloud wallets on behalf of credential holders. It’s the backend of our Mobile SDK, which you can read more about in our recent post about building your own SSI wallets. Get started with the API by checking out the documentation.
  • Provider API: Our newest API enables developers to programmatically provision issuer and verifier cloud agents. Learn more about the provider API in the recent launch announcement.

 

Trinsic Studio is an easy-to-use web interface for managing credentials, API keys, verification policies, and more. Sign up for a free Trinsic Studio account and start building your SSI solution today.

Notes

  1. In this case, the issuer and verifier could be the same organization. Or they could be different organizations if the example is a case of federated identity (e.g. Login with FaceBook, Login with Google).