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

["David Waite" <dwaite@pingidentity.com>]

> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@osu.edu]
> > 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.

The way I have looked at this - NameID's are normally scoped by a
certain entity's issuing authority/authorities. If company X starts
issuing assertions to company Y which relate to a subject who really
works for company Z, klaxons should sound. 

With the 'persistent' profile, NameID's are further scoped down to a
pair-wise relationship between two parties; the asserting policy which
creates the persistent identifier (IDP), and the relying party which
accepts and (possibly) correlates an existing account with that NameID
(SP). However, this process of acceptance makes the same NameID mutually
"owned" by both parties.

The interesting question is whether the relying party before (the SP)
can use a correlation to perform its own local authentication, and can
then turn around and use that NameID to assert authentication to the
IDP. To me, this seems like a valid deployment option. An example would
be an environment where SSO is used across services controlled by the
same business entity and deemed to have equally secure authentication
policies and mechanisms. 

The SP/IDP roles used in the language and protocol ('SPProvidedID') seem
to indicate that these trust relationships must be unidirectional. My
interpretation based on the current language is that a second identifier
(or pair of identifiers) is needed to reverse the roles and create a
relationship in the alternate direction. 

If the NameID 'SPProvidedID' child was change to something like
'PartnerProvidedID', and if the language for the Name Identifier
Management section struck the usage within SP/IDP roles, the option for
bidirectional usage of the 'persistent' NameID type would be clearer.

-David Waite