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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss message

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


Subject: Re: [dss] DSS Core WD34 pre 4


Hi Nick,

Nick Pope wrote:

>I have the following major comments on the revised draft of the core.
>
>1) Client Side Transform and no server side transform
>--------------------------------------------------
>
>The situation where all transforms are carried out on the client side and
>the XML is transferred as an octet string in Base64Data could be easily
>supported if the transforms are included in the BaseDocumentType.
>
Right, however I don't think that this is a very clear way of doing this.

Furthermore if we are putting the <ds:Transforms> back to 
<dss:DocumentBaseType> again we'd need to exclude their use from all the 
other Types extending <dss:DocumentBaseType> by normative text thus 
making the core bigger.
Another problem will be, that if we transmit the last output of the 
client side <ds:Transforms> we'd also have to exclude it from being 
referenced by <dss:IncludeObject> and <dss:SignaturePlacement>. Btw. 
similar problems apply to DocumentHash as well.
Yet another problem with <ds:Transforms> in <dss:DocumentBaseType> will 
be that the assumption for <dss:Document> to be parseable will then not 
necessarily hold any more due to the client side transforms.

Thus I'd suggest to leave the <ds:Transforms> with <ds:DocumentHash>, 
but to rename <dss:DocumentHash> to <dss:TransformedData> and change 
it's Type as follows.

    <xs:element name="TransformedData">
        <xs:complexType>
            <xs:complexContent>
                <xs:extension base="dss:DocumentBaseType">
                  <xs:sequence>
                    <xs:element ref="ds:Transforms" minOccurs="0"/>
                    <xs:choice>
                      <xs:element ref="dss:Base64Data"/>
                      <xs:sequence>
                        <xs:element ref="ds:DigestMethod"/>
                        <xs:element ref="ds:DigestValue"/>
                      </xs:sequence>
                    </xs:choice>
                  </xs:sequence>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:element>

Hence allowing to either send <dss:Base64Data> or a <ds:DigestMethod> 
plus a <ds:DigestValue>.
The first allowing complete Client Side Transforms plus server side hashing.
The latter taking over the functionality of <dss:DocumentHash> (i.e. the 
client also hashes).

Alternatively we could leave <ds:DocumentHash> as it is now and add a 
new Type also called TransformedData.

    <xs:element name="TransformedData">
        <xs:complexType>
            <xs:complexContent>
                <xs:extension base="dss:DocumentBaseType">
                  <xs:sequence>
                    <xs:element ref="ds:Transforms" minOccurs="0"/>
                    <xs:element ref="dss:Base64Data"/>
                  </xs:sequence>
                </xs:extension>
            </xs:complexContent>
        </xs:complexType>
    </xs:element>

and add it to <dss:InputDocuments> as follows.

    <xs:element name="InputDocuments">
        <xs:complexType>
            <xs:sequence>
                <xs:choice maxOccurs="unbounded">
                   <xs:element ref="dss:Document"/>
                   <xs:element ref="dss:DocumentHash"/>
                   <xs:element ref="dss:TransformedData"/>
                   <xs:element name="Other" type="dss:AnyType"/>
                </xs:choice>
            </xs:sequence>
        </xs:complexType>
    </xs:element>

>[...]
>
The latter alternative from my point of view is semantically clearer.

best regards
Konrad


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