Re: schema 16 comments: autn assertion and attribute authority

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

I'd like to pursue this topic a bit more, if I may. By way of
introduction, I'm helping with the Shibboleth technical design process,
particularly the low-level aspects, and just joined the list as an
additional observer/liason along with 'RL' Bob and Marlena. My
background is primarily in web development and distributed computing,
with some dabbling in application-level security.

Simon Godik wrote:
>It's been pointed out by Shibboleth design that authentication
>authority can front several attribute authorities. After authentication
>assertion is received how do we know which attribute authority to use? 

I'd go a bit further in that we also need to know what protocol should
be used to exchange any subsequent messages (in Shibboleth's case,
attribute request and assertion response messages). We expect to adopt
the SAML HTTP binding for this (in whole or in part) in our initial
pilot, but of course there may be others eventually, and SAML itself has
tentatively defined a pair, HTTP and SOAP.

It would seem logical at minimum to tag these with URIs, just as the
authentication methods have been, and include that URI in the locality
information you're proposing.

It's also, I think, self-evident, that having an endpoint address and
port are not sufficient to specify a binding over HTTP or SOAP, since
you need the URI (unless you define a well-known endpoint, which seems
unnecessary).

The (very) preliminary idea in Shibboleth was to model the binding
information as a string that would be parsed in accordance with the
binding method/protocol. For example, if a directly TCP-based protocol
was used, we might encode it as host:port, or if HTTP or SOAP was used,
the string would be a URI.

So this might look like:

<complexType name="LocalityType"> 
    <attribute name="Protocol" type="anyURI"/> 
    <attribute name="Binding" type="string">
</complexType> 

Obviously, structuring the Binding string is fine also, perhaps with an
abstract type that is extended for each protocol people develop.

I've only just begun to really digest a lot of what's in SAML, although
I've looked a lot at the binding side, on which I have a bit more to say
separately, but this is a particular aspect we would definitely like to
see included.

--------
  Scott Cantor               So long, and thanks for all the fish.
  cantor.2@osu.edu                  -- Douglas Adams, 1952-2001
  Office of Info Tech        PGP KeyID   F22E 64BB 7D0D 0907 837E
  The Ohio State Univ        0x779BE2CE  6137 D0BE 1EFA 779B E2CE