[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] DSS Core WD34 pre 4
Konrad,
Personally, I think it more belongs as another choice in <Document> and call
it <TransformedDataXML> as below. However this is a question of style the
approach you describe below is OK. I'll leave the final decision to you
and Stefan.
<xs:element name="Document">
<xs:complexType>
<xs:complexContent>
<xs:extension base="dss:DocumentBaseType">
<xs:choice>
<xs:element name="InlineXML" type="dss:InlineXMLType"/>
<xs:element name="Base64XML" type="xs:base64Binary"/>
<xs:element name="TransformedDataXML"
type="dss:TransformedDataType"/>
<xs:element name="EscapedXML" type="xs:string"/>
<xs:element ref="dss:Base64Data"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
</xs:element>
<xs:complexType name="TransformedDataType">
<xs:complexContent>
<xs:sequence>
<xs:element ref="ds:Transforms" minOccurs="0"/>
<xs:element ref="dss:Base64Data"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Nick
> -----Original Message-----
> From: Konrad Lanz [mailto:Konrad.Lanz@labs.cio.gv.at]
> Sent: 01 September 2005 13:35
> To: Nick Pope
> Cc: DSS TC List
> Subject: Re: [dss] DSS Core WD34 pre 4
>
>
> Hi Nick,
>
> Nick Pope wrote:
>
> >[...]
> >However, it is not so clear from viewpoint of an XML signature
> being created
> >against a Binary file which is currently carried in Base64Data.
> >
> In the case of a Binary file which is currently carried in
> <dss:Base64Data> having an external-uri this is perfectly valid as long
> as no transforms/canonicalization are to be applied as it will be signed
> binary. Other wise an error will be thrown as it is not parseable.
> For a same-document uri this is also valid if <dss:IncludeObject> is
> used (e.g. include a base64 encoded Image as a <ds:Object>) again if no
> transforms/canonicalizations are to be applied .
>
> >Whether
> >this is in "document or "transformed document."
> >
> >
> However a Binary file which is currently carried in <dss:Base64Data>
> should not be a Document as we decided to not parse <dss:Base64Data>, if
> it is a parseable document one should use <dss:Base64XML> instead.
>
> >I would suggest that TransformedData be another case of <XMLData>?
> >
> I'm not sure if I understand what you mean by <XMLData> as we removed it
> and replaced it with <dss:InlineXML>
>
> Did you probably mean to add the <ds:Transforms> to <dss:Base64Data>?
> If yes this is possible, but I'd rather go for using
> <dss:TransformedData> to support client-side transforms plus server-side
> hashing as this is clearer than using <dss:Base64Data> for this.
>
> >However,
> >I can live the 2nd suggestion.
> >
> >I would prefer keeping HashData as it is in WD34.
> >
> >
> Good, so let's suggest the following to the TC.
>
> Let's leave <dss:DocumentHash> as it is and add a new Type called
> <dss:TransformedData>, which is to be used for complete client-side
> transforms with server side Hashing.
>
> <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>
>
> Let's 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>
>
> best regards
>
> Konrad
>
> >[...]
> >
> >
> >>-----Original Message-----
> >>From: Konrad Lanz [mailto:Konrad.Lanz@labs.cio.gv.at]
> >>Sent: 29 August 2005 11:53
> >>To: Nick Pope
> >>Cc: OASIS DSS TC
> >>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]