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] 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).


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]