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

 


Help: OASIS Mailing Lists Help | MarkMail Help

dss-comment message

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


Subject: DSS for PDF



Hello,

In a project we are looking at applying DSS to sealing (and in the future,
signing) of PDF documents.
DSS can sign arbitrary binary documents using an XML digital signature. 
However, we are looking at having the service return PDF documents with the
electronic signature added inside a modified document, conform the PDF
standard, rather than as a separate XML digital signature of the BLOB.
There does not seem to be a DSS profile to support this PDF specific type of
processing.  
Is that correct?

Some products seem to support PDF signing.  Is there any information on how
they support this in DSS?

Here's how we are thinking of using it:
The PDF document to be signed could be passed in the request as:

    <dss:InputDocuments>
        <dss:Document ID="doc2">
            <dss:Base64Data> .. </dss:Base64Data>
        </dss:Document>
    </dss:InputDocuments>

The profile name could then indicate a request to do PDF specific signing.
Or, we could extend the DSS schema using something like the following:

    <dss:InputDocuments>
        <dss:Document ID="doc2">
            <dss:Base64PDF> .. </dss:Base64PDF>
        </dss:Document>
    </dss:InputDocuments>

What would be the best approach?

An embedded signature could be requested using something like:

<dss:OptionalInputs>
    <dss:SignaturePlacement>
        ...
    </dss:SignaturePlacement>
</dss:OptionalInputs>

The dss:SignaturePlacement element from DSS 1.0 now allows a dss:XpathAfter
or a dss:XpathFirstChildOf element content.
It looks as if for PDF signing this should be extended with elements to
specify the requested type of PDF signature.
For instance, the signature field in which the document (ordinary) signature
is to be placed could be encoded using something like:

<dss:OptionalInputs>
    <dss:SignaturePlacement>
 
<dss:PDFSignatureFieldName>SecondReviewer</dss:PDFSignatureFieldName>
    </dss:SignaturePlacement>
</dss:OptionalInputs>

This hypothetical example would request a signature to be placed in the PDF
signature field name for a "second reviewer".

The signed PDF could be returned using the following structure:

    <dss:OptionalOutputs>
        <dss:DocumentWithSignature>
            <dss:Document><dss:Base64Data> ...
</dss:Base64Data></dss:Document>
        </dss:DocumentWithSignature>
    </dss:OptionalOutputs>

Or again explicitly encode the fact that the dss:Document is a PDF document:

    <dss:OptionalOutputs>
        <dss:DocumentWithSignature>
            <dss:Document><dss:Base64PDF> ...
</dss:Base64PDF></dss:Document>
        </dss:DocumentWithSignature>
    </dss:OptionalOutputs>


To encode that we would be using an extension for PDF, one approach would be
to have a distinct profile ID, like
"urn:ourproprietaryextensions:dss:1.0:profiles:pdfeseal".
But it looks as if the PDF versus other document types distinction is
orthogonal to profiles. 
PDF documents can also be signed, sealed, signed using Xades, be signed
subject to German signature law etc.  
So some way to use another mechanism than profile name seem appropriate.
Comments welcome.

Pim


 




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