On 6/15/06, Scott Cantor <> wrote:
>
> > 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="..."/>
This works fine for a single profile but what if a single
AttributeService wishes to support multiple profiles? It will tend to
get a little ugly.
> That allows a client to search for an endpoint with support for its chosen
> profiles.
Why not specify attribute profileSupportEnumeration?
> > 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?
You mean multiple AttributeService elements in IdP metadata? This
would work but I'll bet they all look similar except for the endpoint
location.
> Or the profile maybe ought to define
> extensions that signal what profile the message uses.
In the AttributeQuery on a per-transaction basis? I'm not sure that's
necessary if the appropriate endpoints are called out in IdP metadata
(as you suggest).
Tom
