OASIS Digital Signature Services eXtended (DSS-X) TC

Hi,

I went over the material of documents and meetings notes related to
Visual Signatures. As I understand the status is as follows:
- Uri and Konrad wrote two separate requirements documents. 
- Uri's document is more focused in managing visual signatures, while in
Konrad's document is more focused on the way this signatures are
displayed.
- There were some comments on both documents, but the key debate here is

  whether to have two separated profiles.

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.
Indeed, there are some issues such as presenting as digital signature
"string" inside the visual signature and its problem with PDF documents,
but there may be other limitations that will be raised. In this case you
can reject displaying a signature in a PDF file, but allow it in another
type of file.
- 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?  

May I suggest discussing the issue of separating the profiles in next
tele-conference?
Is there any issue I am missing in the above understanding of the
status?

Thanks,
Ezer

Hello Andreas,

Some comments below.

Regards,
Ezer



                                                

					
                                                    

        
                                                
				
                                                

                                                    
                                                        
                                                        Original Message
                                                
                                                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