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

j stollman stollman.j at gmail.com
Sun May 15 08:36:49 EDT 2011


Charles,

Perhaps "context" is actually a better term than "environment."  In my view
they should be the same.

Jeff

On Sun, May 15, 2011 at 8:31 AM, Charles Andres <andres.charles at gmail.com>wrote:

> 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>
> 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>
>> colin_wallis at hotmail.com]
>> *Sent:* Thursday, May 12, 2011 3:27 AM
>> *To:* Rainer Hoerbe; <wg-tfmm at kantarainitiative.org>
>> wg-tfmm at kantarainitiative.org
>> *Cc:* <wg-uma at kantarainitiative.org>wg-uma at kantarainitiative.org;
>> <wg-idassurance 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>rainer at hoerbe.at
>> Date: Thu, 12 May 2011 00:14:57 +0200
>> To: <wg-tfmm at kantarainitiative.org>wg-tfmm at kantarainitiative.org
>> CC: <wg-uma at kantarainitiative.org>wg-uma at kantarainitiative.org;
>> <wg-idassurance at kantarainitiative.org>
>> wg-idassurance at kantarainitiative.org; <wg-p3 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>WG-P3 at kantarainitiative.org
>> <http://kantarainitiative.org/mailman/listinfo/wg-p3>
>> 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>
>> WG-IDAssurance at kantarainitiative.org
>>  <http://kantarainitiative.org/mailman/listinfo/wg-idassurance>
>> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
>>
>>
>
>
> --
> Jeff Stollman
> <stollman.j at gmail.com>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
>
>


-- 
Jeff Stollman
stollman.j at gmail.com
1 202.683.8699
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-p3/attachments/20110515/e16d3815/attachment-0001.html 


More information about the WG-P3 mailing list