[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]