The Sovrin Foundation (“Sovrin”) Board of Trustees and Trust over IP Foundation (“ToIP”) Steering Committee are pleased to announce that they have signed a Letter Agreement (dated March 18, 2021). This agreement signifies the commitment of both organizations to mutual cooperation and recognition for each other’s mandates. Sovrin and ToIP intend to work together toward advancing the infrastructure and governance required for digital trust and digital identity ecosystems.

“By signing this Letter Agreement, Sovrin and ToIP are excited to take a step further to support the need and importance of our separate but interrelated mandates to benefit people and organizations across all social and economic sectors through secure digital identity ecosystems based on verifiable credentials and SSI,” said Chris Raczkowski, Chairman of Board of Trustees, Sovrin Foundation.

Under the agreement, each organization will assign one member to act as a liaison to coordinate and maintain lines of communication, attend plenary sessions, and provide periodic updates to the Sovrin Board of Trustees and ToIP Steering Committee. They will also seek opportunities proactively to exchange information, participate in discussions of shared interest, promote the value of each other’s work through joint announcements and media products, as well as collaborate to achieve their respective mandates.

Sovrin and ToIP both operate in a manner that respects open licensing, open source code and open standards. The organizations agree that their open, public materials will be available for reference (with attribution) by the other.

“ToIP and Sovrin each offer something unique to the market. Our members already collaborate together informally on many topics. Signing this agreement makes our work together more visible and open. It will create new opportunities to collaborate on challenges that affect every layer of our trust model,” said John Jordon, Executive Director of Trust over IP Foundation. “By working together, we want to help solve interoperability problems more quickly and support the adoption of digital trust ecosystems more widely.”

If you have any questions or suggestions, please contact info@sovrin.org or operations@trustoverip.org .

About Sovrin Foundation

The Sovrin Foundation is a non-profit social enterprise which acts as the administrator and governance authority for public available SSI infrastructure, as well as supporting interoperability digital identity ecosystems that adhere to the Principles of SSI. Sovrin’s activities aim to serve the common good of providing secure, privacy-respecting digital identity for all, including individuals, organizations and things.

About Trust over IP Foundation

Launched in 2020, the Trust over IP Foundation is an independent project hosted by the Linux Foundation. Its members include over 200 leading companies, organizations and individual contributors sharing expertise and collaborating to define standard specifications to advance a secure trust layer for the digital world. Through this collaborative effort, the Trust over IP Foundation aims to define a complete architecture for Internet-scale digital trust that combines cryptographic trust at the machine layer with human trust at the business, legal, and social layers. For more information, please visit us at trustoverip.org.

Originally published at https://sovrin.org on May 5, 2021.

Sovrin and Trust over IP Signed Mutual Agreement to Strengthen Their SSI Collaboration was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

In December 2019 the Sovrin Guardianship Task Force released a whitepaper titled “On Guardianship in Self-Sovereign Identity.” This groundbreaking paper explored guardianship in the context of SSI, and provided two use cases: one for a refugee, Mya, and one for an elderly living with dementia, Jamie. (Watch the video illustration of these two use cases at the end of this article.)

Recognising the need to develop the work beyond the whitepaper, the Sovrin Foundation chartered a Sovrin Guardianship Working Group (SGWG) in December 2019. Two key documents were identified as outputs for the working group: a Technical Requirements for Guardianship and Implementation Guidelines. After more than a year of hard work, the two papers were completed and will be publicly presented and released at the Sovrin’s breakout session at the Internet Identity Workshop (IIW) #32 during April 20–22, 2021.

“When we started the work on defining technical requirements for guardianship in early 2020, we viewed the task as relatively simple. ‘All’ we had to do was extract the guardianship requirements from the use cases in the previous whitepaper… It turned out that this view was optimistic,” said John Phillips, one of the authors and Chairs of SGWG in Asia Pacific. “We found that the gap between the two use cases in the whitepaper and technical requirements was too broad. So we realised we needed to revisit our thinking. We needed a conceptual bridge, a ‘mental model’ to understand Guardianship broadly so we could write appropriately narrow technical requirements. The lesson we have (re)learnt in our journey is that, before you can describe something in simple terms, you need to make sure you have a broad and deep enough understanding of the topic.”

The first paper is called the Guardianship Credentials Implementation Guidelines and its purpose is to provide readers with the background they need to implement IT systems that support various kinds of guardianship. In particular, it focuses on what they need to know when using Verifiable Credentials and Decentralised Identifiers, the building blocks of a SSI framework within the frameworks of Sovrin Governance and Trust Over IP (ToIP).

This paper is intended for all people interested in the design, build and operation of a Guardianship implementation using an SSI framework. It outlines the conceptual framework for Guardianship and provides implementation guidelines. The document introduces and uses a mental model to help understand the interplay and relationships of the key entities and actors involved in the establishment, running and ending of a Guardianship Arrangement.

While this document provides background explanations of the thinking that led to the technical requirements guidelines, it does not mandate or warrant specific rules for the implementation of Guardianship as these should be Jurisdiction specific, which is defined by the mental model in the document.

The second paper is called Guardianship Credentials Technical Requirements which was developed by the technical requirements working group within the SGWG. The purpose of this document is twofold: i) provide principles under which guardianship scenario designs and requirements are considered and defined; and ii) provide technical requirements for SSI solutions that offer the capability of guardianship.

The intended audience for this document includes: i) individuals looking to understand how guardianship should be implemented for their use case; ii) SSI solution designers that require guardianship to support the use of VCs in their specific use case; iii) readers who want to understand how Guardianship can work in an SSI context.

The requirements described in this paper, together with other SSI standardization, describe when an SSI solution offers the capability of guardianship. In this case, the requirements are mainly for the technical building blocks that live in the bottom three layers of the Technical “Stack” of the Sovrin/ToIP framework. The mental model, however, is also relevant for the top layer (ecosystem), as guardianship is intricately linked to what we will be defining as Jurisdictions, and this enables human governance to be applied to the first three layers.

This document should be read in conjunction with the Sovrin Guardianship Credentials Implementation Guidelines mentioned above. In particular, readers who are looking to understand the thinking behind these requirements are encouraged to refer to the Implementation Guidelines.

These two papers are the first public release of implementation guidelines and technical requirements for guardianship in the context of SSI. There are sections at the end of the documents that propose areas of future work, and it is expected that these two documents will be updated as technology evolves and open discussion and decision areas are resolved.

