[WG-TFMM] [WG-IDAssurance] Trust Federation Frameworks and Assurance Metrics
Kenneth.Dagg at tbs-sct.gc.ca
Kenneth.Dagg at tbs-sct.gc.ca
Thu May 12 08:11:26 EDT 2011
I like the concept that is emerging. Unfortunately circumstances have been such that I have not been able to keep up with recent discussions in this area so I apologize if I am reinventing anything.
I believe that using a small number of (3 or as we continue the analysis maybe a couple of more) vectors such as you are proposing will provide a relying party with a better level of confidence that they can trust the asserting party than a single number such as the Level of Assurance. Or, at least they will provide an explanation for the single number.
In addition, this small number of vectors will enable a Trust Framework Provider to assess the strength of another Trust Framework and arrive at a conclusion that they should be able to trust assertions made by Asserting Parties in the other framework.
I have been following a similar approach in defining the GC trust framework and look forward to aligning my work with what you will be proposing. I currently have five vectors that build upon the work that Jeff Stollman did earlier this year. While the details are slightly different the concept is the same. I am intrigued by the Relative Virtue and Capability Maturity vectors you mentioned. I also believe that I can see how the vectors you are proposing could be used to categorize the criteria in the SAC.
I look forward to seeing the model that you will propose.
Senior Project Co-ordinator | Coordonnateur de projet supérieur
Security and Identity Management | Sécurité et gestion des identités
Chief Information Officer Branch | Direction du dirigeant principal de l'information
Treasury Board of Canada Secretariat | Secrétariat du Conseil du Trésor du Canada
Ottawa, Canada K1A 0R5
Kenneth.Dagg at tbs-sct.gc.ca
Telephone | Téléphone 613-957-7041 / Facsimile | Télécopieur 613-954-6642 / Teletypewriter | Téléimprimeur 613-957-9090
Government of Canada | Gouvernement du Canada
From: wg-idassurance-bounces at kantarainitiative.org [mailto:wg-idassurance-bounces at kantarainitiative.org] On Behalf Of Rainer Hörbe
Sent: May 11, 2011 6:15 PM
To: TFMM WG
Cc: UMA WG WG; IA WG; P3 WG
Subject: [WG-IDAssurance] Trust Federation Frameworks and Assurance Metrics
We discussed how to use Assurance Levels several times in the last months, most recently on [WG-P3] Anna Slomovic's Follow up thread (RE: IAWG P3 Agendas going into Berlin) around May 9. I think that we need a clear model of assurance metrics to proceed on this topic and would like to outline some thoughts on such a model:
The positions are that Levels of Assurance (of identity, authentication, privacy, user control, session protection, service level etc.) shall be simple to use and provide comprehensive information on the safeguards that the assuring actor implemented to satisfy the relying actor. These two requirements are obviously in opposition. Simple use is afforded with a single scale (like 1-4), whereas a comprehensive policy is more like the SAML Authentication Context with 50 elements, end even that does not cover all areas.
What are the basic requirements?
Assurance metrics provide the relying actor with the assurance that its protection requirements are fulfilled with a mutually understood minimum quality level. The assurance has to be communicated in a structured form with some granularity. The key question is the granularity. Do we have to provide a fat list in the size of the ISO 27002 paper, or a single number that covers everything from information security to privacy?
I suggest taking the field of consumer reports as a reference. If Stiftung Warentest (the main tester in Europe) compares products or services, the do that in roughly 4 steps:
a) Description of the subject field in general, with the key expectations and state-of-the-art solutions, plus lessons learned from former tests. Rationale why the subject field was limited to a certain range of products.
b) Product by product textual review highlighting special features that would not be easily conveyed in a formally structured table.
c) Structured comparison as a large table containing the relevant properties.
d) Summary rating according to some predefined weighting scheme.
Assuming that a test would compare digital cameras, one could study the comparison in detail to come to informed decision, applying different weights to usability, durability, picture quality, zoom range etc. Or one could use the score "very good" printed on the box when purchasing a camera ad hoc, without unbiased consulting at hand.
I derive from consumer reports that both approaches are meaningful and two audiences should be addressed. An enterprise risk manager would most probably see a detailed set of assurances to protect valuable assets, whereas a typical SOHO user would like to get away with a 3 second attention span on the security and privacy topic and would therefore be served better with a simple scale.
To achieve interoperability most controls are already aggregated, mixing apples and oranges. Take the well-known encryption strength: Looking at Ecrypt's yearly report on key sizes on learns quickly, that the "128 bit equivalent" in composed of symmetric and asymmetric key lengths, hash functions, padding, protection duration and more. The same is true for many other controls. It will be the challenge of each trust framework to find the adequate level of granularity for each control, which balances control with flexibility and interoperability.
Further aspects: When controls are implemented to fulfill a protection requirement the controls can be measures along 3 generic vectors:
a) Relative virtue compared to the state of the art (e.g. optional data minimization is weaker than a mandatory one)
b) Strength of enforcement (contractual, by law, technically, with or without audit, ..)
c) Capability maturity of the asserting actor (ad hoc, controlled, improving processes)
I would like to describe such a model in the TFMM if your feedback is agreeable :-)
More information about the WG-TFMM