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: Fw: [dss-x] Visual Signatures profile


Hi Pim !

>  I.e. the action of adding, deleting signature fields would not have to 
> be
>  part of the core PDF related functionality.
I perfectly agree !


>  Issues/comments:
>  -  A DSS client may not have any understanding of PDF.  It should be
>  able to issue a request like "Seal this document, unless it already 
> has a valid seal"
Can't think of a client working with a PDF and facing the need to sign 
it, if it doesn't what a PDF is about ?

>  -  A client should be able to send a PDF document a receive a list of 
> all
>  signatures, signature fields and their status. The request would be
>  something like "Tell me who, if anyone, signed this document and 
> validate
>  their signatures".  The response would be something like:
>  "Document is sealed by <DSSserver>, the <Employer> field is signed by
>  <Signatory> and that signature is valid, the <Employee> field is not 
> yet
>  signed"
Yes, verification maybe a bit more detailed compared with simple CMS 
signatures. But the intended signature to be verified should be located 
by the SignaturePointer. Or does DSS verify all signatures in an XML 
document that could be found ? Guess not, but I'm not quite sure on this 
topic.

>  -  PDF has limits on the number of signatures of certain types that 
> can be
>  in a particular document (at most one MDP signature, at most two usage
>  rights signatures).  It should not be possible to put a signature in a 
> field
>  that already has a signature in it, or to add a signature if the 
> document
>  already contains a maximum number of signatures of that type)
I would like to keep the DSS server separated from too much PDF internal 
know how. We don't import knowledge special kinds of XML documents if 
DSS has just has to sign it. This guideline should be followed for PDF 
docs, too.

The PDF should be ready for signing, because signing is the business of 
DSS, not PDF authoring.

>  -  A server could link the name of a signature field to a role or to 
> an
>  individual. When signing, the server could communicate with an access
>  control product, e.g. using XACML ("A requester claiming to be 
> <Person>,
>  identity authenticated by <IdP> using a SAML assertion in the DSS 
> request,
>  wants to sign this document as an <Employer>. Please check if <Person> 
> is a
>  member of the <Employer> group").
Would like to call this 'business requirement proliferation'. Doesn't 
smell like a DSS issue ..

Greetings

Andreas

___________________________________________________
Andreas Kühne
phone: +49 177 293 24 97
mailto: kuehne@trustable.de


Trustable Ltd.
Niederlassung Deutschland
Ströverstr. 18 - 59427 Unna
Amtsgericht Hamm HRB 5868

Directors
Andreas Kühne
Heiko Veit

Company UK
Company No: 5218868
Registered in England and Wales


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