I’ve been having long email discussions over the last month or so about the nature of “Trust Frameworks”. “Trust Framework” is one of those terms that everyone loves to use in the Federated Identity world, but when asked, are hard pressed to come up with a reasonable explanation of what they are and how they work. Equally puzzling is the difficulty in discerning a difference between a Trust Framework and Federated Identity agreements.

There are a few characterizations that I like, especially the American Bar Association Identity Task Force one that a Trust Framework is a set of Operating Rules that include Technical, Business and Legal rules.

I am currently working on a set of white papers that dig into this topic for the Kantara Initiative Identity Assurance Working Group (KI IAWG)

The questions under examination are:

Does the Kantara Identity Assurance Framework (KI IAF) address the needs of service providers seeking Approval under the Kantara Trust Framework?

If not, then what could or should be changed in the Assessment Scheme, the Service Assessment Criteria or Rules of Assessment that would make the KI IAF more flexible or modular in ways that still make sense for Trusted Identity Federations.

Along the way, I have been sidetracked to learn more about Trust Frameworks, Identity Federations and Federated Access Control patterns and architectures. I’ll be sharing bits and pieces of this over the next few blog posts.

But for now, I’ll leave you with a crappy diagram. This diagram is a hypothetical representation of the relationship between the Kantara IAF, Federated Identity models and the assessment criteria that are derived from the underlying models. The premise is: there exist many Federated Identity models. For each model, a set of assessment criteria can be developed. If a service provider demonstrates  conformity to the criteria, then it adheres that that model. It may be possible to describe a “Root” or “Core” model with “Root” or “Core” assessment criteria which form a part of every other model and criteria in that family tree of Federated Identity Models.

In this discussion, it is important to remember that there is more than one way to model Federated Identity. In the circles that I travel at the moment, the US E-Authentication Program (OMB M-04-04 and NIST SP 800-63-2) and the Government of Canada Identity Management models are prevalent. These share common elements such as having 4 Assurance Levels and have differences such as the assignment of functional roles to IDP or RP. However, it is quite simple to describe a common root model with distinct model options and assessment criteria profiles that encompasses both.

Hypothetical relationship between Federated Identity Model and Trust Framework