[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: WD 44 comments from carlos
Forwarding comments De: Carlos
Gonzalez-Cadenas [mailto: Hi all, Some comments from my first review
of the DSS Spec, following Nick’s request in that direction. I didn’t use the final version
of the document, as the OASIS workgroup server has been unavailable this
morning, and I had no local copy of the document. I’ll review the
changing parts when getting access to the server.
In the RefURI element, we have the text “This specifies the value for a <ds:Reference>
element’s URI attribute when referring to this input document. The RefURI
attribute SHOULD be specified; no more than one RefURI attribute may be omitted
in a single signing request.” It is implicit in the text that
we’re referring to XML signatures, but I suggest making it explicit to
avoid confusion. This applies also for the RefType
element.
i.
We have the text “The Document is assumed to be valid against
the first <Schema> referred to by SchemaRefs” and later “The server MUST use the schemas to identify
the ID attributes and MAY also perform complete validation against the
schemas”. If we assume that the document is
valid against the first schema, it’s difficult to find any practical case
(unless the schemas are duplicated) in which we can validate the document
against the first schema and also against another schemas included.
ii.
Apart from this topic, how do we
handle schema importing via xs:import
, we have two cases ·
The ones with no schemaLocation attribute: Imagine the case
(it’s common in the practice) of a schema inside the request that imports
other schema that is also included in the request (inline importing). ·
The ones with a schemaLocation attribute: To be able to
validate, the server should download the schema. I think the two cases should be
analyzed to see 1) if we’re supporting them and 2) how to do it. Even if
no change is done, maybe some clarification should be added to the text
i.
if we look to urn:oasis:names:tc:dss:1.0:resultminor:incorrectSignature
and also urn:oasis:names:tc:dss:1.0:resultminor:HasManifestResults
we can see that we’re using capital letters for ones and not for another
ones)
ii.
some others use more than one word
separed by semicolon urn:oasis:names:tc:dss:1.0:resultminor:inappropriate:signature
instead of, for example, urn:oasis:names:tc:dss:1.0:resultminor:inappropriateSignature
In this case, we also can’t
obtain the applicable service policy. I propose to use the same strategy,
refactor the actual <ServicePolicy> to <UseServicePolicy> and add a new
optional input / output <ReturnServicePolicyInfo>/<ServicePolicyInfo>
Here’s my proposal (note also
we can add some URIs for the Type
attribute of the AdditionalPolicy
element, and, as usual, some other types could be added in the profiles): <xs:element name="UseServicePolicy" type="UseServicePolicyType"/> <xs:complexType name="UseServicePolicyType"> <xs:sequence> <xs:element name="ServicePolicy" type="xs:anyURI"/> <xs:element name="AdditionalPolicy" minOccurs="0" maxOccurs="unbounded"> <xs:complexType> <xs:simpleContent> <xs:extension
base="xs:anyURI"> <xs:attribute
name="Type"
type="xs:anyURI"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType>
BTW, can we move
the <DocumentHash> references
in 3.4 to 3.4.1?.
I see this optional input somewhat
confusing and open to interpretation. I suggest some revision to the whole
optional input.
i.
I see possible collisions with
another ways of creating references. 1. When we have
a RefURI expression that points
to the enveloped document (by means of an appropriate ObjId): In this case, which is the
behaviour if we have createReference
asserted to true?. Creating two references?. 2. When using
<SignedReferences>: I was assuming that this optional input completely
manages the reference creation. But, in this case, we could also have two or
more references (the ones included by SignedReferences and other one included
by <IncludeObject>). If we want to preserve the priority/exclusivity of
<SignedReferences> when managing reference creation, we could add specific
wording to solve that issue.
i.
Why do we have a XMLDSig variant if
the optional input is only for XMLDSig signatures?
ii.
With respect to the text “This <Document> (or documents) MUST
include a “same-document” RefURI attribute … which references
the data to be signed” 1. Under
section 3.3 processing rules, this will force the server to create a
<ds:Reference> pointing to the enveloped document, then there’s no
need for createReference
attribute, as we’re always protecting the enveloped document (and
therefore excluding the possibility for the non-protecting case described in
the createReference definition). 2. What happens
if the referred document doesn’t have a “same-document”
RefURI? (no behaviour / error codes defined).
iii.
With respect to the text “Clients MUST generate requests in a way that some
<ds:Reference>’s URI values actually will reference the
<ds:Object> generated by the server once this element will have been
included in the <ds:Signature> produced by the server” 1. What happens
with the enveloping-but-not-protecting case?. 2. Too much
responsibility on the client side… my understanding: “okay, as we
have many ways to do it, don’t forget to use one”. I think that we
should make this easier, and harden the processing rules to avoid ambiguity.
i.
What happens if RefURI is not RefURI=””?.
ii.
Can we use <XPathAfter> and <XPathFirstChildOf> at the same
time?.
Is it planned to add a compliance
section for the protocol? Regards,
Carlos Gonzalez-Cadenas |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]