RE: [dss-x] Visual Signatures profile

["Ezer Farhi" <Ezer@arx.com>]

Hello Andreas,

Some comments below.

Regards,
Ezer

-----Original Message-----
From: kuehne@trustable.de [mailto:kuehne@trustable.de] 
Sent: Sunday, March 30, 2008 2:39 PM
To: Ezer Farhi
Cc: dss-x@lists.oasis-open.org
Subject: Re: [dss-x] Visual Signatures profile

Hi Ezer,

thanks for diving into the 'visiual signature' sea of  problems !

> My comments at this point are as follows:
> - In my opinion, I do not see a firm reason to separate the profiles.
I
> see these two documents combined together to a single profile, which
> should be more extended since you can think of additional of
information
> that can be displayed inside a visual signature.
>   
Dtmo. this area divides on not just two, but three different areas :

- a visual representation ( within the doument ) of a signature, 
embedded or detached. Usually a trust-assoiated icon like a seal or 
such. Maybe clickable to see some more informations ...

EF - The visual signature should contain also following information:
signer's name, Signature time, Reason for signing, image of handwritten
signature, and all other information as presented in Konrad's document
and others. 

- a visible signature, like a two-dimensional bar code or a 
machine-readable hex value or such.

EF - Why this class is separated from the above? The way I see this type
of information may be incompatible with cases (such as PDF documents or
others) that the digital signature of the document includes the visual
signature's content.

- all the stuff around signatures within the PDF file and the related 
issues. Visible or not.

EF - I think again, that PDF signatures or other similar existing
signatures (such as MS Office 2007 signatures) should fit into the first
classification. We should discuss whether to include non-visual
signature fields in documents. 

Sorry for complicating things, but I think these are distinct issues 
that can't be compiled into a single profile. A PDF signature doesn't 
need a visiual representation, 

EF - But Visual signatures are part of the PDF offering. I do not
understand why do you want to separate between a Visual Signature that
is displayed in a PDF file or in another file format?

 a funny 'seal' may relate to an embedded 
signature in XMLDSig format or may show a bar code field with the raw 
signature bytes, or do nothing at all ! Suh a symbol maybe displaed 
within an PDF, a Word document or a website. So don't mix all this into 
one profile.

EF - I think there are two issues that I would like to say here
- It is true that the Digital Signature "Strength" in the "bytes" of the
digital signature, but a Visual Display of some of the content that are
related to the act of digital signature are important for the acceptance
of digital signatures by organizations. If eventually the visual
signature will only include a seal, there no much point for the Visual
Signatures profile.
- Today, there is a heavy use of Visual Signatures, by organizations.
Certainly as I (ARX) see the market, between 100-200 existing
organizations use Visual Digital signatures as part of their daily
operations. I am sure that many other organizations use today Visual
Digital Signatures based on existing tools.

> - As Uri mentioned in the requirements document, there is a list of
> operation that are not related to a signature operation: create a
visual
> signature field, clear a field, remove a field, enumerate fields, ...
As
> I see it such operations should be accessed through a different method
> than the Sign Operation. Also, it may that these types of operations
may
> require different access permissions. Is it possible to define new
> operations within the DSS scope?  
>   
This PDF stuff is a very complex thing and as we can see in Uris first 
draft we introduce a lot of new methods complete unrelated to what we 
have now. I would vote for a very small set of PDF-related methods 
concentrating in signing, verification and timestamping, maybe 
encrypting. But I like to sort out all things related to PDF forms / 
fields and page positions of something. E.g. the iText lib has a quite 
impressive set of methods to deal with PDFs, I don't want to drag such 
an API into DSS !
I could think of 'sign a given signature element', 'append a signature /

timestamp element', 'verify a given signature / timestamp element'. This

will introduce enough problems to make it fit into the DSS core.

EF - If the issues of "Signature Fields" and Visual Signature structure
are introduced in the profile, we cannot avoid supplying the mechanisms
to create these fields, remove and enumerate fields in the given
document.

Greetings

Andreas