RE: [saml-dev] use of protocolSupportEnumeration

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

> Well, let me push back just a little bit, because I'm still confused.

That's fine, I'm just making sure to explain that you're looking in the
wrong place for a solution to this.

> Noting the two URIs I quoted earlier,
> 
> urn:oasis:names:tc:SAML:profiles:query:attributes:X509-basic
> urn:oasis:names:tc:SAML:profiles:query:attributes:X509-encrypted
> 
> plus the related URI from [SAMLProf]
> 
> urn:oasis:names:tc:SAML:2.0:profiles:query

That profile is implied by the <AttributeService> element. That's what it
means. Reading the spec, it's sloppy..it says "protocol" but points to
SAMLProf as it should. s/protocol/profile and we're there. This should be
errata.

> we have at least three attribute exchange profiles from which to
> choose (plus I have a SAML 1.1 attribute exchange profile I'd like to
> add to the mix).

And you *cannot* overload <AttributeService> alone for that.

> 1. How does an IdP advertise its support for one or more of 
> these profiles?

That's up to the profiles to define metadata characteristics if they want
them. Most likely by defining namespace-qualified attributes that you plug
into <AttributeService> elements to mean "hey, I support profile foo".

I've done them like this for similar cases:

<AttributeService xprof:hasSupport="true"
xmlns:xprof="urn:oasis:names:tc:SAML:profiles:query:attributes:X509-basic"
Binding="..." Location="..."/>

That allows a client to search for an endpoint with support for its chosen
profiles.

> 2. How does an SP advertise its support for one of more of 
> these profiles?
>
> Seems like the latter is particularly important otherwise an IdP won't
> know how to respond to a particular attribute query.

There's no place to put it, so important or not, it's not there.

> Suppose, for example, an IdP receives an attribute query with an
> encrypted NameID?  How does it know which of the above three profiles
> is in effect?  There is nothing in the metadata to help it make this
> determination, it seems.

Why not just use a different endpoint? Or the profile maybe ought to define
extensions that signal what profile the message uses.

-- Scott