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. If our competitors sell into the State of California to issue driver’s licenses, any of our partners can accept those licenses. What’s good for one competitor is good for the others.

Avoid 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 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.

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 standards that we use, 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, 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 credentials (VCs): 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. 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 .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.