[WG-UMA] [WG-IDAssurance] [WG-P3] Trust Federation Frameworks andAssurance Metrics

Charles Andres andres.charles at gmail.com
Sun May 15 08:31:05 EDT 2011


I assume the all-important parameters comprising 'context' are part of the environment data set? To apply the appropriate privacy mask/filter, context for each transaction is key.

Sent from my iPhone

On May 15, 2011, at 8:09 AM, j stollman <stollman.j at gmail.com> wrote:

> Rainer, et al,
> 
> I have been inspired to devote a bit more time to this by your note.
> 
> First, I am inspired by two key points made in your opening:  the separation of identity from authentication and the specification of "session protection."  As we all know, the current NIST Levels of Assurance combine Identity and Authentication.  This has always made me uncomfortable because the two concepts are so distinct.  Of course, they know this; they just wanted to get to a single metric.
> In my own model, I have expanded "session protection" to "environment."  This expansion allows coverage not only of endpoint and network security and integrity in an electronic transaction, but can also be applied to face-to-face transactions.  For example, you and I might agree that I will pay you $10000 for a ruby you own, but we may be unwilling to conduct such a transaction in a public place in a bad neighborhood.
> 
> Second, I favor your idea of providing both summary metrics and detailed backup material for those who desire to apply different weights to the evaluation criteria.  Critical to the summary metrics would be a lengthy discussion of how/why the weightings were chosen.  While this would necessarily be somewhat lengthy, it would only need to be read once and could be applied to large groups of related transactions.  
> I also agree with Ken that even with this simplification, I doubt we will get to a single number.  It is too pedagogical.  Like Stiftung Warentest, Consumer Reports in North America (ConsumerReports.org) uses this approach.  But they may use 4-10 scores to rate different types of products.  They then give a prioritized listing of products, but never refine their ratings to a single number.  The population's tastes are too varied to apply a single prescription.
> 
> I would take a slightly different perspective to Anna's comment, "Privacy ... is usually more important to the data subject."  I am not sure that this is quite accurate.  The typical issue is that the data subject has more information "at risk" than do the other parties.  In large part, this is because the other parties typically control the transaction.  Frequently, I am intrigued by an offer I receive, but seek more information on the offeror. But, in the one-way direction of control of typical transactions, I am unable to obtain more information.  My only choice is to transact or not.
> 
> A agree with Anna's contention that different weights are likely to apply to different those in different roles in a transaction.  The number of roles required to conduct the broad range of transactions within the scope of federated trust frameworks continues to grow.  And as it grows, the number of perspectives expands also.
> 
> It if for this reason, that I continue to focus on the alternative model for Trust Frameworks that I proposed back in March.  The current model is based on roles.  I proposed a model based on trust relationships.  Ultimately, I am just transposing rows and columns in a matrix of roles versus trust relationships.  I contend that there is a fixed and manageable number of trust vectors that exist between any two parties -- regardless of their role.  (Though, I also agree the the weighting will change depending on the role of the party or the environment of the transaction.  I.e., though I trust my best friend to look out for my interests, I may not trust him to do so if his life is being threatened.)
> 
> In my previous proposal I suggested that there need to be at least four trust relationships:  Identity, Terms, Subsidiary Rights, and Enforcement.  Based on this thread, I have added Environment to include both session integrity as well as such factors such as having one's actions compromised by threats or pressure.
> 
> In this model, all transactions are 1:1.  A particular transaction (e..g, buying a widget from an online vendor) may require multiple 1:1 component transactions (between subject and vendor, between subject and credit card company, between credit card company and vendor, etc.).  Each transaction still has the same complexity (i.e. number of cells in the matrix).  But each transaction can be evaluated using the same criteria (though the weightings applied may well change for each role pairing).  The simplification this model brings is that only five scores need to be created that can then be re-weighted as needed for each component transaction.  
> 
> Jeff
> 
> On Fri, May 13, 2011 at 11:13 AM, Faut, Nathan E <nfaut at kpmg.com> wrote:
> All –
> 
>  
> 
> I am sure some of you have seen this, and some may have not.  The following white paper was written for a conference for a predecessor to Kantara.  I think it has some strong bearing on this discussion.  Please pass it along to any and all interested parties.
> 
>  
> 
> The authors welcome any interest!
> 
>  
> 
> -Nathan 
> =-=-=-=-=-=-=-=- 
> Nathan Faut
> 
> 1676 International Drive
> 
> Suite 1200
> Mclean, VA 22102
> 
> office: 703-286-6883
> 
> at PBGC: 202-326-4000 ext. 3845
> 
> mobile: 301-335-2656
> 
> FAX: 202-403-3126
> 
>  
> 
> From: Colin Wallis [mailto:colin_wallis at hotmail.com] 
> Sent: Thursday, May 12, 2011 3:27 AM
> To: Rainer Hoerbe; wg-tfmm at kantarainitiative.org
> Cc: wg-uma at kantarainitiative.org; wg-idassurance at kantarainitiative.org; Kantara P3 WG
> Subject: Re: [WG-IDAssurance] [WG-P3] Trust Federation Frameworks andAssurance Metrics
> 
>  
> 
> 
> <<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)>>
>  
> Yes, I like this approqach.
> It is similar to the approach that the CSA is proposing for assuring cloud providers in terms of ISO 27001 compliance.
> Sure, the control set is complex there, but they do offer a summary matrix, which is closer to Rainer's view for end user/consumer/SOHO folks as he described above.
>  
> Cheers
> Colin
>  
> 
> From: rainer at hoerbe.at
> Date: Thu, 12 May 2011 00:14:57 +0200
> To: wg-tfmm at kantarainitiative.org
> CC: wg-uma at kantarainitiative.org; wg-idassurance at kantarainitiative.org; wg-p3 at kantarainitiative.org
> Subject: [WG-P3] 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 :-)
> 
>  
> 
> - Rainer
> 
> 
> _______________________________________________ WG-P3 mailing list WG-P3 at kantarainitiative.org http://kantarainitiative.org/mailman/listinfo/wg-p3
> 
> 
> ***********************************************************************
> 
> 
> The information in this email is confidential and may be legally privileged.
> It is intended solely for the addressee. Access to this email by anyone else is
> unauthorized. If you are not the intended recipient, any disclosure, copying,
> distribution or any action taken or omitted to be taken in reliance on it, is
> prohibited and may be unlawful. When addressed to our clients any opinions or
> advice contained in this email are subject to the terms and conditions
> expressed in the governing KPMG client engagement letter.
> 
> 
> ***********************************************************************
> 
> 
> 
> 
> 
> 
> _______________________________________________
> WG-IDAssurance mailing list
> WG-IDAssurance at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
> 
> 
> 
> 
> -- 
> Jeff Stollman
> stollman.j at gmail.com
> 1 202.683.8699
> _______________________________________________
> WG-UMA mailing list
> WG-UMA at kantarainitiative.org
> http://kantarainitiative.org/mailman/listinfo/wg-uma
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-uma/attachments/20110515/ef76ab97/attachment-0001.html 


More information about the WG-UMA mailing list