Blepcoin

Home RSS

Sovrin
Decentralized Digital Identity and Verifiable Claims

https://sovrin.org/
lead image

Sovrin is a decentralized, global public utility for self-sovereign identity and verifiable claims. In other words, Sovrin is a protocol for sharing and verifying identities, and associating them with additional credentials such as education status, passport data, and driver license data. Due to the sensitive nature of this data, Sovrin utilizes cryptography to make the data private yet verifiable.

The Sovrin blockchain is permissioned, and public.

Link to whitepaper

Full disclosure: I’m working on an early stage physical identification technology that securely associates physical and virtual/blockchain identities. Although we’re both dealing with identities, these two projects work in very different parts of the identity stack (secure hardware vs trustless verifiers).

Token metrics

Market opportunity/Competitive analysis

So many use cases rely on identity and verifiable claims, in and out of the crypto space. We, as humans, have identities. Companies have identities. Machines have identities. Our possessions have identities. I mean… if you can identify it, it has an identity.

To make things more complex, individual identities can have multiple credentials. For example, you probably have a national credential (passport), a fingerprint, and an Ethereum wallet address.

Currently, in order to connect these three, you have to use a trusted third party to verify that these credentials are valid, every time someone different needs to know your identity. That’s a ton of risk exposure, which increases linearly over identity usage.

Sovrin removes the need for a trusted third party by being able to directly validate those credentials, therefore increasing efficiency and decreasing risk. Nobody has full control of all your credentials, and it enables anyone to issue credentials (only useful if the issuer builds trust with others).

A few examples:

  • Standardize KYC/AML (crypto exchanges, OTC, ICOs)
  • Single login (dapps)
  • Electronic signature verification

Team/Advisors/Partnerships

Relation between Sovrin, Evernym, the Linux Foundation, and W3C

Evernym was started in 2013. The Evernym team developed the source code for Sovrin, which was then donated to the Sovrin Foundation. Sovrin Foundation then contributed the code to the Linux Foundation, where it is now fully open source and known as Hyperledger Indy.

The Sovrin Foundation is a non-profit governed by trustees, with the vision of becoming a global public utility.

Evernym’s business is helping organizations and people leverage Sovrin’s capabilities. They do this by building software that works on the Sovrin Network and consulting with organizations about using Sovrin. (source).

Sovrin is entirely based on open standards. Evernym is just one of at least a half-dozen companies, including Blockstack, uPort, Gem, Microsoft, and Digital Bazaar, contributing to the DID specification 9 at the W3C Credentials Community Group 6. And Evernym is only one of at least 40 companies contributing to the W3C Verifiable Claims Working Group 8.

- Drummond Reed (source)


Sovrin Foundation Team

  • Executive team:
    • Roy Avondet (CFO)
      • Partner at NextStep Partners, a C-suite leadership consulting firm (7 years)
      • CFO Global Upside Corporation, (7 years)
      • experienced with Professional Employer Organization services
      • CFO at several small companies through NextStep Partners
    • Heather Dahl (CEO)
      • Cofounder of CynjaTech, a data security firm (3 years)
      • Chairman Emeritus / Board of Directors at National Press Foundation (9 years)
      • Founder of Kometa, an analyst relations and marketing strategy consulting firm (4 years)
      • Director of Global Analyst Relations at Neustar (blockchain and data security leadership experience) (4.5 years)
    • Nathan George (CTO)
      • Software Architect at Evernym 2016-18
      • Senior Engineer at Perfect Search and Symantec

13 people on the Board of Trustees, consisting of representatives of people and organizations who own identities on the Sovrin network.

15 people on the Technical Governance Board (TGB). The TGB reviews technical qualifications of Steward Candidates and is “responsible for governing the design, architecture, implementation, and operation of the Sovrin identity network as a global public utility for self-sovereign identity.”


Evernym Team

49 other team members listed on the website.


Sovrin Stewards

Stewards are “trusted organizations within the ecosystem who have agreed to abide by the requirements in the Sovrin Trust Framework and are responsible for operation the nodes that maintain the Sovrin distributed ledger.” They also accept/reject changes to the ledger codebase.

The stewards consist of companies from all over the world (all continents except Antarctica and Australia) and many industries (financial service, university, blockchain, consulting, legal, tech, certifying authority, credit union, cybersecurity, payments, data, KYC, identity)

