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

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

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

I more or less agree, which is why I don't think your subsequent premise
follows...

> The SP/IDP roles used in the language and protocol ('SPProvidedID') seem
> to indicate that these trust relationships must be unidirectional.

I don't see this. I mean, I can see why it might read that way, but I don't
think what's there now strictly conflicts with an entity originally an SP
turning around and issuing an assertion back. All it says now is that the
NameQualifier is to contain the identifier of the IdP who created the
identifier. Not necessarily the IdP who's issuing the particular assertion.
If you switch roles, the NameID content needn't change.

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

That would not be mine, so I guess the language needs to improve. In
particular, I view this kind of thing as no different than a NameID that
contains a different format and qualifier, say a DN. It is what it is. If
you know it, and if the relying party is willing to trust your assertions
about it, it's legal.

That's why I don't like the term "directional" for this thing. I don't think
it's directional in terms of usage, only in terms of content.

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

I think the protocol is cast in terms of those roles, but in terms of a
particular shared identifier, the respective "roles" for the purpose of
those processing rules are fixed at the time the XML is first cast.

Within the SSO profile, they could switch roles, but in terms of NameID
Mgmt, I don't think that's the case, or you get the ambiguity Thomas was
mentioning.

The other option to address this would be using distinct messages for
registering an SP alias vs. changing the IdP created value. That's not the
first time it's been suggested.

I don't quite see how renaming anything changes things though. You've still
got a potential pair of qualifiers and identifiers and which goes where
shouldn't be left to a matter of perspective, but simply cast in stone based
on the original XML formulation.

-- Scott