Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

What is a Trust Framework?

In electronic communication, a trust framework (TF) is a complete set of contracts, regulations or commitments that enable participating actors to rely on certain assertions by other actors to fulfill their information security requirements. Information security requirements are for example:

  • Confidence in the link of a digital identity credential to a real-world identity (Authenticity)
  • Compliance with safeguards for integrity, confidentiality and non-repudiation 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 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.

Purpose

The objective of the TF architecture is to define a model that can improve existing frameworks and their interoperability.

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)

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

  • No labels