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