OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x-comment message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Re: [dss-x-comment] Some comments on dss core v2 draft 5.0

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.

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".


4.Clause 2.4

•    The prefix dsb: stands for the DSS core namespace [DSS2XSD].
I guess that dsb stands for the DSS base namespace

Juan Carlos, you must admit that the quality of the TC's documents is degrading rapidly since you left ;-)

5. Clause

<xs:complexType name="DocumentType">
    <xs:extension base="dss2:DocumentBaseType">
        <xs:element name="Base64Data" type="dsb:Base64DataType"/>

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

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,


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 

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]