Often the use of a multi-tenanted cloud service does not suit large organisation need for control over their documents, security policies and system availability. It’s important the full solution capability can be deployed internally on the organization’s own systems. Even if not required initially it should be possible to migrate in future.
This will be true if standard PDF signatures (ISO 32000-1) are used which are verifiable in Adobe® Reader. Check also if ISO 19005 PDF/A format for long-term archiving is also supported if your documents need to verifiable in many years to come.
This is important for non-repudiation regardless of whether the e-signing happens on the server or locally on the client-side.
Signing on the server is usually easy, but true EU Qualified Digital Signatures currently require a Secure Signature Creation Device (SSCD) and in future a Qualified Signature Creation Device (QSCD)to be under the sole control of the signer. The solution must be able to use certified SSCD/QSCD devices.
These are digital signatures with a cryptographic timestamp and signer certificate status embedded inside (using OCSP or CRLs), and do not expire once the signer’s certificate is no longer valid. Standard ETSI PAdES format should be used for interoperability with PDF Reader. Latest ETSI PAdES Parts 1, 2, 3 and 4 must be supported.
This ensures an automatic trust when the documents are verified in standard Adobe Reader with default factory settings.
This avoids the possibility of e-signing potentially fraudulent intelligent documents that do not reveal all the data during signing.
For example, including whether the document can be saved locally, document open passwords and date embargos.
These templates define who the signers/reviewers are, in which order they must e-sign, where the signatures must be placed on the document, each user’s access rights, notification email contents etc. This is essential to making the life of the user easier so that these rules are not defined manually every time a document is sent out.
This allows the owner to determine when the document was opened, reviewed andsigned etc. Also intermediate versions of the document should be available if required.
Essential in many use cases where people are required to fill, sign and then return the form.
This is important as typically you don’t care who signs the document as long as they are the right role holder.
It’s inevitable that people will be on leave when an important document needs to besigned, the workflow rules must be able to handle this!
In the real world it’s not always the case that you must sign every document that is presented to you. You must be allowed to decline and then the workflow rules must define what happens next in the approval process.
This is essential for busy, non-technical, users who don’t have the time to read everything in advance.
Again non-technical users do not understand different types of certificates and cannot easily choose the correct one by them. The solution must automate the selection of the correct certificate.
It’s inevitable that people will be on leave when an important document needs to be signed, the workflow rules must be able to handle this!
Many large organizations and regulated industries have their own existing PKIs; it will be necessary that these existing credentials can be used within the document signing system.
Signature algorithms are continually being enhanced for security reasons, so it’s essential the latest crypto techniques are supported.
Typically different user communities will have different requirements on how users are authenticated before signing can take place. It’s important the architecture allows multiple options, e.g. username/password, OTP, SMS, certificates, grid authentication, etc.
This is useful where attachments of any format can be added to the PDF cover document and then the whole package is signed using standard PDF signatures.
Essential if you want users to acknowledge they have read a particular statement, or even to initial every page as proof they have not missed anything.
Often business applications need to push documents into the signing solution and get them signed off. The API should allow full document digital signature management, and include document status tracking and user account handling also.
iPad, iPhone and Android mobile devices are very common tools now, and either a native app or browser based capability should be provided.
There must be a clear ROI, it should be more cost effective than traditional paper-based approval.
Of course it is essential that the system can support multiple brands and languages depending on the user’s local context.