Drummond Reed

In chapter 2, we introduced the basic concept of the governance framework as a core building block of SSI architecture. In this chapter, we go much deeper into the special role governance frameworks play in fusing SSI technology with the realities of business, law, and society. As you read this chapter, keep in mind that SSI is a cutting-edge technology movement, and SSI governance frameworks are at the cutting edge of SSI. As a result, there are still relatively few governance frameworks in production as examples to which we can point. However, many in the SSI community believe they will be a crucial part of SSI’s success. In particular, the ToIP Foundation is the first industry body to explicitly focus on the role of governance frameworks in decentralized digital trust infrastructure. This chapter will use the ToIP stack and other initiatives in the space to explain how different governance frameworks are relevant to each layer of SSI architecture. This subject will undoubtedly evolve quickly over the next few years; our goal is for this chapter to be a starting point for anyone who wants to explore and/or contribute to this area.

11.1 Governance frameworks and trust frameworks: Some background

Governance is as old as human society. In today’s world, it is the job of governments, companies, and any other human organization. But the concept of a governance framework is newer. From the perspective of technology infrastructure, the ISO/IEC 38500 standard defines governance as “a system by which the current and future use of information technology (IT) is directed and controlled.” More specifically, within the digital identity industry, this can be specialized as an identity governance framework. In identity policy circles, this is also called a trust framework—a term often used interchangeably with governance framework.

