[Fwd: SOAP message style]

Some (important!) messages that were sent to the -ws list.
Please us this (www-xkms@w3.org) from now on - new subscribers
won't see your mail otherwise.

Regards,
Stephen.



-- 
____________________________________________________________
Stephen Farrell         				   
Baltimore Technologies,   tel: (direct line) +353 1 881 6716
39 Parkgate Street,                     fax: +353 1 881 7000
Dublin 8.                mailto:stephen.farrell@baltimore.ie
Ireland                             http://www.baltimore.com

Forwarded message 1

  • From: Blair Dillaway <blaird@microsoft.com>
  • Date: Wed, 19 Dec 2001 16:15:21 -0800
  • Subject: SOAP message style
  • To: <www-xkms-ws@w3.org>
  • Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCE5E@red-msg-01.redmond.corp.microsoft.com>
The issue was raised as to which style(s) of SOAP messages should be
supported in defining the interface between XKMS complaint clients and
services. SOAP supports several styles with the two most common being
Document-Literal and RPC-SOAPEncoding. The XKMS 1.1 Note used the
former. As the WG develops its specification, we should make an explicit
decision as to which styles must and/or should be supported.

For those who aren't familiar with the two styles, I have provided
simple examples of 'Locate' message requests at the end. Its obvious
that the two message structures are quite a bit different. In
particular, The Document-Literal message looks like a typical XML
document structure with nested child elements. In comparison, the
RPC-SOAPEncoding message is:
	1) Quite a bit larger, due to additional namespaces and
extensive use of references
	2) Includes more information about the 'type' of information
being sent, such as the explicit nil and array type attributes.
	3) Uses a more complex style based on isolating multi-reference
values in independent elements which are then referenced by their
accessors. (see SOAP 1.1, Section 5, for the full discussion of these
rules). In some cases, an array element may appear as a child of its
accessor, but one should be prepared to handle the independent element,
accessor reference style shown.

The second point above is really the most important. SOAP encoding is
"based on a simple type system that is a generalization of the common
features found in type system in programming languages, databases, and
semi-structured data". Hence, the RPC-SOAPEncoding style lets the
originator include more information as to their view of data being sent.
This may benefit the recipient in providing hints (beyond XML schema) as
to how best to deserialize the message back into a "value graph"
representing the information in the message. 

>From the standpoint of the XKMS WG, the issues boil down to:
	- Is there a benefit to one style over the other? The Doc-Lit
style is somewhat easier to encode/decode but the RPC-SOAPEnc style has
richer semantics. Unless we believe there is value in promoting 'type
model' fidelity between clients and services, it may be easiest to stay
with the Doc-Lit style.
	- If both styles are supported, then service developers will
need to pick a style to use. This will be reflected in their WSDL
contact If they want to support both styles, then they'll need separate
URLs for each with different WSDLs. Obviously, this would increase
complexity.
	- Allowing both styles creates a dilemma for client
implementers. Do they only support one style, in which case they can
only talk with some services, or do they support both which entails a
significant increase in complexity?
	- If we add a simple integrity and confidentiality mechanism
based on XML Signature and XML Encryption, we'd need to be cognizant of
the possible message structure(s). The biggest impact is probably on
signature generation. With Doc-Lit encoding one could sign a reference
to the Locate element. With RPC-SOAPEnc you'd want to either sign a
reference to the Body element or an xPath selecting all the children of
Body. The latter seems preferable to avoid inclusion of namespaces
associated with the Body that aren't used in the contents.

SAMPLE Document-Literal Style SOAP Message

<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
   <soap:Body> 
      <Locate xmlns="http://www.xkms.org/schema/xkms-2001-01-20">
         <Query>
            <KeyInfo xmlns="http://www.w3.org/2000/09/xmldsig#">
               <KeyName>key</KeyName>
            </KeyInfo>
         </Query>
         <Respond>
            <string>KeyName</string>
            <string>KeyValue</string>
         </Respond>
       </Locate>
   </soap:Body>
