OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-x message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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

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

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

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

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

Greetings

Andreas
begin:vcard
note;quoted-printable:___________________________________________________=0D=0A=
	Andreas K=C3=BChne=0D=0A=
	=0D=0A=
	phone: +49 177 293 24 97=0D=0A=
	mailto: kuehne@trustable.de=0D=0A=
	=0D=0A=
	www.trustable.de=0D=0A=
	=0D=0A=
	Kostenlose Verifikation qualifizierter elektronischer Signaturen:=0D=0A=
	www.sig-check.de=0D=0A=
	=0D=0A=
	--=0D=0A=
	=0D=0A=
	Trustable Ltd.=0D=0A=
	Niederlassung Deutschland=0D=0A=
	Str=C3=B6verstr. 18 - 59427 Unna=0D=0A=
	=0D=0A=
	Entwicklungcenter=0D=0A=
	Kirchr=C3=B6der Str. 70e 30625 Hannover=0D=0A=
	=0D=0A=
	Directors=0D=0A=
	Andreas K=C3=BChne=0D=0A=
	Heiko Veit=0D=0A=
	=0D=0A=
	Gerichtsstand=0D=0A=
	Niederlassung Deutschland=0D=0A=
	Amtsgericht Hamm HRB 5868=0D=0A=
	=0D=0A=
	Company UK=0D=0A=
	Company No: 5218868=0D=0A=
	Registered in England and Wales =
	=0D=0A=
	
version:2.1
end:vcard



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]