RE: [security-services] ResponseLocation attribute

["Scott Cantor" <cantor.2@osu.edu>]

> This attribute MUST not apply to artifact resolution, single 
> signon, and name id mapping, but can apply to manage name id 
> and single logout. The wording seems to suggest that it also 
> only applies to the protocol response (as opposed to the 
> request) as well.

That's correct. It's just a way of bundling the request and response
endpoints for a protocol without requiring separate elements or assuming
that the endpoints have to be the same, although they may be in many cases.

> I want to confirm that the purpose of this is NOT as an 
> alternate location for failover/loadbalancing purposes -- 
> which can be achieved via add'l service RoleDescriptors 
> (unless of course there is an implied restriction, based on 
> the example, that one can only define a single RoleDescriptor 
> for a service per binding type)?

It's definitely not for that purpose, and there are multiple ways to handle
failover. You could add multiple roles, but it's easier to just add another
endpoint element of the same name. You can freely include as many
SingleLogout elements, for example, as you like. They don't all need
different Binding values. There's no rule about that.

> Rather the purpose of it is for it to ALWAYS be used instead 
> of (i.e., in place of) the Location attribute when sending 
> the response (when the attribute is present). Therefore for 
> the supported protocols, you can have different urls for the 
> request and response messages (Lcoation and ResponseLocation, 
> respectively). The definition however, on lines 227-228, 
> states that the ResponseLocation is a "secondary location" 
> which seems to suggest you could try this for failover or in 
> place of the Location attribute (seem not to be well defined).

I agree, that's not the best text. We should make it more specific.

-- Scott