OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [saml-dev] use of protocolSupportEnumeration


On 6/15/06, Scott Cantor <cantor.2@osu.edu> 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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]