RE: Name Federation Using Persistent Pseudonyms

[giorgi moniava <giorgimoniava@yahoo.com>]

Hi Conor.

Thanks for extensive elaborations.

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.

Giorgi.


--- On Fri, 8/1/08, Cahill, Conor P <conor.p.cahill@intel.com> wrote:

> From: Cahill, Conor P <conor.p.cahill@intel.com>
> Subject: RE: Name Federation Using Persistent Pseudonyms
> To: giorgimoniava@yahoo.com, saml-dev@lists.oasis-open.org
> Date: Friday, August 1, 2008, 5:21 AM
> > But in my SAML 2.0 deployment context, the users are OK
> with
> > the fact that throughout the usage of SAML 2.0
> persistent pseudonyms
> > will be used.
> 
> This is an assumption that has nothing to do with SAML 2.0.
>  In some 
> deployments this may be correct, but in others it would not
> be.  For
> example, in the typical Shibboleth deployment they would
> *not* use
> persistent identifiers (pseudonymous or not).
> 
> > So, I think I could just use the WEB SSO profile, and
> > in the Authentication request elements, indicate that
> the identity
> > provider should generate a pseudonym for the
> authenticated users,
> right?.
> 
> I think many circles of trust will have a general policy
> for which type
> of identifiers get generated and in some there will only be
> one kind of
> identifier.  In others there may be multiple in which case
> the RP would
> need to specify which kind it wanted on the AuthnRequest.
> 
> > The linking of users accounts with the pseudonyms is
> done outside the
> > scope of SAML 2.0 I guess 
> 
> Yes, how the actual linking takes place is outside of scope
> for SAML.
> 
> > again, as I said, users are not needed to be
> > asked whether they want to federate accounts between
> identity and
> service
> > providers, since they are OK with it.
> 
> This is definitely going to be a per-deployment issue.  In
> some cases,
> the user won't be explicitly asked during the
> transaction (because they
> were asked at some point prior to that -- perhaps even
> providing that
> consent when they signed their employment agreement), but I
> would think 
> that in most cases there would have been some consent
> established from
> the user and in many consumer cases that will be on a
> per-provider
> basis (e.g. Amazon has asked us to authenticate you to
> them, is this OK?
> Should I remember to this decision? ).
> 
> The requirements for consent collection (how the questions
> are asked,
> when they are asked, how and how long they are remembered,
> etc.) vary
> dramatically in different geopolitical areas and even in a
> given 
> geopolitical region, can vary dramatically between
> providers.
> 
> 
> Conor