Download the two papers here.

Sovrin Guardianship Use Case #1— Mya (a refugee girl)

Sovrin Guardianship Use Case #2 — Jamie (an elderly living with dementia)

Video credit: John Phillips

Originally published at https://sovrin.org on April 22, 2021.

This all-volunteer Sovrin Guardianship Working Group is open to anyone with a genuine interest in and willingness to contribute to digital guardianship. For more information, please see its webpage for details.

A Deeper Understanding of Implementing Guardianship was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

April 7, 2021

On December 23, 2020, the Financial Crimes Enforcement Network (FinCEN) of the US Treasury Department published a Notice of Proposed Rulemaking (NPRM) regarding “Requirements for banks and money services businesses” related to certain transactions involving convertible virtual currency (CVC) or digital assets with legal tender status (“legal tender digital assets” or LTDA). FinCEN is identifying additional statutory authority for the proposed rule under the Anti-Money Laundering Act of 2020, providing additional information regarding the reporting form, and reopening the comment period for the proposal.

The Sovrin Compliance and Inclusive Finance Working Group (CIFWG) took the opportunity to submit its formal response to FinCEN on March 29, 2021 — focusing explicitly on how their proposed rules will impact financial inclusion.

Sovrin Foundation asked Amit Sharma, Chair of the Sovrin CIFWG, to tell us more about the potential impact of the NPRM, their response and recommendations to FinCEN.

Q: Can you tell us a little bit about the Sovrin CIFWG? What’s your mission and who are your group members?

The purpose of the Sovrin CIFWG is to advance the mission of financial inclusion globally, by addressing the challenges and opportunities presented by innovations in the financial services and payments landscape, and the attendant financial and regulatory compliance implications. We are an open group of traditional bank and non-bank financial institutions, regulators, policymakers, technologists, ethicists, and legal experts who monitor the challenges faced by the financially excluded and under-served. CIFWG focuses on how economic and regulatory technologies can bridge the gap between traditional banking compliance and associated risks injected by innovation. We have developed and been actively promoting the Sovrin Compliance and Inclusive Finance Rulebook, an innovative best practices framework that extends traditional banking compliance and payments guidance to emerging fintech and virtual asset service providers (VASP) processes.

Q: What do you mean by global financial inclusion, and why is it important?

Global financial inclusion remains a desirable and necessary development goal — 1.7 billion adults lack a bank account[1], and millions more have limited or no access to traditional financial services around the world. Furthermore, “de-risking” — the efforts of financial institutions to terminate or restrict relationships of certain clients and customers — has continued to be amplified by the continued growth of global anti-money laundry (AML) / counter-terrorism financing (CTF) controls[2]. The result is a disproportionate impact for the financially under-served, the global poor, and institutions and sectors that provide services to these segments of the economy. The attendant consequences of financial exclusion cannot be overstated given that remittances from migrant workers alone total over $500 billion a year (three to four times foreign aid) and is a vital source of finance for poor countries.

Q: What is the NPRM regarding “Requirements for banks and money services businesses” proposed by FinCEN about?

The December NPRM proposed to address the threat of illicit finance with respect to certain transactions involving CVC or LTDA by (a) establishing new reporting requirements for certain CVC or LTDA transactions analogous to existing currency transaction reports, and (b) establishing new record keeping requirements for certain CVC or LTDA transactions that is similar to the record keeping and travel rule regulations pertaining to funds transfers and transmittal of funds.

On January 1, 2021, the Anti-Money Laundering Act of 2020 (Division F of Pub. L. 116–283) (“AML Act of 2020”) became law. FinCEN proposed that by regulation, CVC and LTDA are monetary instruments because they are “similar material” to “coins and currency of a foreign country, travelers checks, bearer negotiable instruments, bearer investment securities, bearer securities, [and] stock on which title is passed on delivery[3].”

Q: What do you think about the NPRM? How does it impact the fintech sector and its key stakeholders?

We believe combating illicit finance activities is necessary and a top priority for FinCEN. But efforts to serve both law enforcement equities and financial inclusion do not present a binary choice. An effective anti-money laundering and counter-terrorism financing regime should also prioritize increased engagement of financially underserved, de-risked and/or excluded parties to foster a financial system that provides enhanced participation, greater transparency, and innovation in domestic financial systems.

Further, the data on illicit finance risks in the CVC sector don’t necessarily support the need for the proposed rule changes which are motivated to strengthen law enforcement and regulatory oversight efforts. According to a recently released report by Chainalysis, illicit activities or crime related to virtual assets has continued to decline, with the illicit share of cryptocurrency activity falling to just 0.34% in 2020.

Importantly within the data analyzed by Chainalysis, the concentration of illicit activities has shown to be primarily with a “small group of shady cryptocurrency services, mostly operating on top of large exchanges, [who] conduct most of the money laundering that cybercriminals rely on to make cryptocurrency-based crime profitable[4].” This data would seem to call for more targeted efforts by law enforcement to concentrate investigations of criminals by identifying owners of these deposit addresses and the organizations that are conducting deliberate money laundering operations at scale (among otherwise legitimate activities).

As such, we are concerned with the proposed rules as they impact a growing sector that is increasingly providing solutions to marginalized and financially excluded constituencies. Also, organizations operating in CVCs, including fintech companies, virtual asset services providers (VASPs), and other similar organizations may fall under the broader definition of nonbank financial institutions or money services businesses/money transfer operators (MSBs/MTOs) that already face enormous scrutiny by mainstream financial institutions when evaluating their respective risks related to onboarding into new accounts. The Financial Action Task Force (FATF) itself has acknowledged the fact of de-risking disproportionately impacting certain sectors like MSBs/MTOs[5].

Q: What is the role of the CVC services in regards to global financial inclusion, and how secure are they?

As CVC services continue to evolve and grow, so do the applications and opportunities inherent in facilitating greater inclusion of underserved and marginalized communities and organizations into the global financial ecosystems. As such, self-hosted wallets are playing an increasingly important role with virtual assets, as global financial operations continue to be unbundled, and an ongoing trend toward de-centralized financial services continues unabated[6].

Self-hosted wallets enable anyone with an internet connection to transact with others in digital assets on a peer-to-peer (P2P) basis. Additionally, these wallets can be used to store value or digital assets securely and provide capability for the user/consumer to hold resources personally that enable them to interact in the fiat and digital financial context. This enables consumers to transact with counterparties directly without the need for a third-party intermediary–similar to making a cash transaction for a purchase of a good, pay an expense, or transfer value to a friend or family member.

