RE: [security-services] ResponseLocation attribute

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

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

Right, I think the point is to strike a balance between strict language
within the generic type definition in the metadata document vs. profiles
that use the elements just specifically calling out what to use them for. I
was leaning more toward the latter.

What distinguishes SingleLogout/etc. from SSO is that with SSO, usually an
entity may just play one side and only handles requests or responses, while
Single Logout requires both entities to handle both messages.

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

I haven't really thought much about that profile. Liberty provided the
profile, and there isn't anything in ID-FF metadata pertaining to it, and it
never came up, but I guess I could imagine including something.

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

I think generally speaking that an IdP that's acting in different contexts
will often have multiple entity IDs facing the different communities, and
publish different metadata pertaining to them (e.g. different keys, etc.)

IOW, the identification strategy that is now more formally part of SAML has
sufficient abstraction to avoid adding more.

-- Scott