RE: [dss-x] Groups - Visible Signature Profile - Working Draft V5 (oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded

Hello Oscar,

 

Thanks a lot for your valuable comments.

 

I have a few more comments below.

 

Regards,

 

Ezer
Farhi | VP Engineering | ARX 

phone: +972.3.9279529 | fax: +972.3.9230864 | email:  | www.arx.com 

 

-----Original Message-----

From: 
[mailto:] 

Sent: Wednesday, April 01, 2009
5:55 PM

To: Ezer Farhi

Cc: 

Subject: RE: [dss-x] Groups -
Visible Signature Profile - Working Draft V5
(oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded

 

Hi Ezer,

 

Sorry for the delay
in the answer.

 

I agree with the list
of issues. Enough for the first version. Some comments below.

 

Regards,

Oscar.

 

 

 

  
  
_

  
  
  
 

  
 

 

  
  
 

  
  
  
   

    
    
Oscar
    Burgos Palomar

    Àrea d'assessorament i recerca

    

    Agència Catalana de Certificació - CATCert

    Passatge de la Concepció 11, 08008 Barcelona

    tel: 93 272 25 88, 93 368 31 73 - fax: 93 272 25 39

    www.catcert.cat 

    
   

  
  

  
 

 

  
  
_

  _

  
 

 

  
  
 

  
 

 

  
  
 

  
 

 

  
  
 

  
  
  
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:] 

Enviat: dimarts, 31 / març / 2009
12:50

Per a: Òscar Burgos

A/c: 

Tema: RE: [dss-x] Groups - Visible
Signature Profile - Working Draft V5
(oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded

 

Hello Oscar,

 

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

The workflow scenarios are aimed for cases were empty signature fields already
exist in the document and during the workflow steps, each user in the workflow
chain sign his/her field.

Also, in the generalized scenario it is possible to specify the configuration
of the visible signature upon an existing signature field by 

 

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

Regarding color there are many ways to define colors and I was hoping to avoid
handling colors in the first version of the profile.

 

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.

 

Thanks,

Ezer

 

Ezer
Farhi | VP Engineering | ARX 

phone: +972.3.9279529 | fax: +972.3.9230864 | email:  | www.arx.com 

 

-----Original Message-----

From: 
[mailto:] 

Sent: Monday, March 30, 2009 5:16
PM

To: Ezer Farhi

Cc: 

Subject: RE: [dss-x] Groups -
Visible Signature Profile - Working Draft V5
(oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded

 

Hi Ezer,

 

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:

§         Font

§         Size

§         Color

§         Orientation

 

 

Regards,

Oscar.

 

 

 

  
  
_

  
  
  
 

  
 

 

  
  
 

  
  
  
   

    
    
Oscar
    Burgos Palomar

    Àrea d'assessorament i recerca

    

    Agència Catalana de Certificació - CATCert

    Passatge de la Concepció 11, 08008 Barcelona

    tel: 93 272 25 88, 93 368 31 73 - fax: 93 272 25 39

    www.catcert.cat 

    
   

  
  

  
 

 

  
  
_

  _

  
 

 

  
  
 

  
 

 

  
  
 

  
 

 

  
  
 

  
  
  
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:] 

Enviat: dilluns, 30 / març / 2009
15:05

Per a: Òscar Burgos

A/c: 

Tema: RE: [dss-x] Groups - Visible
Signature Profile - Working Draft V5
(oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded

 

Hello
Oscar,

 

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.

 

Regards,

Ezer

 

-----Original Message-----

From: 
[mailto:] 

Sent: Monday, March 30, 2009 3:25
PM

To: Ezer Farhi

Cc: 

Subject: RE: [dss-x] Groups -
Visible Signature Profile - Working Draft V5
(oasis-dssx-1.0-profiles-visiblesig-wd5.doc) uploaded

 

Hello Ezer,

 

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.

 

Regards,

Oscar.

 

 

 

  
  
_

  
  
  
 

  
 

 

  
  
 

  
  
  
   

    
    
Oscar
    Burgos Palomar

    Àrea d'assessorament i recerca

    

    Agència Catalana de Certificació - CATCert

    Passatge de la Concepció 11, 08008 Barcelona

    tel: 93 272 25 88, 93 368 31 73 - fax: 93 272 25 39

    www.catcert.cat 

    
   

  
  

  
 

 

  
  
_

  _

  
 

 

  
  
 

  
 

 

  
  
 

  
 

 

  
  
 

  
  
  
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.

  
 

 

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: 
[mailto:] 

Sent: Monday, March 16, 2009 5:33
PM

To: Ezer Farhi

Cc: 

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.

 

 

 

 

  
  
_

  
  
  
 

  
 

 

  
  
 

  
  
  
   

    
    
Oscar
    Burgos Palomar

    Àrea d'assessorament i recerca

    

    Agència Catalana de Certificació - CATCert

    Passatge de la Concepció 11, 08008 Barcelona

    tel: 93 272 25 88, 93 368 31 73 - fax: 93 272 25 39

    www.catcert.cat 

    
   

  
  

  
 

 

  
  
_

  _

  
 

 

  
  
 

  
 

 

  
  
 

  
 

 

  
  
 

  
  
  
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:] 

Enviat: diumenge, 15 / març / 2009
09:52

Per a: Òscar Burgos

A/c: 

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: 
[mailto:] 

Sent: Friday, March 13, 2009 3:14
PM

To: Ezer Farhi

Cc: 

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.

 

 

 

  
  
_

  
  
  
 

  
 

 

  
  
 

  
  
  
   

    
    
Oscar
    Burgos Palomar

    Àrea d'assessorament i recerca

    

    Agència Catalana de Certificació - CATCert

    Passatge de la Concepció 11, 08008 Barcelona

    tel: 93 272 25 88, 93 368 31 73 - fax: 93 272 25 39

    www.catcert.cat 

    
   

  
  

  
 

 

  
  
_

  _

  
 

 

  
  
 

  
 

 

  
  
 

  
 

 

  
  
 

  
  
  
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.