When combined with blockchain technology, P2P transactions are arguably more secure and more transparent than activities undertaken in cash, as the convenience of cash and the efficiencies that come with electronic payments are combined with the risk controls associated with pseudonymous transactions that are not otherwise dependent on a specific financial intermediary[7].

Q: In sum, what are your recommendations to FinCEN regarding the NPRM?

We really appreciated the opportunity to comment on the NPRM. We believe that any proposed rule should explicitly include a thorough assessment of the threats to financial inclusion that may come about with such a proposal, and the Agencies should consider the concerns outlined in the response in our letter as part of such an assessment.

Secondly, increased targeted enforcement and requirements for transaction monitoring would strengthen law enforcement regulatory intentions with the proposed rules vs a more wholesale application of record keeping and reporting for related to all noncustodial wallet holders and their activities. In short, a smaller group of actors are engaged in such activity, and enforcement and regulatory measures should be better targeted to them vs the industry as a whole — especially in light of the financial exclusion implications of such proposed rules.

Strengthening financial inclusion, including by encouraging innovation in the financial services arena with technology applications that extend beyond existing banking and payments systems can actually provide enhanced security, risk and compliance controls, while bringing greater opportunities to marginalized and otherwise financially underserved or excluded communities. The underlying technologies include:

1. The facilitation of cross-border remittances via P2P and blockchain networks that provide efficiency, cost advantages and security;
2. The enhanced auditability and traceability of transactions conducted via these applications that better enable financial services regulators and law enforcement interests; and
3. The application of digital and sovereign identity management capabilities that strengthen know-your-customers processes and customer information programs while preserving the essential privacy protections inherent in financial services.

We welcome follow up with Agencies and participating members that are interested in providing guidance, examples and use cases of inclusion efforts — including the application of self-hosted/un-hosted wallets in particular.

Thank you Amit!

Anyone can download the full letter here. Please feel free to reach out to Amit Sharma (Amit@finclusive.com) and the Sovrin Foundation (info@sovrin.org) if you have any questions or suggestions regarding the NPRM.

For more details about the Sovrin Compliance and Inclusive Finance Working Group and instructions on how to join, please see its webpage or contact cifwg@sovrin.org.

Reference materials:

[1] Global Findex Database: https://bit.ly/2OlEybX

[2] De-risking in the Financial Sector: https://bit.ly/2Q0g3kX

[3] Requirements for Certain Transactions Involving Convertible Virtual Currency or Digital Assets: https://bit.ly/3ugrOme

[4] The 2021 Crypto Crime Report: https://bit.ly/31MOQ8k

[5] FATF (2016). Correspondent Banking Services. Paris: Financial Action Task Force: https://bit.ly/3mlMcQf (accessed July 11, 2019).

[6] World Bank staff estimates based on data from IMF Balance of Payments Statistics database. For UAE, estimates are based on reports from its Central Bank.

[7] Are regulators poised to demand cryptocurrency address whitelisting? Probably not: https://bit.ly/3mlMcQf

An open letter to Financial Crimes Enforcement Network advocating for financial inclusion in its… was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

By Sam Curren, Sovrin Agent Architect

One of the clear highlights of Consensus 2019 for the decentralized identity community was when Brian Behlendorf took the stage and announced Hyperledger Aries , the newest project to be accepted into Hyperledger under the Linux Foundation. Sovrin Foundation led the charge for Aries to be added to Hyperledger.

Aries is meant to foster identity interoperability with any ledger using any wallet. Aries is a shared infrastructure of tools that enables the exchange of blockchain-based data, supports peer-to-peer messaging in various scenarios, and facilitates interoperable interaction between different blockchains and distributed ledger technologies (DLTs). Simply put, developers can pick up the tools and libraries in Aries and make their own digital identity wallets and configure them to operate on any networks they please. This is a major milestone for the Sovrin Foundation and our mission of Identity for All. This means interoperable, open source digital identity for multiple uses on multiple networks.

Drummond Reed on Twitter

At #Consensus2019 #Construct, @Hyperledger ED @brianbehlendorf announces #HyperledgerAries joins #HyperledgerUrsa as the newest HL project. Aries will standardize crypto wallets and off-ledger interactions such as secure messaging & credential exchange for #selfsovereignidentity

Although much of the media coverage of this exciting announcement was , some press outlets attempted to turn the story into a competition between Aries and Microsoft’s recently announced Ion , announced the same day. In doing so, these authors revealed how little they understood about the Aries project (or Ion). Aries provides secure communication and interactions independent of but anchored to any number of DID method providers, including Microsoft’s Ion.

These news outlets also mistakenly identified the launch as something done by IBM. IBM is one of Sovrin’s Founding Stewards and also part of the Hyperledger Indy community. Among several projects supporting verifiable credential exchange they were recently seen at Consensus giving technical previews of a new project that aims to help bootstrap developers looking to develop their own products. But this misrepresentation of IBM as somehow taking the lead in the development of Aries reveals a fundamental misunderstanding that anything related to Hyperledger is the work of a single organization, rather than the work of the vibrant and diverse community that ultimately drives project development.

If anything, one would only need to attend a single Hyperledger Aries, Indy or Ursa weekly community call to see the primary sponsor of both Hyperledger Aries and Hyperledger Indy (the project where Aries was incubated) is in fact the Sovrin Foundation. Our small non-profit is dedicated to a mission of creating a global public utility for Identity on the Internet. The number of companies and organizations that have contributed significant effort to the Aries, Indy and Ursa projects further clarifies their existence as a community project, not one that can be attributed to any single company.

When the Sovrin Foundation first contributed the code for Indy to Hyperledger, it was the first identity focused project within the organization. Hyperledger already contained Sawtooth, Iroha, and Fabric (contributed originally by IBM) as ledger projects. None of these existing projects support Identity at the core, and the Hyperledger community has been very welcoming of the identity strengths of the Indy ledger project and concepts.

One of the architectural components of Indy is called an Agent. This is software that acts on behalf of an identity owner to communicate off-ledger with other Agents. As Agent work continued with the development of message encryption standards, extensible message typing, and common protocols, interest grew in applying these concepts and practices to systems based on other ledgers. It became clear that the right future for Agent work was to extract it from Indy project and add support for other ledger technologies to make that integration easier and more powerful. That work is now known as Hyperledger Aries.

