Open Standards

Why we adhere to public standard protocols

Standards are an important part of the Trinsic product stack. 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 a crucial part of identity. Why do you think that driver’s licenses from different states contain the same information? Or transcripts from different universities look the same? It’s because they’re based on standards that enable any party to trust it.

Standards make the world go round


Not to mention that 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 us to interoperate with the community. This is crucial for adoption of the technology.

Avoid vendor lock-in

Standards also enable us to avoid vendor lock-in. The State of California, for example, probably doesn’t want to force all its constituents to download a specific company’s app, 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.

There are two kinds of standards that we are keenly interested in implementing to enable interoperability and avoid vendor lock-in: data model standards and protocol standards.

The two kinds of standards

Data model standards

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: “John Smith”, email: “[email protected]”, dob: “01/01/91”}

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

{e-mail: "[email protected]", date_of_birth: "01/01/1991", f_name: "John", zodiac: "aries"}

If you needed to share user databases with other people in an industry, you’d 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 data model standards that we use, both developed at the W3C:

  • Decentralized IdentifiersDecentralized Identifiers - A kind of identifier that is controlled by its subject (or assigns) and doesn't depend on a centralized registry, identity provider, or certificate authority. Each organization created in the Trinsic platform has a public DID written to the network it's setup on. Connections leverage pairwise, private DIDs to facilitate message exchange. Learn more at the Decentralized Identifiers W3C Spec Abstract. (DIDs): DIDs are the identifiers used in SSI. They don’t store any data. Think of them as a username, or a phone number, or 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 CredentialsVerifiable Credentials - A credential is a set of attributes about someone or something. Typically, credentials are digital versions of physical licenses, cards, documents, or certificates, but they can represent all kinds of abstract data. They are based on the W3C VC Data Model. (VCs): This is data that an IssuerIssuer - An issuer is an agent that is set up for credential issuance. Every organization created in the Trinsic platform is an issuer by default. 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. VCs answer the question “says who?”.

Protocol standards

Once we’re using the same data model, we must figure out how to communicate. Theoretically, anyone could export their VCs out of their wallet, download them onto a thumb drive, and upload them into someone else's wallet (if it supports the VC data model) for verification. But clearly, using common protocols is better than that.

DID Communications (DIDComms)

DIDComm is an important standard protocol that lets a DID have secure communications with another DID. DIDComm started in Aries and recently moved to DIF.

Aries RFCs

The Aries .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.

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. For example, consider 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 accept the credential
  3. School sends a issue credential to the student, which includes the credential

Note that people can decide which of these standards to follow and which to ignore. Trinsic and others don’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 should follow the RFC to do so so that it’s interoperable with other implementations.

Did this page help you?