[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]