[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] DSS Public comments
Dear all, I have read the proposal about adding optional support for SOAP attachments support to the DSS core and I think this is a very good and powerful architectural feature and the DSS core could benefit a lot from it. Pope, Nick wrote: > [...] we may wish to discuss C) below some more. [...] > > C) The use of DSS and SOAP 1.2 attachments. > http://lists.oasis-open.org/archives/dss-comment/200612/msg00002.html I think it would basically only affect section 6.2 and not harm other parts of the core document I would advocate for considering the adoption of this proposal in our next meeting. The only changes needed to (WD 47) would be: * After line 377 add the text: <AttachmentReference> [Optional] This contains a reference to an attachment like SOAP attachments or similar data containers that may be passed along with the request. For details see section 6.2.1 * Add after line 387 and in the Schema to Document Type the following line: <xs:element ref="dss:AttachmentReference"/> ---------- That's all so far, the rest is to extend Section 6.2 -------- ________________________________________________________________________ * Create a new section 6.2.1 SOAP Attachment Feature and Element <AttachmentReference> ________________________________________________________________________ Applications MAY support SOAP 1.2 attachment feature [SOAPAtt] to transmit documents in the context of a <SignRequest> or a <VerifyRequest> and can take advantage of <Document>/<AttachmentReference>. AttRefURI SOAP 1.2 attachment feature [SOAPAtt] states that any secondary part ("attachment") can be referenced by a URI of any URI scheme. AttRefURI refers to such an secondary part ("attachment") as specified for the swaRef type from WS-I Attachments Profile [WS-I-Att], where the URI value must resolve within the MIME package. All parts must be made available and the encapsulation mechanism is MIME. (cf. http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html#Referencing_Attachments_from_the_SOAP_Envelope) <ds:DigestMethod> [Optional Sequence] <ds:DigestValue> These optional elements can be used to ensure attachment integrity when using WSS, for example. If these elements are supplied the server MUST attach a message digest using the algorithm given in <ds:DigestMethod> to the octet stream. A digest value is computed when the data is read. After the last byte being read from the attachment the server compares the calculated digest value against the supplied <ds:DigestValue>. If the comparison fails then a RequesterError qualified by a GeneralError and an appropriate message containing the AttRefURI is returned. <xs:element name="AttachmentReference" type="dss:AttachmentReferenceType"/> <xs:complexType name="AttachmentReferenceType"> <xs:complexType name="AttachmentReferenceType"> <xs:sequence minOccurs="0"> <xs:element ref="ds:DigestMethod"/> <xs:element ref="ds:DigestValue"/> </xs:sequence> <xs:attribute name="AttRefURI" type="xs:anyURI"/> </xs:complexType> <xs:attribute name="AttRefURI" type="xs:anyURI" /> </xs:complexType> * and add the element and type above to the schema. ________________________________________________________________________ * Create a new section 6.2.1.1 Signing Protocol, Processing for XML Signatures, Process Variant for <AttachmentReference> ________________________________________________________________________ In the case of an input document which contains <AttachmentReference> the server retrieves the MIME headers from the attachment referred by AttRefURI and reads the content's MIME type. IF the MIME type indicates that it contains XML continue with processing as in section 3.3.1 and Step 1 a is replaced with the following: 1. a. The server retrieves the data from the attachment referred by AttRefURI as an octet string. This data MUST be a well formed XML Document as defined in [XML] section 2.1. If the RefURI attribute references within the same input document then the server parses the octet stream to NodeSetData (see [XMLDSIG] section 4.3.3.3) before proceeding to the next step. ELSE continue with processing as in section 3.3.4 and Step 1 a is replaced with the following: 1. a. The server retrieves the data from the attachment referred by AttRefURI as an octet string. ________________________________________________________________________ * Create a new section 6.2.1.2 Verifying Protocol, Processing for XML Signatures, Process Variant for <AttachmentReference> ________________________________________________________________________ Perform section 4.3. Basic Processing for XML Signatures amending step 2 a. as follows: 2. a. If the input document is a <Document>, the server extracts and decodes as described in 3.3.1 Step 1.a (or equivalent step in variants of the basic process as defined in 3.3.2 onwards depending of the form of the input document) or in the case of <AttachmentReference> as described in section 6.2.1.1. ________________________________________________________________________ * Create a new section 6.2.1.3 Signing Protocol, Basic Processing for CMS Signatures, Process Variant for <AttachmentReference> ________________________________________________________________________ Perform section 3.4 Basic Processing for CMS Signatures adding the following variant 1. d' after 1. d. and before q. e.: 1. d'. If the <Document> contains <AttachmentReference>, the server retrieves the data from the attachment referred by AttRefURI as an octet string. ________________________________________________________________________ * Create a new section 6.2.1.4 Verifying Protocol, Basic Processing for CMS Signatures, Process Variant for <AttachmentReference> ________________________________________________________________________ Perform section 4.4 Basic Processing for CMS Signatures amending step 2 as follows: 2. The server retrieves the input data. (In the case of <AttachmentReference> this is done as in section 6.2.1.3 step 1. d'. If the CMS signature is detached, there must be a single input document: i.e. a single <Document> or <DocumentHash> element. Otherwise, if the CMS signature is enveloping, it contains its own input data and there MUST NOT be any input documents present. * add a Reference: [SOAPAtt] http://www.w3.org/TR/soap12-af/ * add a Reference: [WS-I-Att] http://www.ws-i.org/Profiles/AttachmentsProfile-1.0.html > Happy Christmas to everyone! Merry Christmas and Happy Holidays. Konrad
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]