COmanage Developers List

[Steven Carmody <>]

On 10/12/10 5:32 PM, Niels van Dijk wrote:
>   Hi Benn,
>
> For now we (within COIN) choose to 'ignore' this scenario and assume
> every identity is unique. We do not map or combine identities from IdPs
> in any way. We also feared many SPs would not be able to handle complex
> or combined identities in a sensible way

I'm aware of at least a couple of different ways to "link" identities 
found in different IDPs. A few years back, David Chadwick developed a 
mechanism that allowed a user to link two separate identities via a 
linking service; an SP would know that an identity was linked, but 
wouldn't know what it was linked to.

In addition, the current Shib SP implementation allows linking, but 
makes no attempt to preserve a user's privacy. (One of the atributes 
provided along with the Authentication Assertion is used as teh Subject 
value to query other IDPs for additional attributes (typically, group 
memberships or permissions). I've used this support in a demo where the 
SP obtains group memberships from a CoManage instance.

I've also seen this description coming from Australia, which also seems 
related to this question.

-------------------------------

> Privacy Preserving Identity Attribute that can be shared between a
> defined group of SPs
>
> The Australian Access Federation has a requirements for the
> auEduPersonSharedToken attribute. The major use of this attribute is
> for sharing between Research Collaboration Tools and Services where
> sharing a common identifier between research services is not seen as
> a privacy threat.  User anonymity is not a major concern for the
> research collaboration use cases, however persistence of an
> identifier and continuity of use of the identifier when a user
> transfers between higher education institutions is seen as important.
> Hence an identifier not tied to a particular identity provider is
> required.
>
> The Shared Token while providing a solution for one set of Research
> Collaboration Tools and Services has the potential to give away too
> much information about a user. Two independent SPs that receive the
> Shared Token could “swap” other information about users without the
> user’s consent.
>
> A privacy preserving attribute that is common to a defined groups of
> SPs would allow for the requirement of sharing a token between common
> services while enhancing user privacy.  The ability for a user to
> take a set of tokens from one IdP to another rather than just the
> single shared token would be required if continuity of service is
> required when a user transfers between organisations.