RE: SOAP 1.1 Protocol Binding

["Orchard, David" <dorchard@jamcracker.com>]

<snip/>


>     OD> o Headers should be specified explicitly, and how
>     OD> intermediaries will deal with them.
> 
> _This_ is where things get tricky. As I understand it, we don't
> -really- have a reason to use headers except as guidance for the
> underlying protocol (e.g., for routing). If they are defined somewhere
> else, it seems like it would be redundant to enumerate them here. If
> they -aren't- defined somewhere else, well... I don't think it's our
> job to standardize SOAP -and- SAML. SAML's hard enough.
> 
> There are some headers that would probably be very useful for a
> transport-independent protocol. For example, identifying the message
> sender, identifying message receiver, timestamps, unique message ID,
> etc. However, I'm of the opinion that these should be neutral w/r/t
> the SAML protocol binding -- that is, they should be part of our SAML
> message protocol. (AuthXML has some headers to do this, as an idea.)
> 
> The one thing that headers -may- be useful or required for is for
> intermediaries. Data that says, "I got this, and I'm passing it along
> to you." Or "I'm sending this to you, pass it along to party X."
> 
> This gets into a tricky situation, that is, we don't really have a
> good definition of what the role of an intermediary is. Is it simply a
> data routing entity? Or does it have some SAML-specific function, too?
> 

If we don't have any rules for intermediaries and headers, then I propose we
preclude their use completely.  How can we have interoperability if we don't
have a clue how these things will be used.  SAML 1.0 only allows for point
to point, not thru intermediaries.  I know we have use cases where people
can add things into the message, but if we can't figure how intermediaries
would do this using headers, then I say we drop the use cases.  

I think people who want intermediaries are going to have to propose what the
processing model should be.

>     OD> o The use of order in headers needs to be called out, is
>     OD> it lexical or some other order?
> 
> That's an interesting question that I don't really understand. I'll
> try and do some research to see why this would matter. I guess I was
> thinking of SOAP headers as pretty much an unordered bag, a la RFC 822
> messages.

SOAP 1.1 isn't clear on order of headers.  SOAP 1.2 may make this
> 
>     OD> o The behaviour of Header errors needs to be called out.
> 
> Eeep. Yeah, if there are headers that are SAML-specific, I guess they
> do. If there aren't... well.
> 
>     OD> o The contents of FaultDetails should be specified IFF we want
>     OD> to allow multiple returns.  This is how SOAP is designed for
>     OD> multiple errors.
> 
> OK, well, I think I wanted to make the fault codes as sparse as
> possible. In my mind, an error message at the protocol level can mean
> one of several things:
> 
>         * Authorization Error: I don't know you, I don't want to know
>           you, you're not authorized to talk to me, leave me alone.
> 
>         * Message Format Error: You sent me a bogus message, which I
>           can't even figure out well enough to even try to process.
> 
>         * Server Error: I tried to process this message and everything
>           blew up. I somehow managed to send up a warning flare.
> 
> I guess I think that we would use SOAP fault codes only for these
> kinds of situations. Other ones that fall more in the SAML problem
> space would have to have SAML-specific error notification. For
> example, if you sent a query to me for an attribute assertion for a
> user I didn't have, I should send you a SAML query response explaining
> that problem, rather than a SOAP fault code.

I think I agree with you, but SOAP faults can be used to carry SAML errors.
It's just their aren't in the SOAP fault code space.  Faults are exactly
meant for application errors.

> 
>     OD> o 4.6.1 "The parties MUST NOT add signatures in either the
>     OD> headers or the envelope of the SOAP message.".  Are you
>     OD> serious?
> 
> Ha ha ha! Of course not. Little joke I slipped in, glad you caught it.
> 

busted ;-)

>     OD> Imagine 2 cases: 1) Author wants to specify the exact route of
>     OD> a message through intermediaries; 2) Author wants multiple
>     OD> intermediaries, but it only knows the first node.  How are
>     OD> headers constructed differently based on these 2 processing
>     OD> models.
> 
> Yikes! See, now, this is the kind of thing that I think is up to the
> underlying protocol. If SOAP (and -its- underlying transport
> protocols) have definitions for this kind of thing, great. Otherwise,
> terror!
> 

No way is it at the underlying protocol.  If there's any routing through
SAML entities, then the entities have to know how to deal with the SAML
headers.  

This is exactly what SOAP headers and Actor are for, is allowing the
specification of nodes that can process headers until finally the body
processor gets the message.

Cheers,
Dave