> DDTT.
> If you're stuck behind such a monster, then use either string 
> packing or expect that -your client- is going to have such 
> issues. That has nothing to do with the -server- which can 
> still be legitimately expected to put namespace definitions 
> where we want it to.

But if my server is behind such a firewall - for example if my
institution runs such a firewall (which will become increasingly likely
- especially with commercial institutions), then it will effect anyone
accessing my server.

> As I understand it, you have to wrap the entire thing in a 
> <Signature> element, then you have another service which 
> checks the signature, unwraps it and returns the original 
> xml?  And this is -required- to return the canonical form?

No - you add a signature digest in the SOAP header but you don't change
the XML tree (but possibly the serialized XML) of the SOAP:body - that
way any client can still understand the response but a WS-Security aware
will be able to check the signature. However part of this process is to
convert the message part you are signing to (exclusive) canonical form.
An example of a signed SRW response below (as I'm signing the whole
response, I have to move all namespaces up to SRW:searchRetrieveResponse
- in this case I've used string packing to avoid moving the record
namespaces).

Actually the signing bit needed actually send canonical XML for the bit
it signs, but it probably will.


>You could have a client behind a firewall that turns the 
>message into morse code and transmits it via ham radio 
>for all the server and the protocol specification could care.

And if you are using something like XOP (optimised binary transmission
of XML), something like this may indeed be happing. But such a thing
would transmit the XML tree *not* the literal XML (XOP certainly encodes
the XML tree rather than the literal XML), so the thing at the other end
converting back from morse code to XML will render the same XML tree but
not necessarily the same literal XML.

As the client and server have no control over what might happen to the
literal XML in transit. XOP routers, XML over morse routers etc are only
required to preserver the XML tree in transit not the literal XML text.
So an SRW client cannot rely on anything intrinsic to the literal XML
over the XML tree, unless it has full control over the route from server
to client. This is why signing needs an canonical form.

> But the whole reason we're using the XML flavour of 
> abstract-tree-that-you-represent-as-a-stream-of-bytes
> rather than (say) BER-encoded GRS-1 is to make a world where 
> this kind of hack can work. 

This kind of hack has never worked (properly) - in XML you have
namespaces, Entities and other such references which will break this
kind of hack - and even when this kind of hack does work then it is
definitely regarded as *bad* practice (far worse than putting entities
in the root elements, which is both common practice and canonical form).

Incidently, it was interoperability problems cause by "laziness" (SOAP
tools which broke if the namespace prefix wasn't the string "SOAP", for
example) that motivated the WebService Interoperatbility profile work...

> it seems at best rude for SRW 
> servers or hypothetical intermediaries to build XML which, 
> while technically legal, spoils this property.

These are not hypothetical imtermediaries - these are real products you
can buy today (http://www.reactivity.com/products/index.html,
http://www.xtradyne.com/products/ws-dbc/ws-dbc.htm). Such products will
become increasingly common as the indutry worries about security.

We could take the DDTT approach - but do we want to position SRW in a
way that means SRW servers have trouble supporting WS-Security; SRW
servers wo'n't work behind WebService firewalls; accepted XML bad
practice is SRW good practice?


Matthew




Sample signed SRW response

<SOAP:Envelope xmlns:SOAP="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:wsse="..." xmlns:wsu="..." xmlns:ds="...">
  <SOAP:Header>
    <wsse:Security>
      <wsse:BinarySecurityToken ValueType="...#X509v3"
EncodingType="...#Base64Binary" wsu:Id="X509Token"> 
MIIEZzCCA9CgAwIBAgIQEmtJZc0rqrKh5i...
</wsse:BinarySecurityToken>
      <ds:Signature>
        <ds:SignedInfo>
          <ds:CanonicalizationMethod
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
          <ds:SignatureMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#rsa-sha1"/>
          <ds:Reference URI="#myBody">
            <ds:Transforms>
              <ds:Transform
Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/>
            </ds:Transforms>
            <ds:DigestMethod
Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"/>
            <ds:DigestValue>EULddytSo1...</ds:DigestValue>
          </ds:Reference>
        </ds:SignedInfo>
        <ds:SignatureValue> 
BL8jdfToEb1l/vXcMZNNjPOV... 
</ds:SignatureValue>
        <ds:KeyInfo>
          <wsse:SecurityTokenReference>
            <wsse:Reference URI="#X509Token"/>
          </wsse:SecurityTokenReference>
        </ds:KeyInfo>
      </ds:Signature>
    </wsse:Security>
  </SOAP:Header>
  <SOAP:Body wsu:Id="myBody">
    <SRW:searchRetrieveResponse xmlns:SRW="http://www.loc.gov/zing/srw/"
xmlns:DIAG="http://www.loc.gov/zing/srw/diagnostics/">
      <SRW:version>1.1</SRW:version>
      <SRW:numberOfRecords>2</SRW:numberOfRecords>
 
<SRW:resultSetId>8c527d60-c3b4-4cec-a1de-1ff80a5932df</SRW:resultSetId>
      <SRW:resultSetIdleTime>600</SRW:resultSetIdleTime>
      <SRW:records>
        <SRW:record>
 
<SRW:recordSchema>info:srw/schema/1/mods-v3.0</SRW:recordSchema>
          <SRW:recordPacking>string</SRW:recordPacking>
          <SRW:recordData>
            &lt;?xml version=&quot;1.0&quot;
encoding=&quot;UTF-8&quot;?&gt;
            &lt;mods xmlns:xlink=&quot;http://www.w3.org/TR/xlink&quot; 
 
xmlns:xsi=&quot;http://www.w3.org/2001/XMLSchema-instance&quot; 
               xmlns=&quot;http://www.loc.gov/mods/&quot; 
 
xsi:schemaLocation=&quot;http://www.loc.gov/standards/mods/mods.xsd&quot
;&gt;
              &lt;titleInfo&gt;
                &lt;title&gt;Sound and fury : the making of the
punditocracy /&lt;/title&gt;
              &lt;/titleInfo&gt;
              &lt;name type=&quot;personal&quot;&gt;
                &lt;namePart&gt;Alterman, Eric.&lt;/namePart&gt;
                &lt;role&gt;creator&lt;/role&gt;
              &lt;/name&gt;
              ...
          </SRW:recordData>
          <SRW:recordPosition>1</SRW:recordPosition>
        </SRW:record>
        <SRW:record>
 
<SRW:recordSchema>info:srw/schema/1/diagnostic-v1.1</SRW:recordSchema>
          <SRW:recordPacking>string</SRW:recordPacking>
          <SRW:recordData>
            &lt;diagnostic&gt;
            &lt;uri&gt;info:srw/diagnostic/1/68&lt;/uri&gt;
            &lt;details&gt;Not authorised to send record&lt;/details&gt;
          &lt;/diagnostic&gt;
          </SRW:recordData>
          <SRW:recordPosition>2</SRW:recordPosition>
        </SRW:record>
      </SRW:records>
      <SRW:diagnostics>
        <DIAG:diagnostic>
          <DIAG:uri>info:srw/diagnostic/1/59</DIAG:uri>
          <DIAG:message>Result set created with valid partial results
available</DIAG:message>
        </DIAG:diagnostic>
      </SRW:diagnostics>
    </SRW:searchRetrieveResponse>
  </SOAP:Body>
</SOAP:Envelope>