In addition to being able to support more ledger technologies than just Indy, Aries can work with multiple ledgers at the same time. This allows Agents to use each ledger according to the unique power offered by each, instead of requiring anchoring to only one ledger. In the future, Agents will be able to integrate not only with the recently announced Ion DID method, but also Ethereum, Hyperledger Sawtooth, Bitcoin, Hyperledger Fabric, and others.

Each of these ledgers offer valuable mechanisms for trusted transactions, cryptographic credentials and proofs, smart contracts, payment, and DID methods. Microsoft Ion is itself a DID method that combines IPFS with Bitcoin anchoring. Aries exists on an architectural layer above these layers, enabling powerful forms of communication anchored to these underlying ledger technologies that has the possibility to change the nature of how the Internet as a whole handles Identity.

If the Aries project is interesting to you, we invite you to get involved. There are many ways you can contribute, and many ways that your own projects and efforts can be improved by integrating technology from the Aries project.

If you’re interested in learning more about Aries, Indy, or Ursa, consider visiting https://wiki.hyperledger.org/display/HYP/Hyperledger+Aries+Proposal or #Aries on Hyperledger chat at https://chat.hyperledger.org/channel/aries Hyperledger welcomes interest from all groups and organizations, including enterprises and standards organizations.

Originally published at https://sovrin.org on May 21, 2019.

Sovrin proudly contributes to Hyperledger Aries was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Government of British Columbia uses the Sovrin Network to take strides towards a fully digital economy

The Government of British Columbia recently announced the launch of OrgBook BC. OrgBook BC is a searchable directory of public, verifiable data issued by government authorities about businesses in British Columbia. OrgBook BC is an exemplar service of the Verifiable Organizations Network(VON) which envisions a new way to issue, store, and share authentic and authoritative data about organizations globally. The Sovrin Network provides OrgBook BC with a global reach for its credentials issuance and verification services.

We asked John Jordan, Executive Director of Emerging Digital Initiatives from the Government of British Columbia, to tell us more:

Sovrin: Please tell us a little bit about OrgBook BC and the Verifiable Organizations Network? Where did this idea come from? Why was it created? What problem does it aim to solve?

John: The Government of British Columbia’s move towards a fully digital economy is missing a key piece: a solid digital foundation of trust. We need confidence that the people and businesses we are interacting with are who they say they are.

Relationships are fundamental to how we live, work, and play together in society. The current suite of technologies that power the internet have provided a great deal of opportunity; however, they were never designed to solve the problem of establishing trustworthy peer-to-peer relationships. We believe the open technology behind the Sovrin Network, Hyperledger Indy, provides an opportunity to explore how to use digital networks to establish trust at a distance.

The Verifiable Organizations Network (VON) envisions a globally available suite of services enabling new ways for trusted and enduring digital relationships to form. Governments, organizations, and individuals will benefit from the ability to issue, hold, and verify the authentic and authoritative data needed to create and maintain the trusted digital relationships they need to grow and prosper. The issuance of this data will be based on the emerging W3C Verifiable Credentials standard. VON is an open community effort to establish this better way to find, issue, and store this trustworthy data about organizations.

However, it will take some time to reach this broad vision. Not all of the components we need to realize this vision are yet available. In particular, we don’t yet have the software businesses needed to hold and share these new Verifiable Credentials, and government services don’t have the software to issue and verify them. We need a way to provide near-term value and begin the bootstrapping process to realize this global scale vision.

This is where OrgBook BC comes in. Grounded in the foundational data of the BC Registry, OrgBook BC is a searchable public directory of trustworthy business data. Currently, anyone can search for and find registration information for the more than 525,000 legal entities operating in the Province of British Columbia. OrgBook BC provides a destination for our services for business to issue their permits and licences, all linked to the legal entity they are empowering.

These are the numerous government services who issue specific credentials to organizations. Permits to take water, liquor licences, business licences, building permits are among the many, many examples. We are working to enable these issuers to issue more credentials to OrgBook BC with simple to deploy open source software components and open APIs. The greater the number of issuers, the greater the value of OrgBook BC.

As the vision behind Sovrin and Hyperledger Indy matures, we believe a new software stack will emerge. This software “trust stack” will provide a way for global-scale trusted and enduring digital relationships to be formed. These trustworthy digital relationships will give people, organizations, and institutions a way to discover and build relationships with each other, over the internet, as they have always done in their own local communities. We think that is what is holding up the next economic leap forward.

Sovrin: What specifically does distributed ledger technology (DLT) enable VON to do?

John: This is a really important question. The Sovrin Network, powered by Hyperledger Indy, provides important capabilities. These capabilities provide globally scalable peer-to-peer interactions that are both highly secure and privacy respecting. This is a significant factor in our motivation to work with and understand this technology. If this new design can deliver on these privacy enhancing data exchange capabilities, we believe there is a real opportunity to help our businesses and citizens use the internet for trusted and high value interactions.

Most DLT implementations derive their design from the Bitcoin Blockchain. The design of that first type of blockchain implementation focuses on a kind of “reconciliation model” for currency-based transactions. Therefore, the design necessarily includes writing data to the ledger about the specific transactions that the users of the system undertake in order to create a common understanding of the state of the system. For example, what transactions have occurred and what are the associated balances of accounts implicated in those transactions.

The design of this type of DLT can displace typical trust intermediaries or centralized authorities who perform this reconciliation function on behalf of all the members of a network. Members of these networks typically use software called a “wallet” to gain access to the network and conduct a transaction with another member of the network. The transaction between the two members is conducted via the DLT. Without the DLT in this design, there is no way for the members to interact with each other. Further, as a result of the DLT being a party to all the transactions between members of the network, it is quite possible to discover who the members are even if the nature of their interactions may be private. We didn’t feel this was an appropriate technical approach for our purposes which, we hope, will eventually include empowering our citizens with globally recognized digital credentials which could include personal information.

This is not the design of the Hyperledger Indy DLT.

Hyperledger Indy is designed to support a new trust architecture for the internet. With Indy, the goal is to enable direct and secure peer-to-peer communication. Peers are typically individuals, services, and potentially devices. Peer-to-peer communication is not established via an intermediary nor is it conducted via the DLT.

