[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: review comments
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]