</soap:Envelope>

SAMPLE RPC-SOAPEncoding Style SOAP Message

<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

xmlns:xsd="http://www.w3.org/2001/XMLSchema" 
xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"
xmlns:a2="http://schemas.microsoft.com/clr/nsassem/XKMSTypes/XKMSTypes" 
xmlns:i2="http://schemas.microsoft.com/clr/nsassem/XKMSKeyService.KeySer
vice/Key">
   <SOAP-ENV:Body>
      <i2:Locate id="ref-1">
         <TransactionID xsi:null="1"/>
         <Query href="#ref-4"/>
         <Respond href="#ref-5"/>
      </i2:Locate>
      <a2:LocateQuery id="ref-4">
         <KeyInfo href="#ref-6"/>
      </a2:LocateQuery>
      <SOAP-ENC:Array id="ref-5" SOAP-ENC:arrayType="xsd:string[2]">
         <item id="ref-7">KeyName</item>
         <item id="ref-8">KeyValue</item>
      </SOAP-ENC:Array>
      <a2:KeyInfo id="ref-6">
         <Item href="#ref-9"/>
         <Id xsi:null="1"/>
      </a2:KeyInfo>
      <SOAP-ENC:Array id="ref-9" SOAP-ENC:arrayType="xsd:ur-type[1]">
         <item href="#ref-10"/>
      </SOAP-ENC:Array>
      <a2:KeyName id="ref-10">
         <Text id="ref-11">mykey</Text>
      </a2:KeyName>
   </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Forwarded message 2

  • From: Rich Salz <rsalz@zolera.com>
  • Date: Wed, 19 Dec 2001 20:10:28 -0500
  • Subject: Re: SOAP message style
  • To: Blair Dillaway <blaird@microsoft.com>
  • CC: www-xkms-ws@w3.org
  • Message-ID: <3C213A84.4C7ADA23@zolera.com>
I don't think it's quite that complicated.  Nothing in the XKMS data
formats requires shared references, so everything can be inlined.  (It
can also be href/id'd up the wazoo, as your example shows, but that's
the responsibility of the SOAP layer to handle.)

In my experience, the major factors that differentiate the two styles
are "limitations" enforced by RPCEncoding:
	1.  Can't use attributes for data (just meta-data)
	2.  Repeated elements (arrays) must be wrapped in a container.

If strings or complex data (structures and arrays) are aliased, and that
aliasing is significant, then you have to use href/id.  (For example, in
C:
    char *p, *q;
    p = q = "foobar";              /* aliased */
    p = "foobar"; q = strdup(p);   /* not aliased */
SOAP RPC Encoding allows you to make the two cases above explicit.)

So, for what it's worth, my encoding of Locate would be the *exact same*
as your doc-style Locate, except adding
   <TransactionID xsi:null='1'/>

>      1) Quite a bit larger, due to additional namespaces and extensive
>      use of references

Again, they COULD be, but no semantic info is lost if not, so they NEED
NOT be. SOAP message CAN be completely typed and self-describing, but
they need not be.

>      2) Includes more information about the ‘type’ of information
>      being sent, such as the explicit nil and array type attributes.

There's a bit of a debate if "xsi:null='1'" is the same as omit; ask
Andrew Layman up in your campus. :)

>      3) Uses a more complex style based on isolating multi-reference
>      values in independent elements which are then referenced by their
>      accessors.

See #1.

>      these rules). In some cases, an array element may appear as a
>      child of its accessor, but one should be prepared to handle the
>      independent element, accessor reference style shown.

Presumably any SOAP RPC toolkit could handle this, not leaving it to
XKMS to do.  From my experience, all SOAP toolkits do the full RPC stuff
(cf http://yahoogroups.com/soapbuilders for a mail list on soap
interop).

Now then, having said all that, I believe we should use document style. 
The killer reason is that you CANNOT encode an XMLDSIG document in SOAP
RPC, so using RPCEncoding would rule out being able to consider an
XMLDSIG element as part of an XKMS protocol exchange.

