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

From
Conor P. Cahill <>
Date
2004-11-02T14:06:24+00:00
ID
Thread
Re: [security-services] Name Identifier Management Protocol/Profile
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