16 THE GOVERNANCE OF THE TRUST FRAMEWORK
16.1 Creation and Management of a Trust Framework
Someone (a person, an entity, a group, or a committee) must be charged with the task of writing the Trust Framework, and someone (not necessarily the same person or group) should be assigned responsibility thereafter for updating and maintaining it as necessary to meet future needs.
The authorship and control over the content of a Trust Framework is often a function of the nature and structure of the Trust Framework implementation itself. In some cases, this may be assigned to the legal entity establishing the framework, or a separate legal entity charged with the task of managing it. In other cases, a trust framework may be written by a consortium of participating entities that mutually agree on rules and regulations, or by a committee of participants elected to oversee accountability and governance.
Common examples of possible authors for a Trust Framework include the following:
- Independent Governing Entity: For some Trust Frameworks, an independent entity may be formed or designated for the specific purpose of developing, maintaining, and enforcing an appropriate trust framework. This typically occurs in the case of a large-scale identity system that includes numerous Identity Providers and Relying Parties. Such an entity is commonly referred to as a Trust Framework provider, operator or authority. An example is the Digital ID and Authentication Council of Canada (DIACC) a non-profit coalition of public and private sector leaders. DIACC defines and manages the Pan-Canadian trust framework.
- Consortium of Participating Entities: In other cases, a group consisting of some, but not necessarily all, of the participating entities will convene to draft, and update as needed, the appropriate Trust Framework. An example of this is provided by the CA/Browser Forum, which consists of a group of browser vendors and certification authorities that jointly agrees upon the trust framework for a system focused on recognition of trust roots for website server and related domain name owner identification.
- Single Participant Governing Entity: In some cases, a single existing organization (typically an entity acting as either the sole Identity Provider or the sole relying organization) both establishes the Trust Framework and acts as a participant for its own specific purposes. As the strong central entity, it dictates the architecture, policies and contractual structure of the trust framework, and may also manage and operate a technical platform, which supports the interactions among the participants. Examples include single Identity Provider systems, such as those operated by Google and Facebook, and single Relying Party systems, such as those operated by the US governmentâs Login.gov program or the UK governmentâs GOV.UK Verify program.
- Non-Governing Standards or Certification Organization: In some cases, an independent entity may be established to develop (and update from time-to-time) standard rules for a Trust Framework , but such entity will not itself actually govern the operation of a framework. It may, however, certify participants (particularly Identity Providers) as compliant with its system rules. Examples of this approach include the identity assurance Framework issued by the Kantara Initiative, and the tScheme Approval profiles issued by tScheme.
- Mutual Agreement Among All Participants: In smaller scale Trust Framework, system rules can be jointly negotiated by the participants (or written by a dominant participant), and memorialized in a mutual agreement. In such case there is no separate governing entity, but simply an agreement between and among all of the participants.
16.2 Enforceability of a Trust Framework
A Trust Framework is of no value unless the participants in the identity system that it purports to govern are legally obligated to follow the rules set out in the trust framework â i.e., it must be enforceable
In some cases, the rules of the Trust Framework can be made binding by law or regulation. Likewise, depending on the technologies and procedures specified by the Trust Framework, policies may also be enforced by systems, software and applications. But in most cases, the rules of a trust framework are private law that can be made enforceable only by voluntary agreement of the parties.
Thus, once a Trust Framework is written, a key challenge is establishing a mechanism to ensure that all participants within the scope of its rules are legally bound in a manner that makes the portion of the rules relevant to their role enforceable against them. And ideally, each participant should be legally obligated to follow the rules of the framework for the benefit of all other affected participants in the framework (including the end users) even though each participant will not enter into a separate contract directly with all such other participants. This is usually accomplished as follows:
- In the case of the private sector, the governing trust framework is usually made enforceable by some sort of contractual mechanism. Many approaches can be used, although one of the more common approaches is to develop a master set of framework rules (set out in one or more documents), which all parties agree to through the use of a simple form contract that references or incorporates the rules by reference.
- In the case of government sector or government-sponsored frameworks, the governing trust framework may take the form of a statute or regulation. In such cases, the terms of the trust framework are binding on the participants by law.
- Trust frameworks for public-private partnerships might rely on a contract-based approach, or a hybrid form might be used, where the foundation and main principles are based in law, but certain specific role-related requirements are enforceable through agreements.
In some cases, trust frameworks are not made legally binding on certain roles, such as end users or credential issuers, although the trust framework may regulate the conduct and responsibilities of other participants relative to those roles. For example, in some cases users do not contractually agree to the terms of the trust framework itself. However, the trust framework may impose on Identity Providers an obligation to enter into a contract with such users that contains certain terms or imposes certain requirements.
16.3 Certification to a Trust Framework
Participating entities in the framework may need to be certified in some way to demonstrate that they are compliant with the obligations the framework defines for the role(s) that that participating entity is playing. Types of approval include:
- Self-Assessment. The participating entity self declares compliance with the framework.
- Verified Self-Assessment. An independent body or automated tool verifies the participating entities self-assessment. The independent body is not a formal certification body and takes no liability for that verification.
- Approved. The participating entity demonstrates how it meets the requirements of the trust framework through documentation, demonstration and inspection by an independent body.
- Certified. The participating entity demonstrates how it meets the requirements of the trust framework through documentation, demonstration and inspection and is formally certified by an independent body.
The type of approval required will depend on what level of regulatory compliance, and protection against fraud and financial risk, the framework is offering the user and Relying Party.
16.4 Operation of a Trust Framework
The need for one or more operational roles depends on the complexity and maturity of the trust framework implementation.
At a minimum, someone must be responsible for developing and maintaining the trust framework itself, and amending it when changes are required, or new issues arise.
In more complex frameworks, with a large network and many types of participating entities offering many different services, there may also be a need to provide for additional governing roles to address a variety of other governing functions, such as:
- Governance and Policy Development: Developing and amending legislation; policies; decision- making; stakeholder-facilitation; managing standards and procedures; accountability mechanisms.
- Policy Enforcement: Ensuring compliance with existing policies; enforcement mechanisms; performing assessments or audits; managing changes and releases.
- Participating Entity Management: Administration and enrolment of participating entities; Certification and trust marks; support; dispute resolution; billing.
- Network Evolvement: Growing and supporting the network; marketing; communication and; developing strategy.
- Trust Framework Operations: Offering central services to the participating entities and/or public, e.g. fraud management, information and discovery services.
In many cases these functions can be addressed by a designated separate legal entity (like Visa, Inc. does for the Visa credit card system). In other cases, a cooperative consortium might fill one or more of the governing roles or a committee established by the participating entities.
The roles tasked with performing these functions are sometimes referred to as a Trust Framework Provider, Trust Framework Authority, Policy Authority, or Trust Framework Operator (depending on their specific functions).
17 THE LEGAL CONTEXT OF AN IDENTITY TRUST FRAMEWORK
The role of a Trust Framework in the overall legal framework for identity is much like the role of a sales contract in the overall legal framework governing the sales of goods. That is, it is written to address the specific issues of a particular identity system, but is also subject to, and governed by, more general higher-level law.
Identity systems and identity transactions, like most commercial systems and commercial transactions, are typically governed by up to three levels of different legal rules. These legal rules may be generally described as follows:
- Level 1 - General Law: The first (and foundational) level of legal rules applicable to identity systems and transactions is existing general law. This consists of the rules enacted as statutes by legislatures, adopted as regulations by government agencies, or determined by judicial decision. Such law was not written for identity systems, but is frequently applied to them to the extent it relates generally to the activities that take place within the identity system. General law includes contract law, tort law, privacy law, export control law, warranty law, consumer protection law, antitrust law, and the like. Such law is public law (i.e., written by governments), applies to all identity systems and their participants by the authority of the government, and is enforceable in the courts. Unfortunately, because it is not written for identity systems, it may not be a good fit, or may yield unanticipated or inappropriate results.
- Level 2 â Identity Management Law: The second level of legal rules applicable to identity ecosystems and transactions consists of identity management law. This law (where it exists) is new, is written specifically to govern all identity systems within its scope, and is designed to address one or more of the specific issues that arise in the context of the operation of such identity systems (e.g., participant liability). Very little such law currently exists, but projects are underway in several jurisdictions to develop such Level 2 law for the purpose of encouraging and/or regulating identity systems and identity transactions. An example of such Level 2 law is the Virginia Electronic Identity Management Act. Level 2 law is also public law, and applies to all identity systems and identity system participants that operate within its scope by the authority of the government, and is enforceable in the courts.
- Level 3 â Trust Framework -- Identity System-Specific Rules: The third level of legal rules applicable is Trust Framework. A trust framework is usually necessary in some form regardless of whether that identity system is operated by a government or a private sector entity. In the case of private sector identity systems (and some public-private identity systems) the trust framework typically takes the form of contract-based rules (i.e., private law) drafted by one or more participants in, or the governing body of, the specific identity system and voluntarily agreed to by the participants. In the case of government operated identity systems, the trust framework typically takes the form of statutes or regulations adopted by the operating government body (most often a countryâs national ID system, or e.g., the eIDAS Regulation in the EU). In either case, however, these framework-specific identity system rules apply only to the specific identity system for which they were written. Thus, there will be many such trust frameworks. Contract-based trust frameworks must, of course, also comply with the governing legal rules in Level 1 and Level 2. In the case of trust frameworks that exist in contract form, they are binding only on those parties that voluntarily agree to the terms of the applicable contracts. If such rules exist as a statute or regulation, they are binding only on those who are expressly within their scope. In either case, such trust frameworks only apply to one particular identity system.
This legal framework is depicted in the diagram below. As this diagram illustrates, portions of the legal framework for any private-sector identity system (i.e., the Level 3 trust framework portion) are under the control of the developers of that identity system, and other portions (i.e., Levels 1 and 2) are outside of their control. That is, the operators of an identity system are free to make up the Level 3 system rules (so long, of course, as the participants contractually agree to be bound by them), but at the same time, the private contracts that make these system rules binding on the participants are supplemented (and in some cases superseded) by existing laws and regulations. As such, the Level 3 system rules must interface with existing law â a challenge made all the more difficult for identity systems that cross jurisdictional boundaries. Moreover, any issues not addressed by the Level 3 trust framework will be determined by the public law at Level 1 (and Level 2 if it exists).