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

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

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


Subject: RE: Name Federation Using Persistent Pseudonyms


> But my final point is that, since you udnerstand the context
> of my deployment of SAML 2.0, I will not need to separately
> use Name Identifier Management Profile, right? That is, I can achive
> intended goals, by simply using WEB SSO Profile, which comprises of
the
> Authentication Reqest Protocol, and in my case, Artifact Binding.

The NameIdentifier Management protocols resulted from these use cases:

	* pseudonymity is assumed to decrease with age and therefore 
	  pseudononymous identifiers should be refreshed periodically.
	  I'm not convinced that this is absolutely true for an 
	  identifier that is not provided to a user (so the user 
	  can't leak it somehow), but others were more convinced.

	* One of the guiding principals in developing the protocols was
	  to make things as easy as we could for the RP since there 
	  typically would be many more RPs than IdPs.   So, we allowed
	  an RP to define their own NameID for the user so that they 
	  did not have to index their data on the IdPs NameIdentifier.

	  So, upon first receipt of the IdPs Identifier, they RP could
	  send back their own identifier would would be included on 
	  subsequent SSOs.

	* An IdP may, at some point, re-build it's identifiers for some
	  reason (perhaps it was short sighted and found out it was 
	  running out of room in the namespace it selected for it's 
	  identifiers (like IP addresses & phone numbers)).  These 
	  protocols would allow the IdP to update it's identifiers 
	  as necessary.

If these cases are not of interest for you, they you can get away
without
having to implement those protocols.

Note also, that you can certainly go out with a deployment now without
these capabilities and come back and add them later as necessary.

Conor
	
 


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