OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

security-services message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]