Hello Oscar,
A new draft version is attached that contains some of your raised issues.
Tell me if you think that there are issues that must be handled for the first committee draft.
Thanks and Regards,
Ezer
-----Original Message-----
From: oburgos@catcert.net
[mailto:oburgos@catcert.net]
Sent: Monday, March 16, 2009 5:33
PM
To: Ezer Farhi
Cc: dss-x@lists.oasis-open.org
Subject: RE: [dss-x] Groups -
Visible Signature Profile - Working Draft V5 (oasis-dssx-1.0-profiles-visiblesig-wd5.doc)
uploaded
Hello Ezer,
Thank you for reviewing my comments J. I’ve added some additional comments to try to explain better some points.
Regards,
Oscar.
|
_ |
|
|
|
|
|
|
|
_ |
||
|
|
||
|
|
||
|
|
Aquest correu electrònic, així com qualsevol fitxer annex, conté informació classificada. Queda prohibida la seva divulgació, còpia o distribució a persones diferents del seu destinatari exclusiu sense autorització prèvia per escrit de l'Agència Catalana de Certificació - CATCert. Si vostè ha rebut aquest correu electrònic per error, si us plau notifiqui-ho immediatament al remitent reenviant-lo. |
De: Ezer
Farhi [mailto:Ezer@arx.com]
Enviat: diumenge, 15 / març / 2009
09:52
Per a: Òscar Burgos
A/c: dss-x@lists.oasis-open.org
Tema: RE: [dss-x] Groups - Visible
Signature Profile - Working Draft V5
(oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded
Hello Oscar,
Thank you for the detailed review of the profile.
Please see my remarks below.
Regards,
Ezer
-----Original Message-----
From: oburgos@catcert.net
[mailto:oburgos@catcert.net]
Sent: Friday, March 13, 2009 3:14
PM
To: Ezer Farhi
Cc: dss-x@lists.oasis-open.org
Subject: RE: [dss-x] Groups -
Visible Signature Profile - Working Draft V5 (oasis-dssx-1.0-profiles-visiblesig-wd5.doc)
uploaded
Hi Ezer,
Here is the list of changes and remarks. Attached to the mail you'll find the schema and a generate view of the schema that helps to understand it.
· VisibleSignaturePolicy element: After reading the possible scenarios described in the profile document (4 different scenarios), the conclusion is that they can be summarized in two. The creation of a signature field / box from scratch, or filling an existing signature field / box. An approach to solve these two scenarios could be creating an element (as you can see in the schema) called VisibleSignatureBoxPosition that allows to choice one of the two scenarios. Linked to this change, the FieldName element should disappear and VisibleSignaturePosition has been renamed and set to mandatory, as the DSS server needs to know which is the selected scenario to apply the rules.
Ezer – Your
technical observation is right. However, after several discussions in the
committee it was decided to provide some simplified scenarios (the 3 first
scenarios) so that clients that only wish to perform a dedicated operation such
as performing a digital signature operation on a certain single field (The
Simple Workflow scenario), will be able to do so easily.
Another issue that was also decided was not to enable any “signature
field” management operation through this profile, therefore a creation of
a signature field (without signing it) is not in the scope of this profile as
well.
The Signature field item is mandatory in cases where you want to sign an
already established signature field (that already has its position as well as
the configuration of items within it), therefore I don’t think we can
omit it.
Oscar – I agree with the simplified scenarios and the issue of not allowing “signature field” management. It’s a signature creation operation with visible content, so nothing but that should be allowed. What I was proposing is a way to select whether the visible signature content should be placed in an existing placeholder (scenario 2) or to create the place to do it (scenario 1), but grouping in a single type the policies for the scenarios and the information required to perform the operation.
I forgot (deliberately) to include in the choice what is explained for the simplified workflow scenario (scenario 3), where there is a single signature placeholder in the document and there’s no need to tell the server which one should be filled. And I forgot to explain why as well…
An example of a case we are facing currently: A PDF form where a single signature field has been created for a citizen signature. The Public Administration that publishes the document wants to place a visible signature in the document to allow the citizen to trust the document source. In this case, the application that is responsible of publishing the document could request the DSS server to create this “stamp” signature, in a new box, leaving the signature field empty.
Maybe, a blank name for the existing signature field name to fill could be understood by the server as “fill the single empty field” to support scenario 3…
· DocumentRestrictionLevel element: it's an element based on PDF capabilities (in other formats, at the moment, there aren't any similar functionality). I don't know if it's the best way to do it, but I've added a type to restrict the values of this element (0-document signature, 1-certify document and don't allow changes, 2-certify document and allow form filling, 3-certify document and allow form filling and annotations). Is there a better way to do it? What will happen if other document formats allow similar capabilities?
Ezer – You are right about PDF file, however, the intention was not to limit this functionality only for PDF. I think that by providing a general number for emphasizing the restriction may be OK with other document formats in the future.
Oscar – OK, there’s no need to stick the values to PDF.
· DocumentID element: In signature creation, as the visible signature is set in a document that should be able to support embedded signatures (or at least embedding visible signature information, like the Austrian document model) the ID shouldn't be necessary... there will be a single document to sign... Taking into account that this profile should be aligned with the Multiple Verification Report, is it required in signature validation? Anyway, it is optional, so we can have a DocumentID to support multiple signature creation/validation.
Ezer – the intention was to have this as an optional in the case that several documents are submitted. Do you think anything should be changed here?
Oscar – It’s OK. No need to change it.
· VisibleSignaturePosition element: I have renamed this element to VisibleSignatureBoxPosition and allocates what I explained before regarding the scenarios. When a new visible signature box / field should be created, instead of having an abstract type, I've added a new measure type to define the same possibilities (and extended ones) to place the box in a page inside the document, using a type defined in ODF, as you stated in the document. There is also two new elements to define a border color and a background color.
Ezer – The abstract
type was intended to support documents types that have different coordination
mechanism, that may not be even geometrical. I don’t mind using your
terminology “MeasureType” in the
“GeneralVisibleSignaturePosition” type.
Regarding using colors in the profile, it is a good input. Maybe we should use
here an abstract type as well so that different color scheme used by other
types of documents can be used as well.
I will raise the issue of incorporating colors into the profile.
· VisibleSignatureBoxContent (=VisibleSignatureConfiguration duplicated) element: New name as it was using the same name as the schema root element. It is more or less the same that appeared in the profile document with some minor changes:
Ezer – I have some doubts using the wording Content since some of the content is filled by the server.
o New ItemNameEnum enumerations:
§ Custom text (to allow to insert custom information that can't be retrived neither from the signature or the certificate).
Ezer – Will be added to the profile
§ SignatureContact (PDF specific value).
Ezer – Will be added to the profile, but not as PDF specific.
§ VerificationMethod (In format types where the use of a plug-in is allowed (PDF, OOXML), the value of the plug-in identifier should be specified).
Ezer – I think this item is redundant since the document as well as its type is always part of the transaction. Do you think it is necessary to display this item?
§ VerificationService (Service URI that can be used for signature verification, for instance URL where Austrian signature can be verified).
Ezer – Do you think it is necessary to display this? Should’nt this information be part of the core?
§ ItemPosition it's using the same types defined for signature box / field placement.
Ezer – I think it should be abstract type as well. I thought to allow using percentage in this case. I accept to use the defined “MessureType” instead of “coordinate”
o New ItemValue type. Three possibilities to define the value: text, base64 and URI.
Ezer – I will also add the date-time item here as well. The date-time string format will be an attribute of this type.
Oscar – I agree with you, date-time value type is needed instead of an ItemNameEnum.
o New ItemFormat where it is possible to define for each item: text orientation, font, size and color.
Ezer – See my remark regarding colors above. I think that using text orientation is beyond the scope of a visible signature, however, I will raise that to the committee tomorrow.
o Attributes: there is an open point with the includeCaption attribute (I've defined the includeCaption element as an attribute). Where will be defined the caption for each Item enumeration? And there's a new attribute named ServerSideValue that overrides the value specified in the request with the value provided by the DSS server (DSS server fully supports retrieving information either from the signature or the signing certificate).
Ezer – I think that enabling the client to define the text of the caption is also too much of a burden to the client. I will raise that as well.
And the last thing: From my point of view, I don't see the use of this profile for validation requests. The aim of using visible signatures in a document is to allow human beings to better understand the digital signature always relying on the software able to understand the visible signature information that contains. So, it is this software or an external service, that should provide this information using its own capabilities.
Ezer – One of the issues that were raised in the past is to allow the verification service to incorporate visible indication to the visible signature that reflects the verification status.
Oscar – If server modifies visible content, then in most document formats, signature will be broken.
There aren't a lot of changes, but I tried to explain in a detailed way (hopefully enough detailed and not too tough to read) all the changes and open questions I had on the profile.
Regards,
Oscar.
|
_ |
|
|
|
|
|
|
|
_ |
||
|
|
||
|
|
||
|
|
Aquest correu electrònic, així com qualsevol fitxer annex, conté informació classificada. Queda prohibida la seva divulgació, còpia o distribució a persones diferents del seu destinatari exclusiu sense autorització prèvia per escrit de l'Agència Catalana de Certificació - CATCert. Si vostè ha rebut aquest correu electrònic per error, si us plau notifiqui-ho immediatament al remitent reenviant-lo. |