A trust model with third party assurance

1. Trust between autonomous organizations

Trusted interaction between identifiable parties has been a problem that predates the current Internet. But the solutions from the mainframe area do not scale with today’s demands. Trust needs to be moved to an infrastructure layer that can be utilized by applications as a commodity. In electronic communication the key issues are to assure that the other party is who they claim to be, and to assure that their actual and expected behavior match closely.

2. Making networks scalable: How to deal with complexity

All kinds of networks need to move beyond one to one relationships between their participants if the number of participants grows, because members are limited in handling the complexity of many unique relationships. Three approaches are the most common patterns to deal with this complexity:

First, a participant with a large number of relationships creates a standard to be able to handle them easily. Typically it is the single dominant player in that market who will enforce Terms of Use and interfaces on less powerful parties. This concept helps one player, but is of little benefit to the other parties. And it is limited to some type of business and does not work well in competitive markets. An example was American Airline’s SABRE booking system before the deregulation.

Second, the government might provide legislation and governance instead of contracts. This is common in areas than concern safety, such as in the health sector or air traffic control, or are those that are very general, such as commerce.

Third, the market participants can decide to cooperate in a federated structure. This can be seen in areas like payments or airlines, which developed credit card associations and IATA. Associations provide the necessary legal and technical infrastructure to manage the legal, operational and technical aspects of relationships within the federation.

The Internet today is lacking an infrastructure that assures trusted interaction between identifiableactors beyond specialized islands. OIX’ architecture for such an infrastructure is based on the third pattern and promotes an open market model with a global, cross-industry reach.

3. Evolution of Cooperation models

It usually requires a legal framework, operational rules and technical standards. A Legal Framework defines the duties for participants in a federation with contracts or law. It should, however, not specify technical, operation and governance rules.

Common Operating Rules (COR)set the technical, operation and governance rules for participants in a federation. Depending on the economic and technical structures four basic constellations evolved:

  • Bilateral model: 2 parties enter into a contract. This is well known and flexible, but scales very poorly if it extends beyond the most trivial set of rules.
  • Centralized model: One party defines the rules and others subscribe.
  • Consortium model:A small number of founders form a consortium via a multi-party contract that sets the COR.
  • Collaborative model:A group of founders forms an entity that establishes the COR. Parties have some proportional representation in that entity.

Fig. 1Scalability of cooperation models

The resulting group of parties in these models is called a circle of trust, although a strange circle in the case of the bilateral model. These models can be enhanced by the Third Party Assurance Model:Parties in the federation work with a third party certification authority to attain accreditation of their compliance with the COR.


Trust Framework is a general term used to summarize the legal, operational and technical duties of parties in a circle of trust.

4. The need for Trust Frameworks

Trust Frameworks govern federations. To understand the federated trust model it is helpful to look first at the basic 1:1 trust relationship. In this model Alice can be either a service consumer (user) who entrusts her private data to Bob, or a service provider who grants access to Bob based on his identity and entitlements.


Fig. 2: Alice directly trusts Bob

4.1. Why Alice can trust Bob

Alice’s reliance on Bob’s compliant behavior is based on two factors: Control and her perceived trustworthiness of Bob. Her trust into the context can be considered as a third factor, but this can be taken as a constant unless Bob is form a foreign context or jurisdiction.

Bob’s compliance with contract, convention and law is driven by two main factors: Assurance to improve his competence, and potential legal or Alice’s personal consequences to encourage his willingness.

Control is a cognitive process based on knowledge and proof, requiring skill and effort. Perceived trustworthiness is an intuitive evaluation of other, rather soft evidence within the common social and legal context. Usually a balanced mix of both is appropriate, but even if Alice would be paranoid she could almost rely on control alone if she had the capacity to probe Bob’s operation.

4.2. Why the model of direct control does not scale

The model breaks if Alice has to deal with many different relationships because the complexity would exceed her intellectual horizon or administrative capacity in case Alice would be an organization. It is evident that most end users are incapable of handling different schemes for privacy, authentication and device security; Enterprises fail to align multiple external IT security policies with their internal Information Security Management System.

How can complexity be handled? The intuitive human approach is to handle trust intuitively. That does work quite well in long-lasting relationships, but is difficult to measure and manage, and vulnerable to aimed attacks. For practical purposes in the Internet an adequate amount of control is indispensible. Another approach would be to avoid additional complexity, but that comes at the cost of not utilizing new services, partners, cooperation, local intelligence and other opportunities. The third option is to turn to trust service providers who have a neutral position in relation to Alice and Bob and provide standardized assurance to exploit economics of scale.

4.3.The model of delegated control and assurance

3rd party trust model


Fig. 3Alice delegates control; Trust is brought to an infrastructure level

Alice wants to deal with many Bobs, but handle trust in a uniform way. The Trust Framework that Truman provides replaces the contract and conventions that Alice and Bob had in the 1:1 model. It enables a trust infrastructure for business cases with homogenous requirements, such as specific industries. However, it does not yet scale on a global, cross-industry scope. E.g., if Bob would be a supplier for devices to customers in automotive, aerospace, government and health that have their own trust frameworks, any incompatibility between these Trust Frameworks would cause complex mapping exercises that could turn out to be infeasible if governance is taken seriously.

5. Interoperable Trust Frameworks

To attain interoperability between trust frameworks from different sectors that allows parties to engage into trust relationships in a large scale, Trust Frameworks need to be provided as computational contracts. Then Alice, Bob and other parties can automatically negotiate their trust relationships.

A Trust Framework Meta Model and aids Trust Frameworks in terminology mapping, scope definition, assertion criteria and gap analysis.

Fig. 5Interoperable Trust Frameworks across sectors