[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
Hello Oscar,
Thank you for the detailed review of the profile. Please see my remarks below.
Regards, Ezer
-----Original Message-----
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.
· 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.
· 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?
· 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.
· 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.
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.
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.
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]