To accomplish this, Indy can be understood as having two high-level components. The first component is the software which powers the DLT network. The second is typically called agent software which is used by peers wishing to create and manage their digital relationships via a set of sophisticated protocols. These protocols are generally rooted in a class of technology called public key infrastructure.

A unique quality Indy offers is the ability for issuers of Verifiable Credentials to make their public key(s) globally discoverable and available via the DLT. The Sovrin Network leverages this technical capability of Indy’s DLT and augments this with a governance structure. The governance and technology work together to create a trustworthy publicly readable network which contains the cryptographic elements needed for peers to exchange the Verifiable Credentials needed to establish trusted and enduring relationships.

Sovrin: How does VON work with the Sovrin Network?

John: The vision of VON is that any government, private sector, not-for-profit, or other type of organization can benefit from the ability to establish trusted relationships through the use of Verifiable Credentials over the internet. In order to help this vision come to fruition we have created two new software components to complement the existing ones in Hyperledger Indy.

One component is a type of agent that can be easily configured to connect to existing enterprise services. Under the label of Indy Catalyst Agent, this component enables services to quickly become Verifiable Credential issuer and verifier enabled services. Indy Catalyst Agent has everything that an enterprise service needs to interact with the Sovrin Network and with other Indy-based agents.

The second component, being further developed under the label of Indy Catalyst Credential Registry, is what powers OrgBook BC. In fact, OrgBook BC uses both Indy Catalyst Agent (configured as a holder/prover) and Indy Catalyst Credential Registry. This is also a service we think has a broad audience. Of course, legal entity registries can follow the OrgBook model, but there are many other similar examples. Professional accreditation organizations often have a need to make their membership lists public, including law societies, engineers, nurses, teachers, doctors, universities, colleges, and the list goes on. All of these kinds of services can benefit from having a public and trustworthy source of truth on the internet. And there are private use cases such as using an Indy Catalyst Credential Registry to be an “Evidence Locker” to store “digital evidence tags”.

Both of our active agents are rooted in the Sovrin Network. You can resolve their DIDs using these links: BC Registry did:sov:HR6vs6GEZ8rHaVgjg2WodM, and OrgBook BC did:sov:NewAUq29E4jLJ5jMSxns3s.

We’re very proud of being one of the first governments to have a DID on the Sovrin Ledger as well as deploy one of the first production use cases of Hyperledger Indy using the Sovrin Network.

Sovrin: Describe the open source community as it relates to your work?

John: Open source software development is a cornerstone of the Government of British Columbia’s transition to a digitally native government. Open source software allows us to benefit from the globally leading efforts such as Hyperledger Indy and to demonstrate our commitment to public good by sharing code.

The Sovrin/Hyperledger Indy community has been a huge help in building our understanding of the verifiable credentials model and in the use of Hyperledger Indy. We began by joining the weekly Hyperledger Indy working group calls. I think it was on our second call that we started asking questions and sometimes feeling like we were selfishly taking up community time. Those discussions, combined with our research into self-sovereign identity capabilities soon led us to a vision for what we could create and ultimately, OrgBook BC.

Since then, we’ve done all of our work in the open, and we’ve done better at driving agendas rather than just hijacking them. All of the software we have developed to realize the vision of VON is open source, and we welcome others to learn from our work, take and use it in their jurisdiction, and ideally, contribute with capabilities that we can use.

We were helped immensely by a parallel effort in British Columbia called the BC Dev Exchange — an ‘open by default’ model for delivering digital services. It’s a program that combines modern approaches to digital service design, Agile development, and DevOps-driven deployment with effective procurement mechanisms.

The DevExchange platform enabled us to build the capabilities of VON pretty rapidly. We used two “Code With Us” procurements to bring in experts from outside the project for specific deliverables: enterprise-grade agent storage and DID-Authentication capabilities. We were able to subsequently provide those developments back to the community.

Sovrin: What is the future of VON?

John: We are growing VON in four ways.

• First, we are focused on adding British Columbia government services to our own VON ecosystem. We are working with a variety of the permit and licence issuers to help them make use of authentic and authoritative data in OrgBook BC and to issue this data to OrgBook BC using Verifiable Credentials. We’re trying to make that process as easy as possible for our peers.
• Second, we are looking for collaborators from other jurisdictions that would like to build on the model we’ve created and deploy their own instance of the Credential Registry component, so they can have an OrgBook for their digital economy. There isn’t an easier way to learn about verifiable credentials and self-sovereign identity capabilities than OrgBook, all while bringing real value to businesses.
• Third, we are continuing to collaborate in the Sovrin/Hyperledger Indy/Verifiable Credentials communities. Our goal is to make sure that interoperability is achieved across all communities, so our citizens have a choice in the software they use to interact with the Government of British Columbia and with each other.
• Finally, we will continue to work on what we think are some new great ideas to help small businesses and small issues such as towns and small cities that will become possible once the verifiable credentials interaction model hits the mainstream.

###

OrgBook BC uses the Sovrin Network to allow businesses to share verifiable data online in a trustworthy way like never before. To learn more about VON and OrgBook BC, visit https://vonx.io/ or watch this webinar.

Sovrin Network Use Case Spotlight was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Mike Lodder holds the position of Security Maven for the Sovrin Foundation and is responsible for writing protocols, developing security policies, implementing crypto, and assessing the strength of the Sovrin Network.

At a recent ‘Brown Bag Meetup’ hosted at Sovrin Foundation headquarters in Provo, Utah, Mike gave a fantastic presentation about Zero Knowledge Proofs. We asked Mike to tell us a bit about his presentation, why Zero Knowledge Proofs are valuable, and how the Sovrin Network uses them to provide identity holders with flexibility and privacy.

Q.What is a Zero Knowledge Proof?
Mike Lodder: Zero Knowledge Proofs (ZKPs) are cryptographic techniques that allow users to share information without relinquishing their security and privacy. ZKPs use cryptography to prove a statement from party A (known as a prover) to party B (known as a verifier) without revealing anything else. Zero-knowledge proofs must have three properties to be usable:

• Completeness: If the statement is true, the verifier believes the result of the proof.
• Soundness: If the statement is false, the prover is unable to create a false proof to fool a verifier into thinking that it is true.
• Zero-knowledgeness: The verifier does not learn any other information about the prover other than what is in the proof.

