[WG-IDAssurance] Identity federation use cases, trust relationships and scope discussion

Rainer Hörbe rainer at hoerbe.at
Sun Nov 28 17:38:49 EST 2010 

We need to make a difference between legal/social and technical trust. The latter follows the first. The trust relationships in the Constellation/Use Case document are on a contractual level. Hence these trust relationships can only address actors that can be held legally/socially responsible. See the attached analysis for my rationale of that statement.

For the technical trust relationship, I agree that active clients should be included as actors. 



- Rainer Hörbe

Am 28.11.2010 um 23:13 schrieb Bob Pinheiro:

> Another component that may figure into one or more trust relationships is known by various names, such as selector, active client, or Identity Selection Agent (ISA).   While these different terms may mean somewhat different things to different people, they all designate an entity that houses and manages a user's digital credentials.  These credentials are essentially representations of the user's identity as defined in terms of some set of attribute or claim placeholders (the metadata).  Initially selectors were defined as part of Microsoft's vision for an Identity Metasystem to house and manage Information Cards.  Then selectors evolved into "active clients" in which an OpenID can be represented graphically within the active client.  Now the ULX WG is talking about Identity Selection Agents which house and manage (Info Cards?  OpenIDs?  other things?).  
> 
> A consideration in determining the trust relationships between selectors and other components would be whether the selector resides on the user's own device, or resides "in the cloud."  It seems to be an open question as to whether a cloud-based selector would require a user to authenticate to it in order to access the user's (OpenID, Info Card, other credential).  Since the user must also authenticate to an identity provider in order to generate the appropriate claim or assertion, it is unclear whether use of a cloud-based selector requires multiple authentications (to the selector as well as the identity provider and/or other attribute providers).  
> 
> Selectors/Active Clients/ISAs are presumably activated by some message sent from the relying party that contains policy information.  So there may be some implications for trust relationships between RPs and selectors, and between selectors and identity providers.
> 
> Cloud-based selectors provided as a service to the user would know a lot about a user's activities, raising privacy concerns.  That may be a reason to prefer device-based selectors under the user's control, provided that users with multiple devices could maintain portability and manage selectors and credentials on these devices.  
> 
> Active clients and selectors were discussed at IIW-11 (notes here) and at IIW-9.  U-Prove technology that could potentially help mitigate privacy concerns was also discussed at IIW-11, and was also the subject of a presentation at the recent Kantara F2F meeting in Paris.
> 
> - Bob Pinheiro
> 
> On 11/27/2010 8:59 AM, j stollman wrote:
>> 
>> Rainer,
>> 
>> I am encouraged by your analysis.  You raise several valuable points regarding Trust Frameworks:
>> The overall Trust Framework (of which the IAF and forthcoming Privacy Framework are only components) will need to accommodate all of the trust relationships that exist among the various parties.
>> Only by understanding all of the trust relationships in this larger framework can we appropriately define the scope of the various framework components (e.g., IAF and PF).
>> In addition to the standard parties (Subject, Identity Provider, Relying Party, and Attribute Provider/Assurer), it may be necessary to specifically account for trust relationships between these parties and the Federation Operator.
>> As preliminary work for the Privacy Framework, I have been attempting to list all of the trust relationship (excluding the Federation Operator) that may be in play.  I have begun with the assumption that until demonstrated otherwise, every form of trust (e.g., trust that the party with whom one entity is dealing is the authentic party it claims to be) needs to exist in pairwise relationships between each of the parties.  And because trust is one-way with one Subject trusting one Object, this implies that there are 12 potential trust relationships for every form of trust.  [NOTE: It is my hope that the trust relationships that involve the Federation Operator may be subsumed within other relationships in order to remove this additional level of complexity which would expand the number of relationships to 20.)
>> 
>> I have attached the start of this list.  The list is admittedly incomplete both in its length and in the considerations within each of the current 19 categories.  II welcome further additions/corrections, as I am sure that consideration of additional use cases (including those listed in your link) will expose additional trust relationships.
>> 
>> The task before the Privacy Framework subgroup is to select from this list of trust relationships those that we believe can reasonable be fit into a viable Privacy Framework.
>> 
>> Thank you.
>> 
>> Jeff
>> 
>> On Thu, Nov 25, 2010 at 4:24 PM, Rainer Hörbe <rainer at hoerbe.at> wrote:
>> As a follow-up on the meeting from the IAWG meeting from Oct 27, I compiled a list of "use cases" (baptized as constellations) and trust relationships that should help to discuss the scope of identity federations for the IAF (LoA, SAC and FOG) documents. 
>> 
>> Link: http://kantarainitiative.org/confluence/x/8oh7Ag
>> 
>> My preliminary conclusions (= suggestions for further discussion) are:
>> 
>> a) Make trust relationships the deciding factor for the scope definition. This has a number of benefits:
>> - It is easier to fit the scope of IAF documents with the possibilities of legal contracts, which require to define rights an duties per party
>> - The framework can be extended to satisfy the complete set of trust requirements by all parties
>> - Documents audience can be defined per party (role), better defining who needs to read what.
>> Intuitively, the IAF documents are already structured like this to a great extent, but an explicit analysis should make it possible to make that complete.
>> 
>> b) Select the subset of trust relationships that is as congruent as possible with the current set of requirements. 
>> 
>> c) Align the current documents with the set selected in b), and produce a minor revision.
>> 
>> d) Extend the scope of the IAF to include all trust relation ships, possibly ending up with a complete "Trust Federation Assurance Framework"
>> 
>> e) Put this work on the roadmap of the IAWG.
>> 
>> f) Another consideration would be to refine the trust relationships and associated requirements to a formalized model that would allow automated policy                 negotiation for the inter-federation use case. (-> FIWG?)
>> 
>> 
>> Feedback is welcome, and I would like to discuss this on the Dec 1st IAWG call. If possible within the first 30 minutes, as I need to quit early that day. Independent of this contribution I will submit a similar suggestion to the ISO 29115 committee. 
>> 
>> Best regards
>> Rainer
>> 
>> PS: What is the best way to create a document with the conclusions? Just add a page in working drafts? Templates recommended?
>> 
>> _______________________________________________
>> 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-IDAssurance mailing list
>> WG-IDAssurance at kantarainitiative.org
>> http://kantarainitiative.org/mailman/listinfo/wg-idassurance
> 
>   

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20101128/48f65092/attachment-0002.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: FederationScope.pdf
Type: application/pdf
Size: 243442 bytes
Desc: not available
Url : http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20101128/48f65092/attachment-0001.pdf 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20101128/48f65092/attachment-0003.html

More information about the WG-IDAssurance mailing list