>      - If we add a simple integrity and confidentiality mechanism
>      based on XML Signature and XML Encryption, we’d need to be
>      cognizant of the possible message structure(s). ...  With
>      RPC-SOAPEnc you’d want to either sign a reference to the Body
>      element or an xPath selecting all the children of Body.

Why not just sign a refernece to the Locate, as with doc-lit?

	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

Forwarded message 3

  • From: Rich Salz <rsalz@zolera.com>
  • Date: Wed, 19 Dec 2001 20:26:17 -0500
  • Subject: Re: SOAP message style
  • To: Blair Dillaway <blaird@microsoft.com>, www-xkms-ws@w3.org
  • Message-ID: <3C213E39.E2C10E41@zolera.com>
Oops, I forgot the biggest reason:  RPCEncoding will be "optional" in
SOAP1.2.
	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

Forwarded message 4

  • From: Blair Dillaway <blaird@microsoft.com>
  • Date: Thu, 20 Dec 2001 10:00:07 -0800
  • Subject: RE: SOAP message style
  • To: "Rich Salz" <rsalz@zolera.com>
  • Cc: <www-xkms-ws@w3.org>
  • Message-ID: <AA19CFCE90F52E4B942B27D42349637902CDCE62@red-msg-01.redmond.corp.microsoft.com>
Rich,

Seems like we're in agreement that we should just stick with the Doc-Lit
style SOAP without some compelling reason to support the RPC-SOAPEnc
style, and there doesn't appear to be a compelling reason.   I agree
with most of your comments, but do have a different view on a couple of
key points as indicated below.

BTW, I'm leaving on vacation for 2 weeks and won't be able to continue
discussion of this topic until I return.

First, I disagree that XKMS can claim to support RPC-SOAPEncoding style
messages and also insist on a inlining style only.  The interface
between XKMS clients and servers is defined by the supported messages.
If we claim to support RPC-SOAPEnc style SOAP messages then its my
understanding we must handle messages using either inlining and
href/independent element.  The SOAP spec is clear that one can use the
href/independent element approach even for elements that aren't
multi-ref.  Since its legal to encode in either manner, the receiver
will need to accept both.  I did pick the included example to show
something of a worst case, but it was generated by a SOAP compliant
toolkit and is realistic.  I am against an approach that would try to
define a subset of the SOAP Section 5 encoding rules XKMS supports.

The fact that most SOAP toolkits support the RPC-SOAPEnc style is a big
reason this issue was raised.  But, I don't think this is an adequate
reason to support this style.  I do agree with your comments that one
has some control over the 'shape' of a SOAP message based on the object
model and toolkits being used.  But, XKMS isn't specifying object models
or toolkit behaviors.  Its only the messages and conformance to SOAP
(and ultimately XML-P) that matter.

I don't believe your statement in regards to the size of RPC-SOAPEnc
messages is correct.  You will be bringing in the SOAPEncoding
namespace, arraytype attibutes, etc. If you use this style I think you
will have larger messages.

I do agree the explicit null attributes and omitted elements have pretty
much the same semantic meaning.  My original statement was poorly
worded. The point I was trying to make was focused more on the use of
explicit array types and multi-reference elements.

Finally, to your point on XML Signatures.  I agree that use of the
RPC-SOAPEnc style does raise an issue as to how one includes an XML
Signature such as the ProofOfPossession(POP).  If you simply in-line, it
like we do in the Doc-Lit style messages, then the message would be in a
mixed SOAP style.  While legal SOAP, I think there are issues as to how
you capture this in a WSDL definition and the ease of implementation.
One option would be to move such signature elements to a SOAP header.   

That said, the more important issue with the XKMS use of XML Signature
is that it must be handled independently from the process of mapping
between some object model and the SOAP message contents.  So it really
doesn't matter if you're using a std toolkit to handle this operation
for the other XKMS data.  The reason is that the XML Signatures, like
POP, are computed over the XML being send inside the SOAP message.  For
the POP, we need the Prototype element (KeyBindingType) XML and XML
Signature SignedInfo.   Having an object model representation of the
Prototype element data does you no good.  Similarly, to verify the
signature you need the XML representation carried in the SOAP message.
You can't verify once you've passed the message through a deserializer
to map it into an object model.