A classic example is date of birth. Driver’s licenses/ID cards are often the primary means of proving age. However, this type of ID also contains other valuable, private information (such as a person’s home address) that is frequently used in identity theft. Selective disclosure uses ZKPs to turn (for example) a digital copy of a driver’s license into an abstract proof of itself. It’s as if you’re creating a carbon copy of your driver’s license that is every bit as reliable, and conveys the same personal identifiable information, as the real thing; but, based on who is asking, you control what information actually appears to them on that particular copy.

Using something as simple as a mobile app, you could create a ZKP for each situation where you need to prove your age. ZKP allows you to quickly, easily, and securely verify you are over 18, (or 21 or 65) without actually having to share your specific date of birth.

Q. How does Sovrin use ZKPs?
ML: Companies using the Sovrin Network can issue credentials that identity holders keep in the digital wallet of their choice. Pieces of personal information on that credential, such as an address or social security number, are called “attributes.” ZKPs are created using these attributes. Using the Sovrin Network, identity holders create ZKPs to prove one or more of the following things about their attributes.

1. Equality: if the attribute is equal to the value or an identity holder can just reveal the attribute itself in the proof

Example: [Are you employed?] = Sovrin ZKP: [Yes] or [Employer: IBM]

2. Inequality: if an attribute lies in a specific range without revealing the actual value. This is helpful when dealing with something that has a numerical attribute, like age or money.

Example: [Are you over 21] = Sovrin ZKP: [Age >= 21]

3. Set Membership: ZKPs can prove if a value is contained in a set without revealing with value.

Example: Do you live in Europe? = Sovrin ZKP: [Country of residence is: a European country] or [Country of residence is: not in a European country]

Q. Describe ZKP at it’s most basic level?
ML: Sure, the developer community often uses the classic Alice and Bob illustration to explain complex user scenarios in real world terms.

For this example, Alice and Bob want to know if they both make the same salary but don’t want to tell one another exactly how much they make. So, they agree to the following system:

Alice and Bob take 10 boxes that represent all the possible salaries ranging from $30,000 to $120,000, in increments of $10,000.

All of the boxes are locked and Alice and Bob can’t open any of them.

Alice, without Bob looking, chooses the key to the box that corresponds to her salary amount.

Bob, without Alice looking, puts a piece of paper into each of the boxes that indicates if his salary matches what the box represents or not. He puts an O on a piece of paper into the box matching his salary and an X on a piece of paper in the rest of the boxes. Bob then leaves.

Alice returns and uses her key to open the box that matches her salary. If the box she opens has a note with an O, Alice knows she has the same salary as Bob. If she sees a note with an X, it means they have different salaries, but has no idea how much Bob actually makes.

Once they are reunited, Bob only learns that Alice has the same or different salary by seeing if the slip of paper Alice has in her hands has an O or X.

This system makes it so Alice and Bob cannot learn if one makes more or less money than one another.

As contrived as this example is, the basic principle remains the same. ZKP allows for the control over individual pieces of private identifying information, with the ability to communicate and share that same information.

What makes Sovrin’s use of ZKPs unique?
The Sovrin Network is the only system that makes it feasible for identity holders to deploy ZKP for all of their verifiable identity claims. With a Sovrin identity, you can generate ZKPs from any of your digital credentials to verify who you are to any verifier operating within the Sovrin Network. Further, you can choose to selectively share different attributes from these identity credentials without showing the credential itself.

While there are other companies attempting to use ZKP technology, Sovrin was built from the ground up as a global public utility for identity and is proud to have this privacy preserving technology integrated deeply into the network. The Sovrin Network scaled the use of self-sovereign identity and ZKPs so that anyone using Sovrin to manage their credentials can use them to communicate and transact with other people, organizations, and even things.

Photo by Tim Evans on Unsplash

The Sovrin Foundation sponsors brown bag meetups monthly onsite at its offices in Provo, Utah. For a complete listing of these events and other Sovrin sponsored events, check out our Press Page.

The Sovrin Network and Zero Knowledge Proofs was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

We take the Internet for granted, not realizing that such a global, decentralized system is a rare thing. Protocols, rightly, get credit, but they alone are insufficient. TCP/IP did not create the Internet. The Internet is not just a set of protocols, but rather a real thing. People and organizations created the Internet by hooking real hardware and communication lines together. To understand the importance of this, we need to understand what’s necessary to create social systems like the Internet.

Social systems that are enduring, scalable, and generative require coherence among participants. Coherence allows us to manage complexity. Coherence is necessary for any group of people to cooperate. The coherence necessary to create the Internet came in part from standards, but more from the actions of people who created organizations, established those standards, ran services, and set up exchange points.

Coherence enables a group of people to operate with one mind about some set of ideas, processes, and outcomes. We only know of a few ways of creating coherence in social systems: tribes, institutions, markets, and networks[1]. Startups, for example, work as tribes. When there’s only a small set of people, a strong leader can clearly communicate ideas and put incentives — and disincentives — in place. Coherence is the result. As companies grow, they become institutions that rely on rules and bureaucracy to establish coherence. While a strong leader is important, institutions are more about the organization than the personalities involved. Tribes and institutions are centralized — someone or some organization is making it all happen. More to the point, institutions rely on hierarchy to achieve coherence.

Markets are decentralized — specifically they are heterarchical rather than hierarchical. A set of rules, perhaps evolved over time through countless interactions, govern interactions and market participants are incented by market forces driven by economic opportunity to abide by the rules. Competition among private interests (hopefully behaving fairly and freely) allows multiple players with their own agendas to process complex transactions around a diverse set of interests. Markets don’t displace institutions completely but do help institutions process transactional exchanges.

Networks are also decentralized. The rules of interaction are set in protocol. But, as I said earlier, protocol alone is not enough. Defining a protocol doesn’t string cable or set up routers. There’s something more to it. One form of organization doesn’t usually supplant the previous, but augments it. The Internet is the result of a mix of institutional, market-driven, and network-enabled forces. The Internet has endured and functions because these forces, whether by design or luck, are sufficient to create the coherence necessary to turn the idea of a global, public decentralized communications system into a real network that routes packets from place to place.

My interest in coherence is driven by efforts to create a global, public, decentralized identity system that we call Sovrin. Sovrin is an identity network that, like the Internet, achieves coherence through a combination of institutional, market-driven, and network-enabled forces. I think of Sovrin as the Internet for Identity. The Sovrin network is not owned by anyone, but, like the Internet, is created through the cooperation of many people and organizations. Sovrin is seeking to create a global, decentralized, identity network that is open to all. That’s a little bit different thing that creating a standard or a protocol.

