[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Some comments on dss core v2 draft 5.0
Dear DSS-X TC team 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?
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 5. Clause 18.104.22.168 <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")?
6. Clause 22.214.171.124.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.
Best regards Juan Carlos Cruellas.