What is a Trust Framework?
The term seems to be widely used for various agreements that govern a federation, may be to pimp the resulting document. For the purpose of this model 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. 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 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)
Tom Smedinghoff and Scott David are working on aligning the term Trust Framework used in different domains. (WG-P3 mailing list - REFERENCE MISSING)
A TF may consist of several domain-specific frameworks, like entity authentication assertion and privacy.
...
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
...
(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:
...
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 .
...
- 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
...