[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [dss] DSS Public comments
Dear all,
My comments intermixed as agreed in our last conf call.
First of all, I would like to also comment the remark made by Clemens
Orthacker.
I agree with his first remark.
He says that: "The second remark is that in order to set the MIME type
in <ds:Object> elements in the result, it would be advisable to add a
MimeType attribute to the AttachmentReference type (just as in the
Base64Data element)[1]."
I am not familiar with SOAP attachments but Konrad in his text mentions
that:
"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."
So it seems as in the SOAP attachement the MIME type is present, so I am
not sure whether Clemens' proposal would introduce some kind of
duplicity, in which case we could increment the risks of incoherences in
some request.
As for Konrad's text see intermixed below....
I must confess that I haven't had enough time for reading the two
references that Konrad mentions so I am still uncertain on the specific
appearance that attachments would have and the values in the referencing
URIs....I wonder if it would be asking too much to kindly ask Konrad if
he could send some simple example of this appearance.
I think that Konrad's proposal isolates the processing of the SOAP from
the rest of the document... but I must confess that, due to the fact
that I am not familiar with the documents Konrad references I feel a bit
uneasy, as I have made some comments even my lack of experience
(although I am not sure they are right ;-)....anyway, this leads me to
ask, would it be acceptable to put this text in an informative annex of
the core? implementors could still find material for their
implementations and we would not have introduced this relevant material
at the last moment in the normative part....just a (maybe not suitable)
proposal...
Juan Carlos.
Konrad Lanz escribió:
> 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
--->JC: I am not sure of the usage of "attach" within the sentence "the
server MUST attach a message digest.."... If my understanding of what
Konrad tries to say is correct I think it would be better to use
"include the message digest value" and leave "attach" for actual
attachments.
> <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
Would not be better:
A digest value is computed when the data is read after
the last byte has been read from the attachment. Then the server
compares the calculated ...."?
> 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>
>
Agree with Clemens: cut and paste problems.
> * 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.
>
The text does not say what happens If the RefURI attribute references
outside the same input document... need of completion.
---> So, in summary, if the contents of the attachement are xml then we
check well-formedness, and if required, parse it.
Question, I am not aware how many MIME types have been defined for XML
content... I guess that your assumption is that this would not have any
impact on the processing, wouldn't it Konrad?
> 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.
>
--> If no xml content, then just read the charater as it is and hash
it...but Konrad's text does not say anything about the note in 3.3.4...
should it be still applicable here? it explicitly mentions base64...so,
my conclusion is that this note does not apply anymore for this...should
not text say that?
> ________________________________________________________________________
>
> * 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.
---> I am not sure I like the sentence. An attachment of the document is
a special case of a dettached signature, isn't it? so, I think that it
would be better something like:
If the CMS signature is detached, there must be a single input document:
i.e. a single <Document> or <DocumentHash> element. If <Document>
contains an <AttachmentReference> element then the server retrieves the
input data as in section 6.2.1.3 step 1. d'. 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]