Regards,
Blair

-----Original Message-----
From: Rich Salz [mailto:rsalz@zolera.com] 
Sent: Wednesday, December 19, 2001 5:10 PM
To: Blair Dillaway
Cc: www-xkms-ws@w3.org
Subject: Re: SOAP message style


I don't think it's quite that complicated.  Nothing in the XKMS data
formats requires shared references, so everything can be inlined.  (It
can also be href/id'd up the wazoo, as your example shows, but that's
the responsibility of the SOAP layer to handle.)

In my experience, the major factors that differentiate the two styles
are "limitations" enforced by RPCEncoding:
	1.  Can't use attributes for data (just meta-data)
	2.  Repeated elements (arrays) must be wrapped in a container.

If strings or complex data (structures and arrays) are aliased, and that
aliasing is significant, then you have to use href/id.  (For example, in
C:
    char *p, *q;
    p = q = "foobar";              /* aliased */
    p = "foobar"; q = strdup(p);   /* not aliased */
SOAP RPC Encoding allows you to make the two cases above explicit.)

So, for what it's worth, my encoding of Locate would be the *exact same*
as your doc-style Locate, except adding
   <TransactionID xsi:null='1'/>

>      1) Quite a bit larger, due to additional namespaces and extensive
>      use of references

Again, they COULD be, but no semantic info is lost if not, so they NEED
NOT be. SOAP message CAN be completely typed and self-describing, but
they need not be.

>      2) Includes more information about the 'type' of information
>      being sent, such as the explicit nil and array type attributes.

There's a bit of a debate if "xsi:null='1'" is the same as omit; ask
Andrew Layman up in your campus. :)

>      3) Uses a more complex style based on isolating multi-reference
>      values in independent elements which are then referenced by their
>      accessors.

See #1.

>      these rules). In some cases, an array element may appear as a
>      child of its accessor, but one should be prepared to handle the
>      independent element, accessor reference style shown.

Presumably any SOAP RPC toolkit could handle this, not leaving it to
XKMS to do.  From my experience, all SOAP toolkits do the full RPC stuff
(cf http://yahoogroups.com/soapbuilders for a mail list on soap
interop).

Now then, having said all that, I believe we should use document style. 
The killer reason is that you CANNOT encode an XMLDSIG document in SOAP
RPC, so using RPCEncoding would rule out being able to consider an
XMLDSIG element as part of an XKMS protocol exchange.

>      - If we add a simple integrity and confidentiality mechanism
>      based on XML Signature and XML Encryption, we'd need to be
>      cognizant of the possible message structure(s). ...  With
>      RPC-SOAPEnc you'd want to either sign a reference to the Body
>      element or an xPath selecting all the children of Body.

Why not just sign a refernece to the Locate, as with doc-lit?

	/r$

-- 
Zolera Systems, Securing web services (XML, SOAP, Signatures,
Encryption)
http://www.zolera.com

Forwarded message 5

  • From: Rich Salz <rsalz@zolera.com>
  • Date: Thu, 20 Dec 2001 13:25:58 -0500
  • Subject: Re: SOAP message style
  • To: Blair Dillaway <blaird@microsoft.com>
  • CC: www-xkms-ws@w3.org
  • Message-ID: <3C222D36.6070909@zolera.com>
I didn't meant to imply that XKMS should profile/subset SOAP, merely 
that it wasn't a-priori going to result in bigger messages.

Since we agree on everything else, I'll just say: happy holidays.
	/r$

-- 
Zolera Systems, Your Key to Online Integrity
Securing Web services: XML, SOAP, Dig-sig, Encryption
http://www.zolera.com

Received on Friday, 21 December 2001 06:39:16 UTC