[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: SOAP 1.1 Protocol Binding
>>>>> "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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC