[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss-x] Groups - Visible Signature Profile - Working Draft V5 (oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded
Thanks a lot for your valuable comments.
I have a few more comments below.
Farhi | VP Engineering | ARX
Sorry for the delay in the answer.
I agree with the list of issues. Enough for the first version. Some comments below.
Let me try to list all your raised issues. Please add to the list all issues that I am missing.
1 – Enabling the client to add a new signature field and sign it when a document already has an empty signature field
Ezer: This issue is
handled in the last draft by using the generalized scenario. When using this
policy, if a signature field is not specified or the specified signature field
does not exist in the document, a newly signature field will be created and
Oscar: OK, now our real case could be supported as well.
2 – Item format should include color and orientation in addition to the existing attributes.
Ezer: I saw in your
example using orientation for the whole visible signature. Regarding color I
think it is much to detailed for a first version of the profile. I think for a
start we should go with the orientation, but in the overall visible signature
level (like captions).
Oscar: If it helps, I agree with you that in the first version all the details of presentation could be done in the overall visible signature level. Regarding colors, you’re right that there are other ways to describe a color, instead of RGBa, but I was proposing what ODF is currently using (Maybe we have problems with other color schemes and I’m not an expert on this, so I don’t know if there’s any conversion method).
Ezer: I think that ODF color is based on a color name. Would you agree that in the first version only orientation will be dealt and that currently the color will not be
Handled in the protocol (for example, the server will determine the colors).
3 – Additional information passed for an item: Item Value Source
Ezer: I assume that for every item you can decide in advance what is its source. Can you give me an example of an item that its value can be both determined by the server or client?
Oscar: For example custom text could have a predefined value or client value, signatureReason could be a client value or the commitment value as a signed attribute present in the signature (in the case of EPES signatures).
Ezer: I agree for the cases you mentioned that both client and server can determine a value for a certain item. But I would say that it is up to the server implementation to define whether it accepts the value of the client or override it with its own value. I would postpone explicitly specifying in the protocol that the client is not permitting an override of the server of the value.
If you have more issues, please add them to the list.
Farhi | VP Engineering | ARX
The example I was referring is this one (there is no creation operation as a side effect):
A PDF form where a single signature field has been created for a citizen signature. So, this is the document that will be sent to the DSS server (a document with an existing signature field). The Public Administration that publishes the document wants to place a visible signature in the document to allow the citizen (the one that will sign the current existing field) 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 existing signature field empty. There’s a single (visible) signature creation operation.
You are right that the document could already have both signature fields created, but this is not what our clients are requesting. They are in charge of preparing the form and the business (citizen) signature fields. And what they request is a signature that allows the document to be trustable. That’s what we want to offer them as a DS Service.
The way to describe this scenario and all of the rest could be a type with a choice between new signature field or an existing signature field. The only open point in the choice is how to support the simple workflow scenario, where a single signature field exists and there’s no need to tell the identifier of the field to sign (my suggestion was a blank value). At least in PDF format, information to display is not predefined. There’s always the chance to select a user signature appearance when creating the signature. So, summarizing:
· Where to place visible signature info: existing field (name/blank) / new field (coordinates, page number, … )
· Info to display: list of allowed enumerated values containing:
o Item name
o Item value source
o Item Position in signature field.
o Item formatting:
Thanks for the example.
The scenario that you describe involves creating a second signature field while signing on the first signature field. This is why you should like to have the position information be part of the newly generated signature field, while the displayed content is part of the existing signature field.
I have some remarks:
- I have not seen any such scenario. I think that in the common scenario there would be two signature fields in the original document.
- I think that such a scenario is complex to describe in the profile and it makes it hard to differentiate between the existing signature field and the newly generated one.
- It will be much clearer to support a creation of an empty signature field than have a signature operation creates a signature field as a side effect.
Thanks for including some of the raised issues in the profile.
At this moment, after reading again our last discussion, I still think that there is a point that could be improved in the profile (Sorry to insist again in this topic J): the scenario based model.
From our experience (we currently support this kind of operations), it could be easier for a server to process single concrete instructions (create a new signature and … place visual information in a box, fill an existing box, … ) rather than preconfigured scenarios and provide all the required functionality. The schema is what should help the server to determine what can be done and what not without applying any other logic, if it is possible (that was my idea when I first sent a different approach for the schema). An that was the reason to use a type to define where the visual signature information would be, and another type to define the content (from a predefined information types and information source), the place to display the content within the box and detailed information on how to do it (font, size, orientation, color, etc.).
Related to the example I sent you two weeks ago, where we use a stamp (it is a signature, not only text and an image). Our server signs (certificates, to allow a future user signature) GeneForm.pdf and returns GeneFormCertified.pdf. This is the scenario where a signature field already exists, but we need to create a new signature placeholder for the Public Administration stamp. It’s only a quick example I’ve prepared, using as well, text with an orientation of 90 degrees. But I think it will help to understand what I explained in previous mails.
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,
Thank you for reviewing my comments J. I’ve added some additional comments to try to explain better some points.
De: Ezer Farhi
Thank you for the detailed review of the profile.
Please see my remarks below.
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.
– 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.
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.
– 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
· 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]