In Decentralized Governance in Sovrin, I described how the Sovrin Network is governed. The centerpiece of that discussion is the Sovrin Trust Framework. The trust framework serves as the constitution for Sovrin, laying out the principles upon which Sovrin is governed and the specific requirements for various players in the Sovrin Ecosystem.

In A Universal Trust Framework, I say “a trust framework provides the structure necessary to leap between the known and unknown.” The idea is that online we often lack the necessary context to reduce the risk around the decisions we make. A trust framework defines that context using agreement, process, and technology so that people can make decisions with significantly less risk.

In this post, I want to talk about how organizations can use the Sovrin Network as a trustworthy infrastructure for creating businesses or processes that require strangers to trust one another. This happens by building domain-specific trust frameworks on top of Sovrin.

Exchanging Claims and Proofs

Let’s begin by reviewing Sovrin-based credentials and how they are used.

Issuers issue and identity owners accept Sovrin credentials that are based on emerging Verifiable Claims standards. Identity owners store these credentials in their digital wallet. A credential consists of a set of claims. Identity owners present proofs based on those credentials to verifiers. Proofs can be about any assertions in the credentials the identity owner holds.

The preceding figure shows how this might work in a specific use case. Suppose your employer is using Sovrin. They issue a Sovrin credential that includes claims about your employment status and current salary. The credential includes a reference to a credential definition (on the Sovrin ledger) that contains your employer’s public decentralized identifier, or DID, (also on the Sovrin ledger) and a reference to a schema (also on the Sovrin ledger) that describes the claims in the credential. The credential is signed by your employer, using their public DID. You store that credential in your Sovrin wallet.

Later, you apply to your bank for a loan. Before the bank processes the loan, you need to prove to them that you’re employed and that you make at least $75,000 per year. Using your Sovrin wallet¹, you are able to prove what the bank needs to know without revealing your actual salary or any other claims that might be in the credential your employer provided. The proof process also ensures, through countersigning, that the bank sees these proofs based on their DID for you even though the credential was issued to you by your employer based on the DID they have for you.²

Of course, your wallet also holds other credentials from other issuers. For example, you might have a credential from your bank that you can use to prove your account information to your employer or any other party.

The beauty of this approach is that verifiers never need to contact issuers to verify the assertions or understand how they’re formatted. Anything they need to use to verify the credential is on the ledger. This results in immense benefits for scalability and reliability³.

What Sovrin Promises

The preceding example credential exchange shows how the credential-supported proof provides trustworthy attributes to the bank. But it’s worth teasing that apart and determining why the attributes can be trusted. Let’s start with what Sovrin is promising with respect to the credential that is being issued and the proof that is based on it.

Sovrin’s promise is based on the Sovrin Trust Framework. As I pointed out in Decentralized Governance in Sovrin, the framework governs the operation of the network and the code that it runs on.

Sovrin promises the following:

• The DIDs can be resolved using the Sovrin ledger and the resulting DID document that can contain a public key and an endpoint associated with that DID.
• The schema can be retrieved from the Sovrin ledger and hasn’t been tampered with.
• The definition for the credential can can retrieved from the ledger and hasn’t been tampered with.
• The credential can be validated as not having been tampered with.
• The credential was given to the identity owner with whom the employer has a relationship.
• The proof is about the identity owner with whom the bank has a relationship.
• The identity owner who presents the proof is the same person to whom the credential was issued⁴.
• The credential has not been revoked by the issuer.

The Sovrin Trust Framework is a general-purpose or universal trust framework that is meant to provide a set of universal features that form the foundation for trust transactions. The preceding list of Sovrin promises are all part of that trust framework. They are shored up by legal documents, business processes, and technology.

What Sovrin Does Not Promise

The promises made by Sovrin are important and foundational. But what the bank really wants to know is “are you employed?” That requires promises that Sovrin can’t make:

• The identity owner is a real person.
• The employer is a real business.
• The bank is a real bank.
• The identity owner is employed by the employer.
• The salary figure comes from the employer.

If Sovrin doesn’t keep its promises, then the bank can’t trust anything. But even if Sovrin runs perfectly, the bank is still short of the assurances it needs to make decisions. That’s where domain-specific trust frameworks come in.

Domain-Specific Trust Frameworks

A domain-specific trust framework works on top of the Sovrin trust framework and contains the technology, business processes, and legal agreements necessary to trust the content of the claim. For example, in the scenario above, a domain-specific trust framework would enable the bank to trust the proof that you’re employed.

Let’s walk through each of the promises Sovrin can’t make and discuss who can make them and how.

You Are a Real Person

The bank knows you’re a real person because they have a relationship with you, memorialized by the exchange of Sovrin DIDs. As part of their new customer process, they performed a Know Your Customer (KYC) process as mandated by law. They associate the results of that with the DID you gave them to represent you. So when you contact them with that DID, they know the account belongs to a real person.

Your Employer is a Real Business

Knowing the employer is a real business is a little harder. Even if the bank knows the employer by name, how do they know that the credential was issued from that entity. As I pointed out in Sovrin Web of Trust, there are several options:

1. The employer could publish their public DID (the one associated with the claim definition that underlies the employment verification) on their Web site or some other well known place so that it is easy to verify. This method takes you out of the Sovrin system and into the hierarchical public key infrastructure since you’d verify the website using a standard SSL certificate from a traditional certificate authority.
2. They could offer supporting claims that show they are a legitimate business. These claims would come from what are called trust anchors in Sovrin, trusted entities who can prove who they are based on others who vouch for them. For example, the government, acting as a trust anchor, could provide claims to registered businesses. The Government of British Columbia is piloting this right now.
3. The preceding two steps could be used together in a hybrid verification. InfoCert, that largest European cerificate authority, is already a Sovrin Steward and could issue a Sovrin credential to go along with the TLS certificate the issue to the employer. This Sovrin credential would be backed up by the same process they use to verify the business as part of issuing the TLS certificate.

