RE: [security-services] ResponseLocation attribute

[Thomas Wisniewski <Thomas.Wisniewski@entrust.com>]

Scott, thanks, so I'm correct in assuming the interpretation is (will be)
such that:

"If the ResponseLocation attribute is present, then for protocol responses
it MUST be used and the Location attribute should be ignored."

Thus from an implementation standpoint, one can always distinguish the
request and response protocol messages based on the URL, if desired.

One other question, perhaps the SSODescriptor should contain an optional IDP
Discovery element of type anyURI. Thus if IDP Discovery is used by IDP/SP
provider, metadata can used to determine the URL to use. Additionally, to
support multiple groupings (i.e., the case where an IDP belongs to 2 or more
different sets of affiliations and IDP discovery is necessary in different
domains), perhaps this should be an unbounded sequence containing the IDP
Discovery anyURI element and an optional identifier/qualifier string
attribute that uses a value known to the providers involved.

Tom.

-----Original Message-----
From: Scott Cantor [mailto:cantor.2@osu.edu]
Sent: Wednesday, October 06, 2004 11:09 AM
To: 'Thomas Wisniewski'; 'SAML'
Subject: RE: [security-services] ResponseLocation attribute


> 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