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

[Rainer Hörbe]

Summarizing our off-list chat:

Definition: A trust relationship between 2 federation actors is established by joining the federation and has a set of requirements from one actor A to actor B, and actor A trusts B because B accepted to fulfill these requirements.

We agreed that we do not think to create a single all-encompassing policy framework/SAC, but we need clear criteria to separate the various components of the trust framework. Processes should not be used for categories of trust, because a number of requirements is involved. Hence, Identity Proofing is not a good category. Alternatives are:
- Roles (as in http://www.portalverbund.at:8080/cmmls/compare_fw.jsp) and 
- trust relationships (as in http://tinyurl.com/36l5z4a).

Looking at your table, I think that roles might be more appropriate then trust relationships.

We agreed that to FO should net be eliminated. Jeff assumes (hopes) that trust into the FO can be generalized as a function of the other trust relationships. But that will need further analysis.

---

Further remarks:

"Attribute Proofing: This MAY end up being collapsed with Level of Assurance for Identity Proofing". 
I do not believe this:
On a technical level it could collapse with LoA; On an administrative level not, if the AP is the authoritative source. E.g. if you want to assess the LoA of a UK passport holder, how would you assess the UK passport offices? The operate by law, but the implementation and internal audits are not transparent. And the law might not be explicit about how to issue passports. It is a typical "you take what you get" pattern.

"Credibility" could be more specifically named "Business Process Credibility"

Rainer

Am 27.11.2010 um 14:59 schrieb j stollman:

> 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
> <Trust Framework Categorization.xlsx>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://kantarainitiative.org/pipermail/wg-idassurance/attachments/20101127/8b3b927d/attachment.html