Competitive Advantage

Identity platforms are sensitive to network effects, due to requiring buy-in from three sides: users, verifiers (eg. companies evaluating or trusting the claim), and issuers (eg. government entity issuing credentials).

Sovrin has solved the chicken and egg problem by forming the most partnerships I have seen for a crypto project in this fundraising stage. These partners will not only act as verifiers and issuers, thus seeding demand within the tokenomics, but also maintain the functionality of the network by participating in ledger governance and node hosting. These partners are called “stewards,” which includes at least 39 listed organizations, such as Cisco (potential verifier), IBM (potential verifier), Veridium (potential issuer), and InfoCert (potential issuer) (full list here).

Tokenomics and Token Utility

image-20181108005723929

When a verifier accepts a credential from a credential presenter/owner, both the verifier and the presenter receive real value from the issuer of the credential.

In the current world, every verifier has to set up a payment account with every issuer. For example, a potential tenant or a landlord would have to pay a credit agency to get a credit report. Separately, they would have to pay a background check service to get a background check. While this makes sense for higher risk (eg. being stuck with a bad tenant in a contract) situations, lower value situations (social media verifications, LinkedIn endorsements) are often overlooked.

High risk/high value credentials in a high friction market means large, centralized, credential issuers, who also happen to store a lot of personal data – a huge target for hackers. A low friction market would increase low risk/low value credential utility, and also encourage credential verification to become commoditized.


image-20181108011314313

Using zero-knowledge proofs in the payment protocol, Sovrin keeps payment metadata private where it needs to be. Issuers don’t know who is using a credential nor where it’s being used.


image-20181108012247214

“Digital credentials paid for with the Sovrin token could also be insured with the Sovrin token.” Insurers have the capability to do risk assessment on issuers, reflected in their pricing and possibly become a repuation signal that verifiers can rely on.


image-20181108012702549

Since credential owners control the data, Sovrin opens up the possibility of a marketplace for customer data controlled by the subject of the data.

Code/Tech/Community

This section is usually titled “Code” only, but there’s something to be said about how developer friendly this project is. Take a look at the Developer’s Getting Started Guide with LibIndy. I’ve only seen this level of documentation from large scale open source projects. In addition, Sovrin hosts a group video call every Thursday at 3pm UTC.

Sovrin also has a ton of documentation to help newcomers understand the architecture of the system. Here’s a clear spec with well defined flows for all users, which demonstrates the level of detail with which this project is designed: DKMS (Decentralized Key Management System) Design and Architecture V3.

The high level design is well thought through and explained in a straightforward manner in the whitepaper. The spec includes pairwise-pseudonymous identifiers, off-chain private data storage, and zero knowledge proofs, which solves some long-term problems that some other identity projects do not consider.


Repositories

Distributed Ledger:

  • indy-node: indy-plenum based implementation of distributed ledger
  • indy-plenum: Identity system specific distributed ledger technology based on RBFT

Client Tools:

  • indy-sdk: Contains client and anoncreds implementation
  • indy-agent: Reference agents and associated tools.

Shared Components:

With such a complex and long-running project, it’s very difficult to dig into each individual file in each individual repository to get a mental model of how everything fits together as I typically do for other projects. It also comes with diminishing returns, since we can already grasp how strong the tech is based on the thoughtfulness of the design documentation. A quick scan through all the repositories show that there is a ton of progress, everywhere, with the biggest code contributions from active team members.


Technical roadmap

image-20181108014816138

Conclusion

Universal digital identity and verifiable claims enables innovation that offers more automation, efficiency, and privacy.

Sovrin is a strong contender, by bringing not only an experienced team, but also countless value-add partnerships, a very well thought through technical design, and very significant technical progress. For the longer term, they are also doing everything right when it comes to developer community development; it’s clear the team knows that adoption is everything when it comes to making new standards.

The tokenomics make sense to me.

I have some concerns about the delay of the token launch, which was meant to be in July 2018, now slated for Q1 2019. This may be due to fundraising taking longer than expected as a result of difficult market conditions.

Other Info

  • The “technical paper” is not released yet, but there is a lot of technical documentation and code that is self-documented.