OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: ID Federation - Is there a notion/need of one-way vs. two-way direction for it


Title: ID Federation - Is there a notion/need of one-way vs. two-way direction for it

Hi. A general question about id federation "direction". Do folks perceive that the direction of the federation will be meaningful and thus implementations will be required to store them. Specifically, I mean where the id federation was generated from (e.g., an IDP to an SP). My initial take on the initent of the specs was that once federated, an identity could be used in either direction without regard for any other provisions. However, the definition of the schema types makes it such that we have to store the direction in order to support the ManageNameID protocol in a non-ambiguous manner.


The simple case to consider is when a provider can be both an IDP and an SP. Assume there are 2 of these call them P1 and P2, and they federate a user's identity between them. Should information be kept about which one of the 2 initiated the federation? [Not to mention what about the case where federation happens off line, in a bulk fashion where there is no true originator distinction].

Consider the case where the id federation is such that
P1 -> p1-abc    maps to     P2 -> p2-xyz

And now assume P1 wants to change its alias (opaque identifier); then if the notion of who the originator in the federation is not stored, then there are actually two ways you can send this request from P1 to P2 in terms of how the NameID is defined:

<NameID nameQualifier="P1" SPNameQualifier="P2" Format="...persistent" SPProviderID="p2-xyz">p1-abc</NameID>
<NewID>p1-def</NewID>

<NameID nameQualifier="P2" SPNameQualifier="P1" Format="...persistent" SPProviderID="p1-abc">p2-xyz</NameID>
<NewID>p1-def</NewID>

In both cases, P2 canl update its alias for the user it knows as p2-xyz to be p1-def. It can do this because it can recognize its own Name Qualifier and hence determine which alias belongs to them (either SPProviderID or the NameID content).

Tom.




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]