Businesses often have credentials from others that are part of their web of trust—think of all the “Chamber of Commerce” decals you see on the windows of local shops. The employer would have credentials from numerous government agencies, business partners, and trade associations that could all be used to back up the credentials they issue.

The Bank is a Real Bank

The person knows the bank is a real bank for the same reason the bank knows the person is real: the DID exchange. One of the important and often overlooked benefits of a DID exchange is that both sides can authenticate the other. Mutually authenticated connections are the default in Sovrin and one of its most powerful features. This is in contrast to TLS, which has been a one-sided affair in practice.

In our example, the bank is verifying the credential, so it obviously knows that it’s a real bank, but the identity owner want to know it's real when they open an account. If they did it physically, then they know of themselves, but if they enrolled online, they might have questions. The bank could be validated in the same way as the employer. For example, in the US, financial institutions are certified by different government institutions depending on whether they’re national banks, state-chartered banks, or credit unions. In any case, these certifying agencies could issue credentials to the institution that could be checked by the customer (using their wallet) as part of the enrollment process or at any other time.

You are Employed by the Employer and Have a Certain Salary

The credential itself is making the claim that you are employed by the employer and that the salary is a certain amount. Sovrin links all this up, but the bank would need to validate the claim schema and definition and understand what it means. This validation process would be internal to the bank.

In Sovrin, the schema is a document that is written to the ledger. Think of it as the description of what fields the schema contains and what the fields mean. The schema is readable and understandable by anyone—they are public documents.

Schemas can be reused. Ideally the schema is not specific to the employer, but is used by many employers for employment verification. An industry trade group or a large vendor of ERP systems might, for example, author the schema with inputs from many parties. Doing so would ensure that a wide range of organizations understand and recognize it. The schema becomes a standard, de facto or de jure, for employment verification.

I believe that there will be a relatively rapid agreement on schemas, reinforced by trust frameworks, in many fields. But this does not preclude anyone from creating any schema they want whenever they want for their own purposes.

Claim schema are automatically versioned. When a new schema is created, the original schema doesn't go away, so credentials issued with the old schema can still be used. Credentials issued with the new schema refer to that new schema and not the old one.

The claim definition references a claim schema and is written to the ledger by a specific entity. In our example, the employer writes a claim definition that references the schema and includes its public DID.

Depending on the use case, an industry group might do more than merely publish the schema. They might also create standards around how the schema is to be used. These standards would be enforced by legal contract and required business processes with compliance attested to by claims from the standards group to any organization creating claim definitions that use the schema. That way claim inspectors could know that the claim was created in accordance with an accepted process, increasing trust in the claim. How would they know? By means of a Sovrin credential from the standards group, of course.

Sovrin’s Role in Domain Specific Trust Frameworks

A domain-specific trust framework is a collection of policies, legal agreements and technologies that provides the context for claims in a given domain. Sovrin Foundation provides a structure and supporting systems for groups defining trust frameworks.

Sovrin works as a globally decentralized dictionary for schema definitions, with no central authority dictating what schemas, definitions, and claims can or can't be issued. This makes it uniquely flexible. Anyone can issue credentials about anything, enabling the "long tail" of use cases to be easily addressed.

Sovrin Foundation provides the basis for the Sovrin web of trust. As discussed in the Sovrin Trust Framework, Sovrin Trustees provide the foundation for this web of trust. They select Stewards who validate transactions on the Sovrin ledger⁵. Stewards can vouch for others. Anyone using the Sovrin network is part of this general web of trust.

Beyond this general web of trust, domain-specific trust frameworks can determine their own web of trust. This already happens in the physical world. For example, colleges and universities in the US are accredited by independent organizations. Brigham Young University, where I work, is accredited by the Northwest Commission on Colleges and Universities. They already have a process for accrediting member organizations. They could simply rely on that process and any attendant legal agreements to issue and revoke Sovrin credentials that reflect their determinations concerning the accredidation status of member institutions.

Other uses of Sovrin may not have a physical world counterpart. For example, suppose you wanted to start a decentralized version of AirBnB. One of the roles that AirBnB plays is identifying and attesting to certain attributes for renters and hosts. A decentralized AirBnB may want to establish a process for vetting renters and hosts and issue and revoke claims in accordance with that process. This decentralized AirBnB might define and include claim insurance for both renters and hosts in the event the process breaks down. The processes that define how vetting works, the legal agreements that hold parties to the processes, and the provisions for recourse and restitution via insurance are all part of the domain-specific trust framework for this ecosystem.

For anyone wishing to build domain-specific trust frameworks for an existing or planned business, Sovrin Foundation can help with technical advice about schema and claim definitions as well advice on how to go about creating and governing the legal agreements and business processes necessary to create environments where trust abounds.

---

Endnotes

1. A wallet in Sovrin is an agent that holds credentials on behalf of the identity owner and speaks the Sovrin agent-to-agent protocol.

2. Your employer and bank have a different DID for you to prevent correlation.

3. Specifically, issuers do not need to maintain always-on infrastructure to answer questions about credential validity and credential transactions are done peer-to-peer.

4. Technically it could also be presented by the identity owner's guardian if the identity owner is in a guardian relationship. But the Trust Framework considers that to be the same as the identity owner presenting it themself

5. When Stewards "validate" a transaction, they are merely achieving consensus with other Stewards about the validity of the transaction, not it's content. Stewards aren't making judgments about the assertions inside of any transaction on Sovrin.

Photo Credit: Framework from kaz z (CC BY 2.0)