Re: SOAP 1.1 Protocol Binding

[Evan Prodromou <eprodromou@securant.com>]

>>>>> "OD" == Orchard, David <dorchard@jamcracker.com> writes:

    OD> Evan, The protocol binding needs to be very specific about how
    OD> it is bound to SOAP 1.1. 

David,

Thanks for the excellent feedback -- it's much needed! I'll try and
integrate your suggestions over the next few days, but I don't think
they'll get into the bindings doc for F2F#3. I was tardy getting this
in as it is!

Here's my responses, in order:

    OD> o SOAPAction must not be used.  Rationale, SOAP 1.2 will be
    OD> deprecating or minimizing it's usage.

OK, that makes lots of sense.

    OD> o Preclude trailers.  SOAP 1.1 leaves trailers undefined

Check.

    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?

    OD> o It should be called out whether Actor and MustUnderstand are
    OD> required for headers or not.

Check.

    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.

    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.

    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.

Seriously, I guess what I was trying to get at was that digital
signatures that are an important part of the SAML definition should go
on the SAML data itself, and not be lodged somewhere on the headers or
the envelope or what have you. This would allow me as an intermediary
to, say, take a message you sent me through SOAP and pass it to
another system using "raw" HTTP or BEEP. Since the sigs are on the
SAML part, it would still have verifiable integrity after crossing
that protocol boundary. 

    OD> Say an intermediary processes a header (mustUnderstand="1")
    OD> and changes the attribute to (hasUnderstood="1", SOAP 1.2
    OD> proposal) and adds a signature to indicate secure that it
    OD> processed the header.  Why preclude that?.

You're absolutely right, there's plenty of non-SAML reasons to add
sigs. I guess I need to find a better way to say that.

    OD> o The processing model of intermediaries is very unclear here.

I was hoping that wouldn't show. B-)

    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!

~ESP

-- 
Evan Prodromou, Senior Architect        eprodromou@securant.com
Securant Technologies, Inc.             415-856-9551