What is a Trust Federation?

Start reading the figure above clockwise from top left:

Trust Federations provide secure electronic communication a network of independent parties. High-level use cases are described in the TF Constellations document.
The business purpose is to provide service consumers access to service providers (or sometime peer-to-peer access) using trusted third parties.
Trust Federations are based on Trust Frameworks that provide legal and technical interoperability.
Trust Federations define security objectives that need to be fulfilled to make electronic communication trustworthy, mostly centered around identity assurance.
For this Purpose the parties are legally bound by the Trust Framework.
See also the more detail topic map

As defined in the TF Constellations document the purpose of a Trust Framework is seen rather wide, covering technical and legal concerns and various types of business transactions, including on-line services, document transfer, network services and electronic verification of physical access.

What is a Trust Framework?

The term seems to be widely used for various agreements that govern a federation. The definition here is not anticipating a more profound analysis, but wants to give approximate delimitation of the scope. For the purpose of this context the meta model is more a kind of process driven by the demands of various domains and projects, rather than a fixed deliverable.

Definition: In electronic communication, a trust framework (TF) is a complete set of contracts, regulations or commitments that enables parties of a Trust Federation to rely on certain assertions by other actors to fulfill their information security and privacy requirements. These requirements are for example:

Confidence in the link of a digital identity credential to a real-world identity (Authenticity)
Compliance with security objectives for integrity, confidentiality and accountability of the communication
Adherence to the privacy policy of the data controller
Fulfillment of a defined service level (short- and long-term availability)
User control over own data (like availability for export in an open format)

A TF can be general or specific, ie. a template for or an instance of a federation contract.

A TF may consist of several domain-specific frameworks, like entity authentication assertion and privacy.

A trust framework defines obligations for various actors, like identity provider, attribute provider, service provider, subscriber, subject, federation operator, policy management authority, auditor, registration authority, and verifier. An obligation of an asserting actor to a relying actor constructs a trust relationship between these actors. Caveat: The term Relying Party is used in Kantara, Identity Commons and other communities as a synonym for a service provider and implies that the service provider is the only actor trusting the other parties. That is, however, only the case in a specific constellation (see Service Provider centric model ). In other scenarios other parties need to have trust relationships as well. This is why in the view of the TF any actor can be a Relying Actor.

Alternative bearings of "Trust Framework":

Rule set: A set of standards and rules used to build a contract and run a certification program.
Contract: A contract, other written form of commitment or some legislation to have a legal binding for a federation
Template: A generic set of rules to craft the set of rules for a specific trust federation. It is not an instance of a contract.
Instance of Template: The specific set of rules that is effective for a trust federation
Conformance: A certification program that accredits the conformance of a federation-specific rule set to the "template" using a defined procedure

Trust Framework Meta Model (TFMM)

The objective of the TFMM is to define a model that can help with an analysis of existing frameworks and improve their interoperability.

Scope and Goal

The Meta Model shall encompass Trust Frameworks as defined above.

The purpose is to:

Assess policies, question if their scope is well defined;
Perform a gap analysis between a specific policy and the common superset;
Provide a statistical analysis about the granularity of a policy, to gibt hints for under- or over-specification:
Support the mapping of different policies;
Foster the standardization of controls in federations to promote automated contract negotiation;
Create a reference model for the development of public policies in this field.

Existing frameworks

There are several frameworks that provide a certain part of a TF, like the entity authentication assertion (EAA) frameworks

OMB M-04-04/NIST 800-63,
Kantara IAF,
ISO 29115,
STORK QAA, or
PKI-based policies like the IGTF.

Given the definition of a TF an EAA-framework is only a subset of a TF, and it needs to be supplemented in other areas such as privacy, user control, general information security and service levels.

(I am not informed about relevant frameworks: P3G, UMA, NSTIC, .. – need help)

Related Efforts

ABA: Tom Smedinghoff and Scott David are working on aligning the term Trust Framework used in different domains.

P3WG is working on a Privacy Framework, currently with the scope limited to PII used for identity verification and authentication.

UMA is working on a Trust Framework for user managed access.

IAWG is expanding the IAF with a Relying Party Guideline to cover the release of PII (subject attributes) to Relying Parties

ISO SC27/WG5 is working on an Entity Authentication Assurance Framework in ISO 29115

ITU-T is starting an effort to define Open Identity Trust Framework (x.oitf)

Interoperability

To make systems using different policies based on various frameworks interoperable the frameworks need to be mapped. However, that is not trivial for several reasons:

Different terminology, sometimes semantically inconsistent
Requirements and measures are mixed up (and are sometimes difficult to segregate)
Requirements are not isolated, like (A and B and C) or (A and C and D). So one cannot map each requirement, only combinations, which is more complex and less likely to map. This a challenge with identity proofing processes.

The model shall clarify the relevant requirements and measures to facilitate the mapping. In the long term automated policy negotiation across federations (and even jurisdictions) shall be possible.

Delimitation

The IAF (and possibly other frameworks) should be assessed against a TF architectural model to avoid overlapping and gaps.

A proper criterion shall be established to classify requirements and measures for a suitable delimitation of domain frameworks.

Completeness

The set of requirements provides the means to analyze if the IAF (an possibly other frameworks) is complete within its scope.

As actors of electronic communication need complete trust frameworks to operate, the model shall define a complete set of trust categories to allow a gap analysis of the domain-specific frameworks.

Approach

The scope of the model is explained using the definition of a TF above and the definition of Federation constellations in Identity Federation Constellations and Use Case Overview.

Criterion for Delimitation

The initial proposal for the criterion to group requirements is the trust relationship between relying and asserting actor, as described in Scope comparison of Identity vs. Trust Federation .

If that criterion were adopted, then a domain-specific framework would exactly describe a defined set of trust relationships. In the case of the IAF that would be:

SP to IdP

SP to FO

SP to AP

Implied: IdP to subscriber

Implied: subscriber to subject

Requirements and Measures

I propose to build on the Common Model for Multi-Level Security (CMMLS) that I developed last October. It is a database that

classifies protection requirements using trust relationships;

assigns controls per protection requirements to assurance levels;

maps and compares controls per framework.

The model is a draft and can be seen at: http://cmmls.portalverbund.at/cmmls/index.jsp