Re: [security-services] Inclusion of Federated Name Registration Protocolin SAML 2.0

[John Kemp <john.kemp@nokia.com>]

ext 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.
> 

Neither do I.

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

Because the IdP may want to change the handle, and the user then decides 
some time afterwards, and without returning to the SP, to initiate 
logout at the IdP. The IdP would have to specify the "old" NameID when 
contacting that SP.

And of course, there is an issue with what you're suggesting generally, 
which is that the IdP would get no response from the SP saying that they 
actually *have* changed the IdPProvidedNameID if the IdP only supplied 
the change in an AuthnResponse. If the IdP doesn't get a response 
message, I guess it has to assume that the SP did not change the 
NameID... this could be particularly important for successful logout BTW.

> 
> There is no other reason or context that requires the SP be informed of this
> change, is there? 
> 

Yeah - the important case is that the SP must either make the change 
before logout is initiated by the IdP, or the IdP must target both old 
and new identifiers in a logout.

- JohnK
> - prateek
>