OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: DSS and SOAP 1.2 attachment feature


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/


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]