re: DSS and SOAP 1.2 attachment feature

["Pope, Nick" <Nick.Pope@thales-esecurity.com>]

Dear Clemens,

Just to thank you formally for your comment.  Whilst we were concerned at
making such a change at this final stage of issuing DSS v1.0, we recognised
the efficiency gains in taking this approach and so have incorporate the
capability to carry documents as SOAP attachments as an option for those
using SOAP along the lines you propose below.

Regards

Nick Pope (Co-Chair DSS)

Dear DSS Group members,

I am interested in the OASIS Digital Signature Service
specification and would like to use it in combination with the SOAP
1.2 attachment feature. This way, large binary objects could be
uploaded without the base64 encoding overhead and allowing for
efficient (streaming) processing.
Unfortunately, I didn't find SOAP 1.2 attachment feature support in
DSS. I sketched a possible way of incorporating it to DSS; probably
you could give me your opinion about it. (I know that I missed the public 
review period, sorry for that.)


SOAP 1.2 attachment feature [1] states that any secondary part
("attachment") can be referenced by a URI of any URI scheme.
However, this specification does not define an actual means by which
compound SOAP structures are represented or transmitted by a SOAP
binding. Only the following requirements are given:

1. All parts must be made available, ie. an encapsulation mechanism is
to be specified. Usually MIME is a good choice, since it is widely
implemented. 

2. A mechanism by which each part is identified using one (or more)
URI(s) must be provided. A possibility would be the swaRef type from
WS-I Attachments Profile [2], where the URI value must resolve
within the MIME package.

In DSS I would imagine an extension to the SOAP 1.2 transport binding
(or even a new MIME transport binding), with the primary SOAP message
part and the attachments encapsulated in a single MIME
Multipart/Related message (as defined in SOAP with attachments [3]).

Further, the dss:Document type could be extended to support the
employed referencing mechanism. I could imagine something like

<xs:complexType name="DocumentType">
  <xs:complexContent>
    <extension base="dss:DocumentBaseType">
      <xs:choice>
        ...
        <xs:element ref="dss:AttachmentReference"/>
        ...
      </xs:choice>
    </xs:extension>
  </xs:complexContent>
</xs:complexType>
 
Where the AttachmentReference merely references the attachment's
Content-Id MIME header in the AttRefURI attribute, which is roughly
equivalent to swaRef [2]. This way support for arbitrary encapsulation
mechanisms (as required by SOAP 1.2 attachment feature), e.g. DIME, is
guaranteed. 
Further one could include an optional digest value element to ensure
message (attachment) integrity when using WSS, for example. 

<xs:element name="AttachmentReference" type="dss:AttachmentReferenceType"/>
<xs:complexType name="AttachmentReferenceType">
  <xs:sequence>
    <element ref="ds:DigestValueType" minOccurs="0"/>
  </xs:sequence>
  <xs:attribute name="AttRefURI" type="xs:anyURI" />
</xs:complexType>

The processing could probably be done similar to what is specified for
Base64Data (3.3.4) without decoding.


Thank you,
Clemens Orthacker



[1] http://www.w3.org/TR/soap12-af/
[...] Each part is identified by one or more URIs (typically one) that can
be used to reference it from other parts. The URI(s) identifying a
part can be of any URI scheme. It is RECOMMENDED that only IANA
registered URI schemes be used.

[2] http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html
<xsd:schema targetNamespace="http://ws-i.org/profiles/basic/1.1/xsd";; 
            xmlns:xsd="http://www.w3.org/2001/XMLSchema";;> 
  <xsd:simpleType name="swaRef"> 
    <xsd:restriction base="xsd:anyURI" /> 
  </xsd:simpleType> 
</xsd:schema>

[3] http://www.w3.org/TR/SOAP-attachments 

-- 
Clemens Orthacker  Secure Information Technology Center - Austria
Tel: +43 316 873 5512                   Web: http://www.a-sit.at/


This email and any files transmitted with it are confidential and intended
solely for the use of the individual or entity to whom they are addressed.
You must not disclose, copy or rely on any part of this correspondence if
you are not the intended recipient. 
If you have received this email in error, please delete it from your system
and notify the System Administrator at Thales e-Security +44 (0)1844 201800
or mail postmaster@thales-esecurity.com