When I say Sovrin is “public” I mean that we intend for it to be a public good that anyone can use so long as they adhere to the protocols, just like the Internet. Public spaces require coherence. Coherence in Sovrin springs from the ledger, the protocols, the trust framework, standards, and market incentives. These gives Sovrin greater coherence than a protocol alone can achieve.

• The ledger creates a decentralized service where various participants can exchange important information without the need for a central authority. But like the Internet, the ledger requires multiple organizations to commit real resources. The Sovrin ledger is a significant piece of the Sovrin network. The ledger provides a global registry for identifiers. This has several significant advantages over DNS as a registry. DNS-based identifiers aren’t permanently owned. This can present real security concerns. With a ledger, identifiers can be persistent and non-reusable. Second, DNS-based solutions require that every site that wants to run registry functions has to install and maintain software for that purpose. This incents centralization of the directories. With a ledger-based solution, a global network does this without special effort on the part of participants.
• The trust framework is an agreement that is administered by the Sovrin Foundation. The trust framework makes shared goals and principles explicit so that the various participants in the system can work together. The trust framework is the basis for shared action and processes.
• Standards like those being developed for Decentralized Identifier (DID) and the verifiable credentials are important for interoperability, but more so specifications and standards on how to communicate with the ledger and the peer-to-peer communication of agents are critical to portability and the rise of a functional ecosystem of software that isn’t controlled by a single vendor.
• Market incentives have traditionally been difficult to incorporate into a networked ecosystem, but the rise of tokens is a recent development that promises to change this. Token-based ledgers come with incentives to participate and thus are self-sustaining in ways that DNS-based identifier registries can’t be. This also alleviates power imbalances where large companies have an advantage relative to individuals. As Chris Dixon says “Token networks …[align] network participants to work together toward a common goal — the growth of the network and the appreciation of the token.” In short, tokens provide a means for establishing coherence.

Someone asked me recently how Sovrin differed from an identity protocol like OpenID Connect. The factors that give rise to coherence are the primary difference between a protocol like OpenID Connect and something like Sovrin. Simply put, Sovrin is a network and OpenID Connect is not. This is where I think we’ve largely gone wrong in building decentralized systems in the past. We’ve shied away from putting a stake in the ground and building a thing. Instead we’ve defined protocols and allowed the network effects to accrue to centralized companies who can establish the coherence necessary to create a real thing. My strong belief is that real networks are necessary for enduring decentralized systems.

Endnotes

Photo Credit: Coherence in chaos from Dhiren Mistry (CC BY 2.0)

Originally published at www.windley.com.

Coherence and Decentralized Systems was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

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[1], 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[2].

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[3].

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[4].
• 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 Subject 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[5]. 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)

Originally published at www.windley.com.

Building Your Business on Sovrin: Domain-Specific Trust Frameworks was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The Sovrin Foundation is excited to announce that we have hired of Nathan George as our Chief Technology Officer. Nathan was previously Chief Architect at Evernym, Inc. He has been instrumental in maintaining the Hyperledger open-source Project Indy, which is sponsored by the Sovrin Foundation. Nathan comes with a wealth of experience that will help Sovrin thrive and reach its full potential.

I’m very excited to have Nathan join the foundation. The Sovrin Foundation is much more than an advocacy organization for self-sovereign identity. As I wrote in Decentralized Governance in the Sovrin Foundation, the foundation exists to administer the Sovrin Trust Framework and a significant aspect of that entails designing and implementing protocols, managing Project Indy, and supporting the Sovrin Stewards in their operation of the network nodes. These tasks are technical and having a full-time technology executive focused on this is critical to the success of the network, and the foundation itself.

The Sovrin Foundation technology goals, on which Nathan will have primary focus, include:

• Planning and following a roadmap that outlines Sovrin development
• Implementing a Sovrin RFC and Improvement Project process
• Supporting steward onboarding and operation
• Managing the release process that prepares code for Stewards
• Monitoring network operation and reliability
• Impacting design of the various components of the Sovrin ecosystem
• Supporting feature development through bounties and other developer incentive programs
• Participating in standards processes that impact Sovrin

Hiring a CTO represents a big step along the path to self sustainability for the Sovrin network. A huge part of being self sustaining is technical independence. Having a CTO in the Sovrin Foundation will allow us to drive many technical developments and coordinate our open source projects from within the foundation.

Photo Credit: Circuits from Max Pixel (CC0)

Originally published at www.windley.com.

Sovrin Foundation Welcomes Nathan George as CTO was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.

Marc Hulty defines governance as “the processes of interaction and decision-making among the actors involved in a collective problem that lead to the creation, reinforcement, or reproduction of social norms and institutions.” From this we can conclude that everything gets governed, the question is whether governance is ad hoc or formal, explicit or implicit.

One of the ironies of decentralized systems is that they require better governance than most centralized systems. Centralized systems are often governed in an ad hoc way because the central point of control can easily tell all participants what to do. Decentralized systems, on the other hand, must coordinate across multiple parties, all acting independently in their own self-interest. This means that the rules of engagement and interaction must be spelled out and agreed to ahead of time, with incentives, disincentives, consequences, processes, and procedures made clear.

The Internet is an excellent example of this. All the computers that connect to the Internet, along with those that route messages between nodes, follow a set of procedures determined ahead of time that cannot be ignored by participants without loss of functionality. These procedures are called protocols and they are embodied in the code that participants in the network — both edge nodes and routers — execute.

Blockchain systems are no different. Their interactions are wholly or partially governed by protocols embodied in code. But these protocols are not emergent properties of the blockchain, rather they are designed by humans who write the code and agreed to by the humans who execute it. Without the design and agreement of humans, the blockchain does not function.

The Sovrin blockchain is a good example. There are two primary components of how Sovrin operates: the design of the protocols and the operation of the ledger. We can ask governance questions about each.

Sovrin’s code is open source — specifically it is the Hyperledger Indy project under the umbrella of the Linux Foundation. This means developers from around the world collaborate to design and build the code that makes Sovrin work. Their decisions are governed in the way of most open source projects: rough consensus and running code with pull requests accepted by a core set of developers who manage the code base. Code embodies the rules that make up the Sovrin protocol. Since the protocol is a critical component of Sovrin governance, how decisions are made about the code is a key component of ensuring Sovrin is governed well.