Nacho Alamillo, chief trust officer of the Alastria Blockchain Ecosystem and leader of the ISO/WD TR 23644 on “Blockchain and Distributed Ledger Technologies— Overview of Trust Anchors for DLT-based Identity Management (TADIM, https://www.iso.org/standard/81773.html), defines a trust framework this way:

Trust frameworks exist to describe the policies, procedures and mechanisms for the operation of digital trust across a community of trust, whether that exists in a legally binding agreement or whether it is mandatory across the nation or jurisdiction under the rule of law. In almost all cases, the start point for a trust framework is the legal baseline upon which the Common Policy framework is built, which forms the core of the trust framework.

Trust frameworks were originally applied to public key infrastructures (PKI), particularly in support of cross-certification and certificate authority (CA) bridge models. The use of trust frameworks grew with the emergence of federated identity systems (chapter 1) where the organizers needed to agree on the rules under which the federation members (especially the identity providers) would operate. These rules naturally fell into three buckets:

• Business rules governing who could join the federation, membership costs, operating costs, business models, and so on

• Legal rules governing jurisdiction, membership, liability, insurance, and so on

• Technical rules for what standards, systems, and protocols were required for interoperability

Dazza Greenwood, an attorney, digital identity consultant, and lecturer at MIT Media Lab, coined the term BLT sandwich for this “stack” of policies, as shown in figure 11.1.

Figure 11.1 The BLT sandwich metaphor for the general three-part structure of governance frameworks

By the late 2000s, federated identity systems had grown to the point where there was a need to start standardizing and promoting them. In 2009, when the Obama administration came to power in the United States, it proposed to work with private industry to build a trust framework under which U.S. government agencies could begin accepting federated identities from private identity providers like banks, social networks, insurance companies, and healthcare providers. Since no existing industry association was designed for that purpose, the OpenID Foundation and the Information Card Foundation got together and created a new international non-profit organization called the Open Identity Exchange (OIX, https://openidentityexchange.org).

For the next decade, OIX hosted the development of a number of trust frameworks across both government and industry, including telecom, healthcare, and travel. The common theme was defining the set of rules under which a specific federated identity and data sharing network could operate. But starting in 2015, the identity community was inspired by a new type of network that roared onto the global stage: the blockchain network. As we explained in chapter 1, some digital identity architects began to see how blockchains could enable the next step beyond federation: a decentralized approach to digital identity infrastructure that no longer needed to rely on centralized identity providers. Thus SSI was born.

However, decentralization does not necessarily mean less governance. Although this view is not shared by everyone in the SSI movement (see chapter 15), in a February 2018 blog post, Phil Windley, founding chairperson of the Sovrin Foundation, framed the argument this way [1]:

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.

That, in a nutshell, is a governance framework. The term itself is rooted in blockchain technology: as blockchain networks evolved, governance models became one of the major differentiating features among different blockchain projects. Thus when the first blockchain networks appeared that were expressly designed to support decentralized identifiers (DIDs), the SSI community was more comfortable with the term governance framework than trust framework. One of the reasons is how well the governance trust triangle fits with the verifiable credential trust triangle.

11.2 The governance trust triangle

In chapter 2, we introduced the basic trust triangle for verifiable credentials (the top half of figure 11.2). We then added the governance trust triangle (the bottom half of figure 11.2) to show how trust networks based on verifiable credentials can scale to any size.

Figure 11.2 The governance trust triangle (bottom half) multiplies the use of the verifiable credential trust triangle (top half).

Although the concept of a governance trust triangle might seem new, it is precisely the same structure used by several of the world’s largest trust networks. This becomes clear when we fill in the names for one of these networks in figure 11.3.

Figure 11.3 Global credit card networks like Mastercard and Visa are good present-day examples of how governance frameworks enable trust networks to scale globally.

Here’s how the two trust triangles work together in the Mastercard network example:

• Mastercard is the governance authority. It establishes the rules and policies governing the issuance and acceptance of credit cards, debit cards, and other credentials on the Mastercard network, including onboarding, payment authorization, chargebacks, liability, and so on. It also sets the requirements for security, privacy, data protection, and other regulatory compliance policies. Finally, it specifies the technology, testing, and certifications necessary to operate on the network.

• Banks, credit unions, and other financial institutions are the issuers of credentials on the network.

• Cardholders are the credential holders.

• Merchants are the verifiers of the credentials—in this case, to obtain a payment authorization.

note Dee Hock, the founder and initial CEO of Visa, is the author of One From Many (Berrett-Koehler, 2005; originally called Birth of the Chaordic Age), one of the breakthrough books to argue that our current organizational structures are failing the world and how “chaordic” organizations (chaos + order) could be the way forward as part of a decentralized world. Many of Hock’s ideas are closely related to the decentralization movement in the blockchain ecosystem that we explain in detail in chapter 15.

While credit card networks are good general examples of governance frameworks from the current business world, in SSI, governance frameworks can become more specialized. We will illustrate this by showing how they can apply to each layer of the ToIP stack.

11.3 The Trust over IP governance stack

At the end of chapter 2, we introduced the four-layer Trust over IP (ToIP) stack (figure 11.4) to show how the basic building blocks of SSI can be assembled into the architecture for a comprehensive trust layer for the internet. With regard to governance, there are three key takeaways from this diagram:

• Governance is half the stack. Most stacks, such as the TCP/IP stack that is the basis for the internet, consist entirely of technology components: protocols and APIs. While the ToIP stack includes a technology stack, it is only half the picture. When it comes to establishing trust both within and across the boundaries of trust communities worldwide, governance is equally important—many would argue it is more important. (This final point was a primary rationale for the establishment of the ToIP Governance Stack Working Group at the ToIP Foundation. Its job is to define standard models and templates for governance frameworks at all four layers of the stack.)

• Technical trust is separated from human trust. Governing how machines and protocols must be designed and deployed to be trusted by humans is very different from governing what people and organizations must do to be trusted by one another. The first two layers of the stack use cryptography, distributing networking, and secure computing to lay a solid foundation for technical trust. The top two layers add the components that only humans can judge: verifiable credentials (VC) about real-world attributes and applications that produce and consume VCs to power digital trust ecosystems.

Figure 11.4 The Trust over IP stack includes both a governance stack and a technology stack.

• Each of the four layers requires a different type of governance framework. This was a critical learning of the SSI community—that governance frameworks are not “one size fits all.” Each of the four layers has structural roles and processes that require policies tailored for that layer.

The following sections explain the special governance challenges at each layer.

11.3.1 Layer 1: Utility governance frameworks

At this lowest layer of the stack, governance applies to the operation of a public utility that provides the verifiable data registry (VDR) services on which higher layers need to rely. You can think of the VDR as a decentralized datastore that can take many different forms depending on the technology architecture being used—blockchain, distributed ledger, distributed file system, distributed directory system, or peer-to-peer protocols.

The roles and processes necessary for the governance of a Layer 1 public utility depend on the architecture of that VDR. For example:

• Public permissionless proof-of-work blockchains such as Bitcoin do not have any formal governance; they rely on the meritocracy of an open source project and the “vote with your feet” power of the miners who operate Bitcoin nodes and effectively govern the network by choosing what version of the open source codebase to run. For many of the most traditional participants of the Bitcoin community, the concept of having centralized organizations define rules for the network goes against all principles that the blockchain movement stands for. However, while Bitcoin was designed to be a peer-to-peer cash system, some people argue that today’s technology is not ready to run fully decentralized identity networks but that decentralization will be good enough to start with. This is a subject that creates heated debates and that we cover extensively in chapter 15.

• Public permissionless proof-of-stake blockchains are governed by a voting algorithm programmed into the blockchain code that ties voting power to the size of the voter’s holdings of the associated token. (Examples include Stellar, Cosmos, and Neo. Ethereum also has a stated goal of moving to proof-of-stake.) However, projects built on top of these blockchains, such as the EU European Blockchain Services Infrastructure (EBSI), are building formal governance frameworks based on EU legal instruments such as Electronic Identification, Authentication, and Trust Services (eIDAS).

• Public permissioned blockchains such as Sovrin and others based on Hyperledger Indy (https://wiki.hyperledger.org/display/indy) use formal governance frameworks developed under an open public process. An example is the Sovrin Governance Framework, first published in June 2017 and now in its third generation of development (https://sovrin.org/governance-framework).

• Hybrid blockchains such as Veres One and Hedera combine aspects of permissioned and permissionless models. For example, on Veres One, anyone can run a blockchain node, but changes to the network and business model are governed by a community group and a board of governors (https://veres.one/net work/governance).

• Private blockchains such as Quorum are operated by their members for their own usage. Their governance frameworks may or may not be public.

Keep in mind that blockchains and distributed ledgers are not the only options for providing a VDR at Layer 1. Other options include distributed file systems like InterPlanetary File System (IPFS), key event logs like those used by Key Event Receipt Infrastructure (KERI), and distributed hash tables (DHTs).

Note Not all VDRs need to be decentralized. For some trust communities, it is acceptable to rely on centralized registries, directory systems, or certificate authorities.

Purist permissionless network proponents will argue that a real decentralized network does not need a governance framework since mathematics and cryptography ensure that proper governance is in place. Again, in chapter 15, we expand on many of these philosophical architecture choices and how they express themselves in the SSI market.

Depending on the governance model, standard governance roles at Layer 1 can include

• Maintainers—Developers of the blockchain code

• Miners—Operators of a permissionless blockchain node

• Stewards—Operators of a permissioned blockchain node

• Transaction authors—Anyone initiating a transaction with a blockchain

• Transaction endorsers—Parties who can authorize transactions to a permissioned blockchain

The draft ISO 23257 standard, Blockchain and Distributed Ledger Technologies—Reference Architecture (https://www.iso.org/standard/75093.html), describes the role of a blockchain governance authority at this level as a DLT governor:

Given that DLT systems are inherently distributed, with multiple nodes typically owned and operated by multiple organizations, there is a need for a role which governs the DLT systems as a whole and keeps the DLT systems able to execute the tasks for which they were established.

The draft standard goes on to list the following typical activities of a DLT governor:

• Developing DLT policy considering applicable laws and regulations

• Communicating the policy with stakeholders

• Resolving conflicts and managing changes

• Defining polices for consensus mechanisms

• Defining policies for nodes that can participate in the DLT networks, including the minimum security requirements

• Working with DLT providers

• Working with DLT node operators to ensure that monitoring and governance are enforced

11.3.2 Layer 2: Provider governance frameworks

Layer 2 governance is a different beast from Layer 1 because what is being governed is not a public utility but the capabilities of digital wallets, agents, and agencies (see chapter 9). The need is primarily to establish baseline security, privacy, and data-protection requirements, plus interoperability testing and certification programs, for the following roles:

• Hardware developers who provide compliant hardware, e.g., secure enclaves, trusted execution environments, and hardware security modules (HSMs)

• Software developers who provide compliant wallets, agents, secure data stores, etc.

• Agencies who host cloud wallets and agents for individuals, organizations, and guardians

Hardware and software security requirements are relatively well understood (if not always well-implemented) and can be subject to rigorous conformance testing. But hosting digital wallets and agents in the cloud requires a new type of service provider—an agency—that has not existed before. Strictly speaking, an agency is not required—agents can connect directly peer-to-peer, as shown in figure 11.5. However, whenever that is not practical, agencies can provide agent-to-agent message routing and queuing and wallet backup, synchronization, and recovery services.

Figure 11.5 Agencies can play a core role in SSI infrastructure by providing message routing and wallet backup, synchronization, and recovery services.

Since all of these services are closely tied to the wallet holder’s activity, Layer 2 governance frameworks are expected to cover agencies’ security, privacy, and data-protection requirements. Furthermore, specialized agency services are necessary to support the services of digital guardianship, covered in chapter 9. The guardian—be it a person or an organization—needs to be able to host and manage a cloud wallet on behalf of the dependent—anyone not in a position to manage their own digital wallet or agent at all (e.g., refugees, people experiencing homelessness, the infirm, young children). Since a guardian is acting as an information fiduciary on behalf of the dependent, a digital guardian’s legal duties and responsibilities need to be spelled out in a Layer 2 governance framework.

11.3.3 Layer 3: Credential governance frameworks

Layer 3 is where we transition from technical trust to human trust, so governance frameworks at this layer will start to look more familiar. The reason is simply that the credential trust triangle and governance trust triangle (shown earlier in this chapter) for digital credentials are very similar to those for physical credentials. Many of the policy frameworks we have for governing physical credentials today—credit cards, driver’s licenses, passports, health insurance cards—can be adapted with relatively little modification to the digital version. See Table 11.1 for standard roles and policy types at this layer.

The roles of issuers, holders, and verifiers are discussed at length in chapter 7. But the concept of a credential registry was not part of the W3C Verifiable Credentials Data

Table 11.1 Standard roles and types of policies for Layer 3 governance frameworks

Role	Policy types
Issuers	Qualification and enrollment Security, privacy, data protection Credentials and claims qualified to issue Identity and attribute verification procedures Level of assurance Credential revocation requirements and time limits Business rules Technical requirements
Holders	Qualification and enrollment Wallet and agent certification Anti-fraud and anti-abuse
Verifiers	Security, privacy, data protection Proof request limitations (anti-coercion) Data usage limitations Business rules
Credential registries	Security, privacy, data protection Acceptance Retention Deletion Availability Disaster recover
Insurers	Insurance policy types Qualifications Coverage limits Rates Business rules

Model specification. Rather, it is a new Layer 3 role conceived by the digital identity team at the Province of British Columbia in Canada. They realized that the cryptographic architecture of the W3C Verifiable Credentials Data Model could enable a powerful new component of decentralized digital trust infrastructure, as shown in figure 11.6.

Figure 11.6 Credential registries are a powerful new component in decentralized digital trust infrastructure because they can serve as verifiable directories of VCs.

You may be wondering what the difference is between the VC issued to the holder at the top of figure 11.6 and the VC issued to the credential registry at the bottom. The answer is, it is the same VC issued to two different holders.

In other words, the data in the claims in the credential describing the credential subject—whomever or whatever that is—is identical. The only difference is the holder to whom the VC is issued. At the top of the figure, the holder is the credential subject (or a guardian or delegate). At the bottom of the figure, the holder is a credential registry whose job is to publish the credential so it can be searched, discovered, and verified by any qualified verifier.

Obviously, credential registries are not for all types of credentials—you would not use them for driver’s licenses, passports, or other sensitive personal information. But for public information—for example, business registrations and licenses that are required by legislation to be published publicly in most jurisdictions—a credential registry is an excellent way to provide that service. For example, the BC government’s credential registry service, called the OrgBook (https://vonx.io), publishes the business registrations and licenses of every single business registered in the Province of British Columbia.

The secret of credential registries is that the DIDs (or link secrets for ZKP credentials) are different for the VC issued to the real holder and the VC issued to the credential registry. This is why the credential registry cannot impersonate the real holder. However, the credential registry can produce a cryptographic proof that it is also an authentic holder of the credential for purposes of discovery and verification. And this cryptographic proof cannot be tampered with by an attacker either outside or inside the credential registry provider—a very desirable security property, especially in a decentralized system.

Another standard Layer 3 role in some governance frameworks is insurers. Any time there is risk, there is insurance. The higher the VC’s value, the greater the liability if an issuer makes a mistake or its system is hacked. Some issuers will offset that risk with insurance, ostensibly making their VCs more attractive to verifiers who know there is a recourse in case they rely on a falsified, hacked, or erroneous credential.

11.3.4 Layer 4: Ecosystem governance frameworks

The top layer of the ToIP stack is the application layer. The purpose of governance frameworks at this layer is to lay the groundwork for entire digital trust ecosystems—for countries, industries (finance, healthcare, education, manufacturing, travel), or other trust communities of any type or size. The ToIP Foundation defines a digital trust ecosystem as follows (https://wiki.trustoverip.org/display/HOME/EFWG+Concepts +and+Workflow):

The set of all parties who have rights and responsibilities under a governance framework for applications at Layer Four of the ToIP stack.

A Layer 4 ecosystem governance framework is the broadest in scope. This means

• It may specify requirements that apply to every other layer of the stack—for example, security and privacy requirements that apply to Layer 3 credentials, Layer 2 wallets and agents, and Layer 1 utilities that want to operate within that ecosystem.

• It may span multiple governance authorities. Digital ecosystems, like real-world ecosystems, are usually built up from constituent trust communities, each of which has its own governance authorities and governance frameworks. So an ecosystem governance framework represents a level of cooperation across all of these other governance authorities and frameworks.

• It may span other ToIP Layer 4 ecosystems. Ecosystems can contain ecosystems. For example, a Canadian national ecosystem defined by a governance framework (such as the Pan-Canadian Trust Framework; see section 11.9) can define policies that apply to provincial ecosystems. And those, in turn, can define policies that apply to ecosystems at the city or county level.

Because they operate at the application layer, ecosystem governance frameworks govern the elements that most directly touch humans—the people and organizations that operate within those ecosystems. The ultimate purpose of SSI and the entire ToIP stack is to enable these humans to easily form digital trust relationships and confidently make trust decisions online. So ecosystem governance frameworks tackle areas such as the following:

• Interoperability—The first goal of every digital trust ecosystem is to enable the applications within it to talk to each other and safely share the data that users want them to. For years, we have been focused on how to enable this technically. But as we solve those technical challenges, the remaining issues are the legal, business, and social barriers. This is where ecosystem governance frameworks can shine.

• Delegation and guardianship—Many of us don’t want to manage our data ourselves, even if we can. That’s why we hire professionals and service providers to do it—bankers, lawyers, doctors, accountants. Others are not able to wield SSI digital wallets and agents directly—they lack the physical, mental, economic, or legal capacity. For both cases, we need to establish legal, technical, and business rules for how we can easily, efficiently, and safely delegate responsibilities to others we trust to manage them for us.

• Transitive trust—With SSI technology and governance frameworks, we unlock the ability for trust developed in one context to be recognized and applied in another context. This happens every day with physical credentials—for example, when a car rental company decides to rent you a car because you have a driver’s license and two major credit cards. Until SSI, this has been nearly impossible to do online. Digital trust ecosystems will change all that—they will make it easy to establish transitive trust between applications and websites within the ecosystem: for example, a travel network or school system.

• Usability—All of SSI will be for naught if it is not easy to use and safe for anyone to use without specialized knowledge about how it works. Ecosystem governance frameworks can define usability guidelines, mandate or provide incentives for their use, and offer certification programs for verifying compliance.

• Trust marks—In the real world, people associate trust with brands represented by trust marks. This is the reason global trust networks like Mastercard and Visa pour billions of dollars into advertising campaigns for their names and logos. The same is true for thousands of other major brands around the world. So one of the most visible functions of ecosystem governance frameworks will be defining their trust mark(s) and the rules for earning and using them. Their goal should be to wrap together everything a person needs to make a digital trust decision.

For ecosystem governance frameworks, the standard roles are more general than the lower layers. They can include the following:

• Member directories (also called trust registries or trust lists)—To establish transitive trust across members of an ecosystem, one of the most vital functions is confirming a particular entity is a member of the ecosystem—and thus bound by the terms and accountability requirements of its governance framework. Member directory services fulfill this role. They can be implemented in many ways, from traditional centralized directory services to federated registries to fully decentralized ledgers. And all of them can function as credential registries as defined in the previous section.

• Certification authorities—If trust marks are a meaningful tool for an ecosystem governance framework, they must have some teeth. One way to do that is for the governance framework to define the criteria for an entity to be certified for any particular role. Certification authorities then oversee this assessment and publish the results (using a VC, of course).

• Auditors—Reviewing the policies, practices, and procedures implemented by a particular entity to determine if they meet the requirements of a governance framework and qualify for certification is the job of a professional auditor.

• Auditor accreditors—This role approves the auditors. The job could be performed directly by the governance authority, but the larger an ecosystem needs to scale, the greater the need to outsource that function to an auditor accreditor organization. This is a role that WebTrust (https://www.cpacanada.ca/en/business-and-accounting-resources/audit-and-assurance/overview-of-webtrust-services) plays for the X.509 digital certificates used by SSL/TLS protocol (the lock in your browser) and organizations like the Kantara Initiative (https:// kantarainitiative.org) play for other digital trust frameworks.

11.4 The role of the governance authority

There is one standard role in all governance frameworks: the governance authority that develops, maintains, and enforces it. Who can be a governance authority?

• Governments at all levels—Laws and regulations are already a governance framework, so producing SSI governance frameworks is a natural extension of the governmental function at any level—international, national, regional, state, district, local. All of these are nested Layer 4 ecosystems with natural Layer 3 credentials.

• Industry consortia—These exist in many industries to solve problems that no single member of the industry can solve alone. Industry-wide governance frameworks, especially at the ecosystem level, are a perfect example.

• NGOs—Non-profit organizations often play a special role in establishing trust by removing the profit incentive. This definitely applies to governance frameworks.

• Corporations and enterprises—A company and its employees, customers, partners, suppliers, and shareholders form a natural trust community—and a natural home for a governance framework.

• Universities and school systems—Educational institutions of all kinds—and the networks they form together—are natural SSI governance authorities because one of the primary outcomes of learning systems is credentials that the learner can use throughout the rest of their lives. (The Internet of Education Task Force was formed under the ToIP Ecosystem Foundry Working Group in July 2020: https://wiki.trustoverip.org/pages/viewpage.action?pageId=66102.)

• Religious organizations—Some of the world’s strongest trust networks are based on religious affiliations, and these can be extended to digital governance frameworks.

• Online communities—Governance authorities do not necessarily need to be formal legal entities—or bound to specific jurisdictions. New types of virtual organizations and communities are forming online, and these can define their own governance frameworks.

The key point is that with SSI governance frameworks, governance to facilitate digital trust is now a tool available to anyone in any community of any size in any jurisdiction.

Who governs the governance authority? That is a classic question of all governance systems, and the answer is: “Whatever works for that trust community.” There is no fixed answer, only a growing number of best practices based on experience with similar initiatives. (Establishing best practices for SSI governance authorities is a key deliverable of the ToIP Governance Stack Working Group: https://wiki.trustoverip.org/display/HOME/Governance+Stack+Working+Group.) However, one best practice is clear from the outset: the governance authority’s own governance structure and policies should be published transparently as part of its governance framework (see section 11.6.1).

11.5 What specific problems can governance frameworks solve?

Governance frameworks are not abstract documents about intentions—they are sets of rules, policies, and specifications designed to help solve a specific set of problems for a trust community.

11.5.1 Discovery of authoritative issuers and verified members

The first question most audiences ask when they learn about digital credentials is, “How do I know I can trust the issuer of the credential?” This one of the primary purposes of Layer 3 and 4 governance frameworks.

Let’s take an example. Say you are an employer, and you want to hire an employee with a college degree in a specific field. An applicant presents you with a proof of a VC of her diploma. Your digital agent verifies that the digital signature on the VC is valid from the DID of the issuer. But how do you know that the issuer DID is a real, accredited university? No employer knows all the accredited universities in the world, let alone all their DIDs.

The answer is that the VC also contains the DID of the governance framework (GF DID) under which the VC was issued. The employer’s digital agent can now use the GF DID to answer two questions:

1. Is the GF DID from a governance authority the employer trusts for educational credentials? (See figure 11.3.)

2. If so, can the agent verify that the member directory for that governance framework includes the issuer DID?

   If the answer to both questions is “Yes,” the employer is satisfied. If the answer to the first question is “No,” the employer’s digital agent can try to answer a third question:

3. Is the GF DID included in the member directory of another governance framework the employer trusts for educational credentials?

This question is very important because it illustrates exactly how transitive trust works. Two different digital trust ecosystems for educational credentials—say, one for Australia and one for New Zealand—could decide to cross-certify: i.e., each recognizes the other's authority to specify the accredited educational institutions in its jurisdiction. Each ecosystem appears as a member of the other in its member directory. Now, if the employer is in New Zealand and trusts the New Zealand educational governance authority, but the applicant has a degree from a university in Australia, the employer will still get a thumbs-up from the employer’s digital agent because of the transitive trust between the New Zealand and Australian educational governance frameworks.

With DIDs, this discovery can work in both directions. If you have a DID, you can resolve it and ask its agent what governance frameworks it is a member of. You can also start with the member directory for a governance framework and discover the DIDs of verified members.

11.5.2 Anti-coercion

The basic principles of SSI presume that parties are free to enter a transaction, share personal and confidential information, and walk away when requests from the other party are deemed unreasonable or even unlawful. In practice, this is often not the case. As Oskar van Deventer of TNO says in “SSI: The Good, the Bad, and the Ugly” [2], it’s like the old joke:

“What do you give an 800-pound gorilla?”

“Anything it asks for.”

Examples of such 800-pound gorillas are big tech providers, immigration offices, and uniformed individuals alleging to represent law enforcement. The typical client-server nature of web transactions reinforces this power imbalance, where the human party behind the browser (client) feels coerced into surrendering personal data to a server because otherwise they are denied access to a product, service, or location. A point in case is the infamous cookie wall, where a visitor to a website gets the choice between “accept all cookies” or “go into the maze-without-an-exit.”

Governance frameworks can implement countermeasures against different types of coercion. For example:

• Require verifiers to be verified members of an ecosystem. This holds the verifiers accountable for abiding by the privacy and anti-coercion policies of the governance framework.

• Require proof requests to have a non-repudiable digital signature from the verifier. That way, a holder can prove a verifier’s behavior in court.

• Require an anonymous complaint mechanism or ombudsman. If a governance framework builds in a service that holder agents can use to report bad behavior of a verifier, this “thousand eyes” approach can be a strong deterrent to such behavior.

In the case of a machine-readable governance framework, some of these countermeasures could be automatically enforced by the user’s digital agent, safeguarding the user from being coerced into action against their own interest. Different governance frameworks may choose different balances between full self-sovereignty and tight control, depending on the interests at play and applicable legislation.

11.5.3 Certification, accreditation, and trust assurance

Another frequent question about the various players in a governance framework is, “How do I know they are playing by the rules?” In other words, no matter how well-designed or complete the governance framework is, how do you know the actors playing each role are complying with the policies specified for that role?

As explained in the next section, most governance frameworks include a key component for this purpose: a trust assurance framework. It is a separate document that establishes the policies under which actors in each role can be audited, monitored, and certified for compliance. It also specifies the rules for selecting, accrediting, and monitoring auditors or auditor accreditors. Since this answers the question “Who watches the watchers?” it can be one of the most important elements of a governance framework.

11.5.4 Levels of assurance (LOAs)

Identity and other trust decisions often are not binary. They are judgment calls. Any time judgment is not a simple “Yes/No” answer, you have the option for levels of assurance (LOAs).

LOAs are most often used to represent the degree of an issuer’s confidence that one or more claims in a credential are true and belong to the intended subject. For example, a bank may be 99% sure that there is more than $10,000 in an account holder’s account but only 80% sure that it has the account holder’s current mailing address.

LOA is a very deep topic in digital identity and thus can be a significant factor in both credential and ecosystem governance frameworks. This is where the LOA criteria can be established for a single VC, for a family of VCs, or across an entire digital trust ecosystem. (For more about LOAs in digital identity, see the U.S. National Institute of Standards and Technology [NIST] Special Publication 800-63-3: Digital Identity Guidelines, https://pages.nist.gov/800-63-3/sp800-63-3.html.)

11.5.5 Business rules

The next most frequent question is, “How do I make money?” For any governance framework to be effective, the members need incentives to develop, implement, operate, and abide by it. In some cases, those incentives might be entirely external, such as regulatory compliance or humanitarian goals. But even then, the governance authority and members will want costs and burdens to be allocated fairly. Of course, commercially oriented governance frameworks need clear business motivations aligned with market forces.

As a result, business rules are a critical part of governance frameworks, such as the following:

• Who is going to pay the shared costs of the infrastructure? How and when?

• What are the available sources of revenue within the framework? Who can charge for what, and when?

• Are revenues split? How?

• How is pricing set?

• Are there penalties or fines for noncompliance?

• How is the governance authority sustainable? Do members pay a membership fee? Licensing fee? Revenue share? Tax?

As a rule, the earlier a governance authority tackles these questions, the more successful the governance framework.

11.5.6 Liability and insurance

One more question always comes to light: “What happens if something goes wrong? Who can get sued? For how much?” This question is essential for any collaborative endeavor to produce something of value. And trust has real value—just look at the “Goodwill” line item on many corporate balance sheets.

So, another standard feature of governance frameworks is policies about liability limits and allocation. Depending on the framework, this can also be coupled with requirements for members to have insurance coverage adequate for their roles.

11.6 What are the typical elements of a governance framework?

Although there are many approaches to crafting a governance framework, the ToIP Governance Stack Working Group has developed a metamodel for ToIP-compatible governance frameworks (https://wiki.trustoverip.org/display/HOME/ToIP+Gover nance+Metamodel) that consists of the modules outlined in figure 11.7.

Figure 11.7 The metamodel for governance frameworks developed by the Governance Stack Working Group at the ToIP Foundation

Organizing a governance framework into these modules does the following:

• Makes it easier for stakeholders to focus on specific policies of interest or relevance to them

• Enables governance of each policy module to be delegated to specific committees, working groups, or task forces within the governance authority who have the relevant subject matter expertise

• Allows policy modules to be versioned independently without requiring a “forklift upgrade” of the entire governance framework

Although their contents may vary considerably, these modules are the same for governance frameworks at all four layers of the ToIP stack.

11.6.1 Master document

If you think of a governance framework like a website (indeed, most human-readable governance frameworks are published on the web), the master document is the “home page.” It is the starting point for navigating all the components of the framework. In the ToIP metamodel, master documents contain the standard sections listed in table 11.2.

Table 11.2 Standard sections of the master document of a governance framework

Section	Purpose
Introduction	Overall background, context, and motivations
Purpose	Mission statement(s)—typically just a few sentences
Principles	High-level guidelines against which specific policies can be evaluated to ensure that they are aligned
Core policies	Policies that generally apply to the whole of the governance framework (specialized policies go in policy modules)
Revisions	Policies governing how the governance framework itself can be revised or amended
Extensions	Policies governing how other governance frameworks (at the same ToIP layer or other layers) may be incorporated as extensions
Schedule of controlled documents	A listing of all the controlled documents in the governance framework and the status, version, and location of each

11.6.2 Glossary

Digital identity can be challenging to describe with great precision because the concepts can be fuzzy, confusing, and even language-dependent (for example, in Russian, there is no good term for the concept of “self-sovereignty”). So both technical specifications and governance frameworks for digital identity benefit greatly from well-researched and documented glossaries. For examples, see the Decentralized Identity Foundation Glossary Project (https://identity.foundation/open-groups/glossary .html), the Sovrin Glossary (https://sovrin.org/wp-content/uploads/Sovrin-Glossary-V3.pdf), and the ToIP Concepts and Terminology Working Group (https://wiki .trustoverip.org/pages/viewpage.action?pageId=65700).

The good news is that once a term is defined in a glossary with the precision required for technical, legal, and policy interpretations, it can be shared across all the documents in the governance framework that need to reference it. Even better, once a term is well defined in one governance framework, it can be reused in other governance frameworks by reference using a permalink to the original source.

11.6.3 Risk assessment, trust assurance, and certification

This category of modules includes policies for assessing and managing risk, including how parties can be certified against the governance framework. Controlled documents in this category should include

• A risk assessment

• A risk treatment plan

• A trust assurance framework (TAF)

As defined earlier in this chapter, a TAF is a module that specifies how members of the trust community can be audited, monitored, and certified for compliance. The TAF is used by auditors to perform the formal assessments that the governance framework may require for qualification, certification (or recertification), and accreditation of different members in different roles. For an example of a TAF developed as a component of the Sovrin Governance Framework, see the Sovrin Trust Assurance Framework: https://sovrin.org/wp-content/uploads/Sovrin-Trust-Assurance-Framework-V1.pdf.

(To learn more about the entire subject of TAFs for SSI, see the “Trust Assurance Development Kit” white paper by Scott Perry, co-chair of the ToIP Governance Stack Working Group: http://mng.bz/6gdG.)

11.6.4 Governance rules

These module(s) are devoted to the governance of the governance authority itself. This can vary greatly depending on the legal form of the governance authority and the nature of the governance framework (algorithmic, human-administered, hybrid). The governance rules are often embodied in the charter, bylaws, and operational policies of a non-profit organization or consortium.

This component is critical because trust in a governance framework can be no stronger than trust in the responsible governance authority. Pay particular attention to the rules governing changes to the governance framework itself (i.e., the amendment or revision process). They dictate how easy, fair, and equitable it is (or is not) to evolve the governance framework to reflect the changing stakeholders, needs, and values of the trust community.

11.6.5 Business rules

Infrastructure of any kind at any layer costs real money to develop, govern, and maintain. As pointed out in chapter 15, this is one reason virtually every blockchain project in the world uses some form of cryptocurrency or digital token to provide incentives for members. The same is true of SSI infrastructure. A standard component of any governance framework is the business rules governing who pays what to whom to provide incentives for all members/participants to engage and sustain the governance authority so it can continue to maintain and improve the infrastructure.

11.6.6 Technical rules

On the subject of technical specifications, the ToIP Foundation recommends that governance authorities refrain from “rolling their own” technology because that approach is usually anathema to interoperability (imagine if every website told you “its way” to build a web browser). Rather, that is the purpose of the ToIP Foundation, the Decentralized Identity Foundation, the W3C Credentials Community Group, the MyData Consortium, and other industry consortia: developing open standard specifications and vendor-neutral technology components from which governance authorities can choose what is needed to meet the requirements of their trust community. This maximizes interoperability and transitive trust while minimizing the potential for vendor lock-in.

In particular, the goal of the ToIP technology stack (the right half of figure 11.4; https://wiki.trustoverip.org/display/HOME/Technology+Stack+Working+Group) is to standardize the choices that governance authorities need to make to implement their policies in a manner that maximizes interoperability with other ToIP-compliant governance frameworks. Ideally, the technical policies are simply profiles of the required and optional ToIP standard specifications (TSSs) needed for that governance framework.

11.6.7 Information trust rules

These are the policies governing information security, privacy, availability, confidentiality, and processing integrity as these terms are defined by the AICPA for ser- vice organizations (https://www.aicpa.org/content/dam/aicpa/interestareas/frc/ assuranceadvisoryservices/downloadabledocuments/trust-services-criteria.pdf). Controlled documents in this category typically include the following:

• Security and access control

• Privacy and data protection

• Information availability and robustness

• Information confidentiality

• Information processing integrity

• Trust marks and publicity rules

• Dispute resolution

For some industries, many of these requirements are already specified by regulations or covered by industry-standard compliance certification programs such as ISO/EIC 27001 or SOC-2.

11.6.8 Inclusion, equitability, and accessibility rules

These are policies governing how the framework does not discriminate among eligible participants and provides equitable access for all, including capabilities specifically aimed at digital accessibility, such as the W3C Web Accessibility Guidelines (https://www.w3.org/WAI/standards-guidelines). To the extent it is relevant, these policies should also address digital guardianship and controllership (covered later in this chapter).

11.6.9 Legal agreements

Not all governance frameworks require legal agreements. It depends on the framework's design and legal architecture and the governance authority (see section 11.8). However, if the framework defines clear rights and obligations of members in specific roles, then it is natural for the framework to include standard legal agreements for this purpose. Another common reason to include legal agreements is to assist with regulatory compliance, especially in the areas of security, privacy, data protection, and inclusion.

Typically, such agreements are in the form of contracts between the member and the governance authority. They include the rights and obligations of both parties. The overall structure of the governance framework can often simplify these agreements because many of the standard components of a legal contract—the “whereas” clauses, definitions of terms, and relevant business rules—are defined in other parts of the framework and can be included by reference. A typical operational requirement of a governance authority is executing, filing, monitoring, and, when necessary, terminating these agreements with participating members.

11.7 Digital guardianship

Several times in this chapter, we have touched on the special importance of digital guardianship. Although there are certainly technical aspects of implementing guardianship, those pale in comparison to the governance aspects: i.e., the legal, business, and social policies that apply to digital guardians and their duties to dependents. The reasons should be apparent from the following definition of guardianship taken from section 2 of the Sovrin Governance Framework (https://sovrin.org/wp-content/uploads/Sovrin-Governance-Framework-V2-Master-Document-V2.pdf):

Guardianship

An Individual who does not have the capability to directly control that Individual’s Identity Data (a Dependent) shall have the right to appoint another Identity Controller who has that capability (an Independent or an Organization) to serve as that Dependent’s Guardian. If a Dependent does not have the capability to directly appoint a Guardian, the Dependent shall still have the right to have a Guardian appointed to act on the Dependent’s behalf. A Dependent has the right to become an Independent by claiming full control of the Dependent’s Identity Data. A Guardian has the obligation to promptly assist in this process provided the Dependent can demonstrate that the Dependent has the necessary capabilities. Guardianship shall not be confused with Delegation or Impersonation. Guardianship under the Sovrin Governance Framework should be mapped in the proper contexts to various legal constructs, including legal guardianship, power of attorney, conservatorship, living trusts, and so on.

In short, with guardianship, there is ultimately no technical mechanism to prevent the dependent from being taken advantage of or impersonated by the guardian. It is a reflection of the same level of vulnerability in real-world guardianship.

note As discussed in the previous section, governance frameworks designed for digital guardianship are in a special class because they define the obligations of guardians as information fiduciaries. This is a new and rapidly expanding area of the law. For more information, we recommend the Electronic Freedom Foundation (EFF) page on the topic and the foundational 2015 paper “Information Fiduciaries and the First Amendment” by Jack M. Balkin, Knight professor of constitutional law and the First Amendment at Yale Law School (https://lawreview.law.ucdavis.edu/issues/49/4/Lecture/49 -4_Balkin.pdf).

This is why guardianship is a special case when it comes to governance frameworks—and likely will lead to governance frameworks specialized for this purpose. Some may be directly from governments, others from international NGOs like the Red Cross or the World Bank ID4D project, and still others from specialized NGOs devoted to problems like refugees, human trafficking, homeless, dementia, and so on. (For more on this topic, see the Sovrin Foundation white paper “On Guardianship in Self-Sovereign Identity” from the Guardianship Working Group: https://sovrin.org/guardianship.)

11.8 Legal enforcement

Another frequent question about SSI governance frameworks is, “Are they legally enforceable? Or are they just statements about the good intentions of the members of a trust community that have no actual teeth if their policies are violated?”

As we indicated earlier in this chapter, the answer depends on the needs of the trust community and the design of the governance framework. Certainly, if a governance framework specifies legal agreements that create specific contractual obligations for members performing specific roles, it is legally enforceable under contract law just like any other contract. For example, the Sovrin Governance Framework (discussed in the next section) includes legal agreements for three roles:

• Stewards who operate nodes of the Sovrin ledger (https://sovrin.org/wp-con tent/uploads/Sovrin-Steward-Agreement-V2.pdf)

• Transaction authors who write transactions to the ledger (https://sovrin.org/wp -content/uploads/Transaction-Author-Agreement-V2.pdf)

• Transaction endorsers who digitally sign transactions to authorize them (https://sovrin.org/wp-content/uploads/Transaction-Endorser-Agreement-V2.pdf)

After the activation of the EU General Data Protection Regulation (GDPR) in 2018, all three of these agreements had to be carefully revised to account for the regulatory obligations of all three parties as data controllers or data processors. As a result, two more legal agreements were added in the second generation of the Sovrin Governance Framework. (For more information, see the white paper on this topic published by the Sovrin Governance Framework Working Group: https://sovrin.org/data-protection.)

However, whenever it comes to legal enforcement of digital rights, asymmetry of power is a real issue. Between individuals who need to defend their rights and corporations or governments who have transgressed them, who has the greater legal expertise and resources? It’s not a fair fight. In fact, in most cases, it’s not even a fight—because the individual cannot afford to (or is afraid to) enter the ring.

SSI governance frameworks bring new tools to help level this playing field and encourage everyone in the trust community to do the right thing:

• Transparent, community-wide policies—One of the reasons privacy policies have been so ineffective at delivering real privacy is that every site has its own such policy. A 2008 paper by privacy experts Aleecia M. McDonald and Lorrie Faith Cranor estimated it would take the average American internet user over 200 hours to read the privacy policies of all the websites they use—and would cost the U.S. economy $781 billion in lost productivity annually if everyone did so [3]. Well-designed governance frameworks can establish uniform baselines for privacy, security, data protection, and other digital trust policies that apply to all members—increasing confidence across the entire trust community.

• Community monitoring and reputational incentives—For all its flaws, social media has created powerful new incentives for players to maintain good reputations in the market. Well-designed governance frameworks and community-based monitoring and reporting mechanisms can tap this same incentive to motivate their members to play by the rules.

• Collective action—When the first two tools are not enough, governance frameworks can incorporate specific legal support for members taking collective action against violators. As long as the design includes the appropriate safeguards against abuse, this can be an extremely effective disincentive to break the rules.

Some SSI experts believe that the groundwork SSI lays for sharing cryptographically verifiable assertions across trust boundaries will enable so much more effective and scalable reputation systems that legal enforcement of governance frameworks will rarely be needed. We will see if this prediction proves to be true.

11.9 Examples

SSI governance frameworks are at the cutting edge of SSI, so there are not yet many production examples to point to. Table 11.3 summarizes some of the earliest market entrants.

Table 11.3 Examples of SSI-compatible governance frameworks

Example	Description
Sovrin Governance Framework (SGF, https://sovrin.org/governance- framework)	Mentioned several times already in this chapter, this is the most mature governance framework designed explicitly for SSI. The first version was published by the Sovrin Foundation in June 2017, SGF V2 was published in December 2019, and the third generation is now under development by the Sovrin Governance Framework Working Group. It will split the SGF into two ToIP-compatible governance frameworks: the Sovrin Utility Governance Framework and the Sovrin Ecosystem Governance Framework. The SGF is licensed under Creative Commons, so the trust community can use it as the basis for its own governance framework.
Veres One Governance (https://veres.one/network/governance)	Veres One is a hybrid blockchain network that has both permissionless and permissioned aspects. It is governed by a five-party system: the Veres One community group, the board of governors, advisory committees, nodes, and the maintainer.
CCI Governance Framework (https://www.covidcreds.com)	This is a deliverable of the Rules Task Force of the COVID-19 Credential Initiative. The first version was delivered in June 2020, and the second version is currently in development.
Lumedic Health Network Governance Framework (https://www.lumedic.io/ perspectives/introducing-lumedic- connect)	This is the first SSI governance framework designed exclusively for the exchange of VCs for patient-centric healthcare. Announced in November 2020, the first version will be published in Q1 2021.
Pan-Canadian Trust Framework	While not specific to SSI, this is the most mature national governance framework globally, and the latest version was revised specifically to incorporate the key architectural design principles of SSI. For the full story, see chapter 23.

We expect the number of SSI governance frameworks to begin growing rapidly in 2021. A selection of efforts underway that are known to the authors of this book include the following (the ToIP Governance Stack Working Group maintains a list of SSI- and ToIP-based governance frameworks as they come onto the market):

• ToIP Layer 1 networks in Finland (https://www.findy.fi), Germany (https://www.snet.tu-berlin.de/menue/projects/ssi4de), and Canada (https:// canacred.ca)

• National SSI governance frameworks underway in the EU—the Europe Self-Sovereign Identity Framework (https://www.eesc.europa.eu/sites/default/files/files/1._panel_-_daniel_du_seuil.pdf) and eSSIF-Lab (https://essif-lab.eu) and New Zealand (https://www.digital.govt.nz/digital-government/program mes-and-projects/digital-identity-programme/digital-identity-trust-framework/)

• Ecosystem governance frameworks are under development by the Global Legal Entity Identifier Foundation (GLEIF, https://wiki.trustoverip.org/download/attachments/66630/Accelerating-Digital-Identity-with-the%20LEI_ToIP-Ecosys tem-Foundry_WG_v1.0_final%20.pdf) for organizational identity and by GS1 for global supply chain

Note that many other blockchain-related projects have governance frameworks that are also looking to incorporate SSI. Examples include the Enterprise Ethereum Alliance (EEA, https://entethalliance.org) and the Corda Network (https://corda .network/governance/governance-guidelines).

There are only a few good examples of SSI governance frameworks as of the publication of this book, but many more are on the way.

SSI Resources For more free content to learn about SSI, please go to IdentityBook.info and SSI Meetup.org/book.

References

1. Windley, Phil. 2018. “Decentralized Governance in Sovrin.” Technometria. https://www.windley .com/archives/2018/02/decentralized_governance_in_sovrin.shtml.

2. Van Deventer, Oskar. 2019. “Self-Sovereign Identity - The Good, the Bad and the Ugly.” TNO. https://blockchain.tno.nl/blog/self-sovereign-identity-the-good-the-bad-and-the-ugly.

3. McDonald, Aleecia M. and Lorrie Faith Cranor. 2008. I/S: A Journal of Law and Policy for the Information Society 4 (3): 543-568. https://kb.osu.edu/handle/1811/72839.