|
Hi Juan Carlos,
thank you for you your time and effort to review the core! See my
comment inline ...
Below follow some few comments on core v2 draft 5.0:
1.Is there any relationship between the notice at the beginning of
the document identifying the number of WD ( WD 03) and the
identifier in the document name (05)? Maybe they should be the
same?
The numbering and date entries are on still my automation list. I'll
setup a manual pre-upload checklist for the meantime.
2. An indication of the day/month/year would also be good.
True!
3. In the text "Using the first protocol a client can end
documents (or document hashes) to a server and receive back a
signature on the documents. Using the second protocol a client can
end documents", I guess that the two instances of "end" should be
converted to "send".
Fixed.
4.Clause 2.4
• The prefix dsb: stands for the DSS core namespace [DSS2XSD].
I guess that dsb stands for the DSS base namespace
Fixed.
Juan Carlos, you must admit that the quality of the TC's documents
is degrading rapidly since you left ;-)
5. Clause 4.2.3.2
<xs:complexType name="DocumentType">
<xs:complexContent>
<xs:extension base="dss2:DocumentBaseType">
<xs:choice>
<xs:element name="Base64Data"
type="dsb:Base64DataType"/>
</xs:choice>
</xs:extension>
</xs:complexContent>
</xs:complexType>
Not sure about the choice having only one child element. It is
used normally for making it clear that one among different options
must be present. However there is only one option here: the
Base64Data element. Wouldn't it be more appropriate to use a
sequence (minOccurs="1" and maxOccurs="1")?
Yes, the sequence version expresses the intended structure more
obviously. And my test cases don't complain, so I changes the core
schema accordingly.
6. Clause 4.3.5.2.
This clause reuses the element ReturnUpdatedSignature. This
element was defined years ago and was mostly related to AdES
signatures which could be added unsigned attributes/properties.
Since then, ETSI ESI TC has coined a term for the process of
incorporating unsigned properties/attributes to an AdES signature:
AUGMENTATION. That was the result of lengthy discussions within
the committee, which also assessed other terms (update, upgrade,
etc). Nobody now, within the AdES world, speaks about updating a
signature for incorporating unsigned properties/attributes;
instead everybody speaks of augmenting the signature.
The DSS-X core v2.0 should align the names of the components
related with the augmentation of signatures with the terminology
that the standardization organization that defined the process has
adopted. Consequently, the name of the element should be moved to
ReturnAugmentedSignature.
The argument of keeping backwards compatibility should not apply
here: as the document states, a good number of decissions have
been made that make v2.0 incompatible with v1.0. The adherence to
the globally accepted terminology coined by ETSI is a reason good
enough to make the movement, which would avoid missunderstandings
and confussion among developers and users.
Please note that ETSI, in its profile of the dss core v2.0
deprecates the usage of ReturnUpdatedSignature and uses its own
ReturnAugmentedSignature for being fully coherent with the
terminology used in all its standards (those ones on signature
formats, signature validation and signature policy, among others).
The movement from DSS-X to this component would benefit alignment
of both specifications.
Interesting point! And I would always support alignment of wording.
But as read in core 1.0 the idea of 'upgrading' was defined a much
broader way than just augmentation: "[...] the updated
signature may be the original
signature with some additional unsigned signature properties added
to it (such
as timestamps, counter-signatures, or additional information for
use in
verification), or the updated signature could be an entirely new
signature
calculated on the same input documents as the input signature."
So if we move to 'augmentation' we would limit the functionality
here. On the other hand I would agree that the augmentation is the
major use case. I'll check back with the TC regarding their view.
Greetings from sunny Germany,
Andreas
Best regards
Juan Carlos Cruellas.
--
This publicly archived list offers a means to provide input to the
OASIS Digital Signature Services eXtended (DSS-X) TC.
In order to verify user consent to the Feedback License terms and
to minimize spam in the list archive, subscription is required
before posting.
Subscribe: dss-x-comment-subscribe@lists.oasis-open.org
Unsubscribe: dss-x-comment-unsubscribe@lists.oasis-open.org
List help: dss-x-comment-help@lists.oasis-open.org
List archive: http://lists.oasis-open.org/archives/dss-x-comment/
Feedback License:
http://www.oasis-open.org/who/ipr/feedback_license.pdf
List Guidelines:
http://www.oasis-open.org/maillists/guidelines.php
Committee:
http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=dss-x
Join OASIS: http://www.oasis-open.org/join/
--
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de
Trustable Ltd. Niederlassung Deutschland Gartenheimstr. 39C - 30659 Hannover Amtsgericht Hannover HRB 212612
Director Andreas Kühne
Company UK Company No: 5218868 Registered in England and Wales
|