[WG-TFMM] Trust Framework limited to trust in identities?

Rainer Hörbe rainer at hoerbe.at
Sun May 22 13:22:25 EDT 2011



Am 22.05.2011 um 17:02 schrieb Anna Slomovic/Equifax:

> To Jeff's good analysis I would only add that trying to force Kantsra's Trust Framework on organizations beyond identity is very much like requiring them to adopt a privacy framework. Business and legal requirements determine what organizations do after they receive identity assurance.

I am not sure if I understand you. I was not asking to force a Kantara TF on organizations. Which implications of a privacy framework did you mean?

I do understand that the TF will take time to be build, and more specific solutions need to be implemented in the meantime. My modest request is to have a common vision and definition of Trust Framework respectively trust infrastructure. This should allow better integration into enterprise security frameworks and an approach driven by business needs.

- Rainer 


> 
> Anna 
> 
> 
> 
> Anna Slomovic
> CPO, Equifax
> 
> Sent via DROID on Verizon Wireless
> 
> 
> -----Original message-----
> From: j stollman <stollman.j at gmail.com>
> To: "Rainer Hörbe" <rainer at hoerbe.at>
> Cc: "smedinghoff at wildman.com Smedinghoff" <Smedinghoff at wildman.com>, Mark Lizar <mark at smartspecies.com>, TFMM WG WG <wg-tfmm at kantarainitiative.org>, Wilsher Richard <RGW at zygma.biz>, John Bradley <jbradley at mac.com>, Anna Slomovic/Equifax <anna.slomovic at equifax.com>, Wallis Colin <Colin_wallis at hotmail.com>
> Sent: Sun, May 22, 2011 14:14:14 GMT+00:00
> Subject: Re: Trust Framework limited to trust in identities?
> 
> Rainer,
> 
> The discussion of whether or not trust frameworks should be extended beyond identity may be the wrong argument.  I don't think that anyone can argue with the sound logic and insight conveyed in your response below.  The apparent dispute is really not ontological, however; it is temporal.  
> 
> I think we all will agree with your assertions about the various components of a trust framework and their interrelations.  And I think that we all will agree that this is a complex topic whose exploration is still in its infancy.  
> 
> Kantara was chartered with a focus on identity by organizations whose primary focus was on identity:  mostly large enterprises who sought to ensure that they were delivering their services only to their authorized clients.  Kantara's predecessors shared this more narrow focus on identity.  To adhere to this focus, initial efforts (e.g., the Liberty Alliance IAF) explicitly targeted identity-centric outcomes.  We could argue that this historical focus is "wrong" because it fails to give proper attention to the other elements of a trust framework.  It may look like trying to build an airplane by focusing only on designing wings and expecting to fly.  But, at the same time, several organizations (including federations) have short-term goals that do not require the full construction of a comprehensive trust framework.  They can meet their initial requirements using only wings to build a glider.  A glider is incapable of self-powered flight, but it can fly.  These organizations can meet (and have met!) some short-term objectives that benefit their constituencies without the full capabilities of an airplane.  They recognize the airplane as the desired end result.  But they are content to achieve some short-term benefits with their gliders in the long interim before such time as someone develops engines, control systems, and airports to support the more varied and nimble missions that only an airplane can address.  
> 
> I think that you will agree that we are not close to crafting a comprehensive trust framework -- even if we are close to building a model that can specify its components (the Trust Framework Meta Model).
> 
> Of course, there is a danger in seeking incomplete, short-term solutions.  Such solutions tend to captivate peoples' thinking and cause the creation of tools and infrastructure that actually serve as barriers to building the better airplane.  Consider how the current petroleum distribution network sets such a high bar for the distribution of alternative automobile power sources (electricity, hydrogen, LNG) that it serves as a barrier to their creation.  In the trust framework space, current stop-gap regulatory efforts are imposing substantial constraints to solving an already complex problem.  
> 
> I am not sure that there is a simple way to resolve this conflict.  The accepted "free-market" approach is to merely let both sides proceed and let "the market" be the judge.  However, inefficient this will show itself to be in retrospect, I am not sure what alternatives there are.  Absent some global political power that is stronger than "the market" (a power that I have never witnessed), I see little alternative to this laissez-faire capitalism.
> 
> But we can recognize that both efforts are continuing concurrently and seek to reinforce one another rather than trying to stifle each others' efforts.  If we keep abreast of each other we may be able to take advantage of "lessons learned" that are transferable from one group to the other.  I see no point in arguing for the superiority of one approach to the other -- once we recognize that the two approaches are not in direct opposition.
> 
> Thank you.
> 
> Jeff
> 
> My suggestion is th
> 
> 
> 
> On Sun, May 22, 2011 at 8:58 AM, Rainer Hörbe <rainer at hoerbe.at> wrote:
> I was too late for the discussion regarding federation governance, but I liked to see the good explanation of the relationship between legal and operational levels in <_Draft Trust Framework-7.doc>. I agree mostly to this document, but I would like to question one issue: Should the scope of TFs be limited to identity-related rules? The draft implies that its scope is limited to confidence in identity, like IAF, 800-63 and others do as well.
> 
> My considerations to go beyond this limitation:
> a) From a system modeling view the trust infrastructure is a service that is provided to some business functions. The trust infrastructure (legal/operational) shall guarantee the common information security and privacy objectives that are not specific to certain business cases. The ritual view (with slight variations) in enterprise IT is that infosec's objectives are confidentiality, integrity availability and accountability; privacy has notification, data minimization and the other principles listed in the PF. Most of these objectives are related to identity, but not all. Clean modeling - minimizing complex dependencies, overlaps and gaps - would not take identity as the salient factor to structure or delimit the trust infrastructure or split the TF into subcomponents, because it would only reduce the topic by a small fraction without providing a clean interface.
> 
> b) Trust Frameworks need to be aligned with other policies when federations are linked with enterprise systems or cloud services. In this context it is essential to ease mapping by using the approved approach of enterprise security frameworks, with the objectives at the top level as listed previously. Otherwise the interoperability would suffer. Differences between HIPPA, PCI DSS, 2700x, ITIL, SOX and others are difficult enough to bridge.
> 
> c) There are areas that are indirectly or partially related to identity:
> - Data collection: Data may be collected that is anonymous or pseudonymous, but will be become identifiable to some degree later due to aggregation and business intelligence. It has nothing to do with confidence into the identity of a remote user in the traditional sense.
> - Availability: Data loss prevention in the user-to-self scenario, long-term availability of CSPs, availability of audit repositories etc. are related to identity, but only a part of comprehensive SLA.
> - Authorization: The user's entitlement is an essential part of a trust infrastructure and add value to an identity. The processes for (delegated) provisioning need to be considered as well.
> 
> To converge to sustain
> 
> This message contains information from Equifax Inc. which may be confidential and privileged. If you are not an intended recipient, please refrain from any disclosure, copying, distribution or use of this information and note that such actions are prohibited. If you have received this transmission in error, please notify by e-mail postmaster at equifax.com.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-tfmm/attachments/20110522/3158e228/attachment.html 


More information about the WG-TFMM mailing list