[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: Name Federation Using Persistent Pseudonyms
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]