But with the Sovrin blockchain there is another kind of governance that is not embodied in the code. Sovrin is built on a public permissioned blockchain. This means that anyone can use the Sovrin ledger, but consensus is achieved by a known set of validator nodes. Validators perform a similar function on a permissioned ledger than miners perform on a permissionless ledger — ensuring that each copy of the ledger records the same data in the same order1. Since Sovrin’s validators are part of a known group, we should also examine how this group of validators is selected, organized, and governed.

Decisions about how code is architected, which code is run by validator nodes, and how those nodes operate are made in accordance with the Sovrin Trust Framework, a document that specifies how the Sovrin Network is governed. The Trust Framework is Sovrin’s constitution, defining the operation and organization of the network, and is where the final authority for the Sovrin Network lies. In fact, Sovrin can be said to have a constitutional governance model. The Sovrin Foundation is an international, non-profit organization that represents the collective interests of all Sovrin identity owners. Sovrin Foundation exists to administer the Trust Framework. The Sovrin Foundation clearly and openly identifies the actors in decisions and the processes they use to reach those decisions and ensures they are made consistent with the trust framework.

Sovrin’s Trust Framework is based on a set of shared goals consistent with establishing a global public utility for privacy-respecting, self-sovereign identity. In One from Many: VISA and the Rise of the Chaordic Organization, Dee Hock writes:

In the constructive sense of the word, governance can be based only on clarity of shared intent and trust in expected behavior, heavily seasoned with common sense, tolerance, and caring for others as fellow human beings. This is not to say that contracts, laws, and regulations do not serve a purpose. Rather it is to point out that they can never achieve the mechanistic certainty and control we crave. Rules and regulations, laws and contracts, can never replace clarity of shared purpose and clear, deeply held principles about conduct in pursuit of that purpose.

In the case of Sovrin, that shared purpose and deeply held principles are contained in the Sovrin Trust Framework. The Trust Framework lays out the purpose of Sovrin as providing a global public utility for self-sovereign identity that adheres to a set of thirteen principles2:

• Independence and Self-Sovereignty
• Guardianship
• Diffuse Trust
• Web of Trust
• System Diversity
• Interoperability
• Portability
• Security by Design
• Privacy by Design
• Accountability
• Openness
• Identity for All
• Collective Best Interest

Sovrin embraced these principles to meet the needs of identity owners and protect their data, privacy, and autonomy. These principles guide both the technical development of the Sovrin code and the operational rules for stewards, the trusted organizations who operate validator nodes and connect to the ledger in a transparent way.

Some have pointed to the permissioned structure and the existence of the foundation as a reason for distrusting whether it is truly a decentralized public network. To those people I say, “Look at the Trust Framework and tell me where it falls short.” Often this question is just a knee-jerk reaction to how Sovrin splits governance between code and agreement. There’s nothing magic about code when it comes to governance. It can automate things but it has no special properties when it comes to resisting accumulation of power or autocratic tendencies. Even in permissionless blockchains, change is proposed by the developers and accepted (or not) by miners. These are people coming to agreement or not based on the principles they hold dear.

Sovrin’s Trust Framework makes those principles explicit by providing a documented public agreement (consensus) about them. The process for amending Sovrin’s Trust Framework is also public. The stewards running validator nodes agree (or not) by accepting or rejecting changes. This is the same process we (and other public blockchains) use for managing code changes. It ensures that Sovrin continues to be public and open to all. There is no point of centralization in Sovrin because no single entity can force other participants to bend to that entity’s will. Sovrin is technically, politically, and geographically decentralized to achieve diffuse trust, which enables diffuse control.

Others might wonder how the Trust Framework governs the code that Sovrin runs. While it’s true that Sovrin code is open source and anyone can make contributions, those contributions still have to be accepted by the maintainers of Project Indy to be incorporated in the codebase. Further, the Indy code is not automatically transferred to Sovrin validators to run, but is subject to review by Sovrin’s Technical Governance board and the Stewards themselves.

Those reviews ensure that only code consistent with the Trust Framework is run by validator nodes. These reviews also put appropriate pressure on Project Indy contributors and maintainers to adhere to Sovrin Trust Framework principles, since not doing so could lead to a fork of the project (although not the ledger), with Sovrin developing its own branch of the Indy codebase to protect its interests. Recent events in the blockchain space show that this is not inconceivable, but it would be disruptive and costly to the ultimate success of Project Indy. This neatly aligns incentives between Project Indy and Sovrin. Make no mistake; Sovrin will take decisive action if our principles are threatened.

Participation in Sovrin is open to all. As I wrote in Is Sovrin Decentralized?: anyone can create identifiers. Sovrin does not have “identity providers” because they are entirely unnecessary; identity owners are empowered to carry their own claims. Furthermore, any organization who will publicly agree to the Trust Framework and meets its requirements is welcome to become a Sovrin Steward.

This is the ultimate point: no single entity owns or controls Sovrin, not even the Sovrin Foundation. The Sovrin network is a global public utility that we all own, collectively, just like we all own the Internet. And the governance model of the Trust Framework, along with governance of the open source Hyperledger Indy code run by all Sovrin stewards, has been carefully designed to reflect this. All of this is captured in the Sovrin Trust Framework which is developed and published under an open public process available to all.

The public and open nature of Sovrin supports an unprecedented level of autonomy, privacy, security, and control by the people and organizations using Sovrin. We welcome you and your organization to join us in this important work.

Endnotes:

1. There are many reasons for using a permissioned model, as spelled out in the recent Sovrin Foundation white paper, but one of the most important is cost. Simply put, if the cost of using a ledger can be kept very low, then it will enable people to use a different cryptographic identifier for each relationship, thus reducing correlation risk and increasing privacy. Any blockchain-based identity system must be carefully architected to take advantage of the blockchain without sacrificing the privacy of the participants in the system. If writing transactions to the blockchain is expensive, as it typically is in permissionless ledgers, people are more likely to reuse identifiers (or hashes) and increase the risk of unwanted correlations.
2. See Section 2 of the Trust Framework for a detailed discussion of these principles.

Thanks to Steve Fulling, Drummond Reed, Timothy Ruff, Jason Law, and Daniel Hardman for helpful discussions on this topic that improved the post and made it more clear.

Photo Credit: Bees and Honeycomb from Phil Windley (CC0)

Originally published at www.windley.com.

Decentralized Governance in Sovrin was originally published in Sovrin Foundation Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.