RE: [security-services] ID Federation - Is there a notion/need of one-way vs. two-way dir ection for it

["Scott Cantor" <cantor.2@osu.edu>]

> 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.

I think the whole NameID element is in essence a unit. It's stored as a unit
and referenced as a unit. If that's what you mean by "store the direction",
I guess I agree, any given persistent NameID essentially has one
"direction".

> 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]. 

I think that's the wrong way to think about it. What matters is, what is the
XML content that makes up an identifier? Once you decide, it's fixed and the
subject is "that guy" (pointing at XML blob). Unless you want to change it
or extend it, and it's still unambiguous ("change the blob from <> to <>").

In terms of which of the entities is acting as SP or IdP in terms of the
protocol definition, you can extrapolate, I guess, from the way the fields
line up in the original XML. In the bulk case, whatever you choose to place
in the NameQualifier field becomes the entity considered to have "created"
the identifier, at least in the persistent format case.

Note that the other types of identifiers don't even specify what the
qualifiers might be or what they might be used for. The purpose behind
tightening them up in this one use case is just to formalize the pair-wise
nature for privacy reasons.

> 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:

Right, but not if the original XML is recoverable into the original
formulation it had, which I believe is necessary anyway given the lack of
rules around use of SP/NameQualifier in the other formats.

-- Scott