[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]