Hey developers! 👋 Check out our documentation for tutorials, API reference, SDK docs, and a forum!

Share on facebook
Share on twitter
Share on linkedin

Trinsic Basics: What Are SSI Standards?

Standards are an important part of the Trinsic platform. Our vision is that people everywhere will have a digital identity that’s as legitimate as their real-world identity. In the real world, standards are an important part of identity. Why do you think that driver’s licenses from different states contain the same information? Or transcripts from different universities look roughly the same? It’s because they’re based on standards that enable any counter party to trust it.

Standards make the world go round

Not to mention, open standards make good business. The ICP/IP protocol the internet runs on is an open standard that beat out the proprietary Microsoft protocols. HTTP is another standard—any browser can visit any website because of it. Bluetooth is another standard—any headphones can connect to any phone, which makes both the headphones and the phone more valuable as a result.

 

Standards enable the Trinsic platform to interoperate with other self-sovereign identity (SSI) and verifiable credentials platforms. For example, if the State of California were to use Trinsic to issue digital driver’s licenses, any business or organization that needed to verify those licenses (such as a pharmacy when people pick up certain prescriptions) would not need to necessarily use the Trinsic platform to do so and vice versa. Any developer that uses the Trinsic platform—including Trinsic’s APIs, Trinsic Studio, and the Trinsic Wallet—will inherit interoperability with solutions that also implements open, community-driven SSI standards.

Avoids vendor lock-in

Standards also enable us to avoid vendor lock-in. The State of California probably doesn’t want to force all its constituents to download a specific company’s digital wallet to store the driver’s license. Instead, it will want its citizens to have the freedom to choose from a variety of apps. (It may help to imagine if the whole internet was run by Microsoft, and you had to have a Microsoft device in order to access government services. That wouldn’t fly, because at that point Microsoft would be a monopoly.)

Not only would the State of California probably want its constituents to be able to choose from a variety of digital wallets, it would want its constituents to have the ability to leave their current wallet provider and switch to another at any time they wish without losing their credentials during the transition. The Trinsic Wallet is one of the first SSI digital wallets to provides its end users with the import/export of credentials functionality.

There are two kinds of standards that Trinsic implements to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.

Data model

Computers are very precise, so it’s important they have a model for how data is structured. For (an oversimplified) example, if you had a database that stores data like this:

{name: “Joe”, email: “Joehd@gmail.com”, dob: “10/22/91”}

Then you will run in to problems if you try to insert the following into the database:

{e-mail: ‘Joehd@gmail.com’, date_of_birth: ‘10/22/91’, f_name: ‘Joe’, zodiac: ‘aries’}

If you needed to share user databases with other people in an industry, you would need to form a standards body (like the W3C or IEEE, etc.) to agree on what data will be collected, what order it appears in, how it’s spelled, punctuation, etc. The more specific the use case, the easier it is to standardize.

 

There are two fundamentally important standards that Trinsic uses, both developed at the W3C:

  • Decentralized Identifiers (DIDs): DIDs are the identifiers used in SSI. They don’t store any data. Think of them as a username, a phone number, an IP address, or any other identifier—except they don’t need a central registry to authorize them. In SSI, every person has a new DID for each relationship they have. And the issuers of credentials have a public DID with a reputation so verifiers can trust it.
  • Verifiable credentials: This is data that an issuer attests about you and signs with their DID. This same thing happens with the DMV in real life—they issue you a credential that others can verify is legit. Only now, there’s a digital version in addition to the plastic. Verifiable credentials answer the question “says who?”.

Protocol

Once we’re using the same data model, we must figure out how to communicate. Theoretically, I could export my verifiable credentials out of my wallet onto a thumb drive and upload them into your wallet (if it supports the verifiable credentials data model), so you can check them out. But clearly, using common protocols is better than that.

DID Communications

DIDComm is an important standard protocol that lets a DID have secure communications with another DID. DIDComm started in the Hyperledger Aries community and recently moved to the Decentralized Identity Foundation (DIF). Every action the Trinsic platform enables, whether it be creating secure connections or verifying a credential, uses some number of DIDComm.

Aries RFCs

At the core of the Trinsic platform is the Aries Framework .NET. The .NET implementation is a collection of implemented standards based on the Hyperledger Aries RFCs (Request for Comment) documents. This is a project that is meant to make apps and clients that can interact with a variety of distributed ledgers. All of the protocol specifications can be found in the aries-rfcs repo here: https://github.com/hyperledger/aries-rfcs.

A protocol is a step-by-step process to accomplish a task. If it’s not followed exactly correctly by either side, the process will fail. I’ll give an example of a university issuing a student ID to someone.

  1. School sends a credential offer to student

  2. Student responds with a credential request to the school, to confirm

  3. School sends a issue credential message to the student, which includes the credential


Trinsic doesn’t have to implement every Aries RFC. But if we implement a feature that can be done in a way that follows an RFC, we will follow the RFC to do so so that it’s interoperable with other implementations.

Our commitment

As SSI continues to mature, the number of related standards will increase and existing standards will evolve. Through it all, our engineering team will ensure that the Trinsic platform is always based on the most recent standards and protocols, so you never have to worry about interoperability or standards compliance. Sign up for a free Trinsic Studio account today to see the beauty of SSI standards in action!