Re: [security-services] Name Identifier Management Protocol/Profile

["Conor P. Cahill" <concahill@aol.com>]

Thomas Wisniewski wrote on 11/2/2004, 8:21 AM:

Hi. I wanted to get a clarification on the purpose of this protocol/profile. I.e., it is to provide id federation features (where the respective providers do not need to know the true identity of the user).

It can work
whether the name identifiers are pseudonymous or not (e.g. if both
parties are using a public identifier, they can still use this value to
indicate that the identifier has changed -- as in a user changing their
domain login ID).

In the core spec, line 2289, it says "After establishing a persistent name identfiier". Does the word persistent here apply to all types of identifiers that are like urn:oasis:names:tc:SAML:2.0:nameid-format:persistent (which may be defined externally, or in future versions of SAML)? Or is it meant to be applied literally, so emailAddress, X509SubjectName, etc.... are meant to be used with this protocol/profile?

It can be used
with any persistent name identifier (including emailAddress, etc.)  -
it does not make sense to use this for non-persistent identifiers since
they don't persist anyway.

The profiles spec (paragraph around line 1280), also alludes to an "alias" that the SP can use, suggesting that it only applies to the former case I described above.

The "alias" can be
used for any form of persistent identifier and is meant primarily as a
means of allowing the SP to be able to implement these protocols
without the need for changing their internal database indexing
mechanisms.  If the SP has no problem indexing off the identifier
provided by the IdP, then it won't use an alias.  If, on the other
hand, the SP wants to continue to use its existing indexes and so needs
to provide some identity key to the IdP, it can use this alias
mechanism to do so.

The use of an "alias" is optional and I expect that many deployments
will end up *NOT* using it.  

Conor