[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [security-services] Inclusion of Federated Name Registration Protocolin SAML 2.0
The problem, I think, with trying to update name identifiers though the SSO exchange, is that there's no "response" back to the IdP that confirms that the message was received -- with a request/response protocol it's much easier to do the bookkeeping. I'm afraid it would become unwieldy if we had to send the whole identifier history on each message (AuthnResponse, FederationTermination, etc). -Greg On Feb 27, 2004, at 9:00 AM, Mishra, Prateek wrote: > > > ext Mishra, Prateek wrote: > >> Could this not be accomplished by the IdP (optionally) returning a >> "fresh" >> federation identifier as part of the AuthNResponse? That is a modest >> extension to an existing protocol vs. the introduction of a whole new >> request-response pair. > > <JohnK> > 1) You'd need to carry two NameIDs in the AuthnResponse. > </JohnK> > Yes, that is correct. I don't see this as a problem though. > > <JohnK> > 2) The IdP might have to send an "unsolicited" AuthnResponse in order > to > initiate this change. Would that be an overloading of the > AuthnRequest/Response? > </JohnK> > > Why is such an "unsolicited" message needed? > > Why is it not enough that once a change to handle values is made at > the IdP, > the "next time" the user transits through the IdP, a pair of opaque > handles > are returned to the SP via the AuthNResponse. Alternatively a pair of > handles could always be returned. > > There is no other reason or context that requires the SP be informed > of this > change, is there? > > - prateek > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/security-services/ > members/leave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]