Signing PDF with AES

Prerequisites

The what? and why?

Advanced Electronic Signatures (AES) are more robust and secure than simple electronic signatures, making them suitable for contexts where higher security and legal validity are required. Here are some scenarios where AES is advisable:

Key Features of Advanced Electronic Signatures

  • Authentication: AES must use identification methods to verify the signer's identity; in our case, we propose SPID/CIE authentication.

  • Integrity: AES ensures that any modifications to the signed document are detectable through cryptographic hashing. We ensure this applying a PAdES signature to the document.

  • Non-Repudiation: AES provides undeniable proof of the signer's intent, making it legally binding. Our patented forensic signing technology, which we also apply in this case, creates a proof containing several elements gathered while the singing occurs, like, for example, all the network traffic exchange between the signer and the signing environment.

Use Cases for Advanced Electronic Signatures

  1. High-Risk Transactions

    • Financial Agreements: AES is suitable for financial transactions, such as loan agreements or investment contracts, where security and legal enforceability are crucial.

    • Legal Documents: Using AES for contracts that require high legal validity, such as property deeds or employment contracts.

  2. Regulated Industries:

    • Healthcare: AES can be used for medical records or consent forms where confidentiality and integrity are paramount.

    • Government Services: For official documents or applications where identity verification is essential.

  3. Cross-Border Transactions:

    • AES is recognised under the EU's eIDAS regulation, making it suitable for international business transactions within the European Single Market.

In summary, AES is ideal for situations requiring enhanced security, legal enforceability, and compliance with specific regulations like eIDAS. It offers a higher level of assurance compared to simple electronic signatures, making it suitable for more critical and legally binding documents.

In Web Trust, we have a workflow to manage this kind of signature, the Document Advanced API.

The provider

In order to dispense AES, you need to create an AES provider. An AES provider is a subject; it could be yourself, with which the signer will sign an extra contract, an AES contract. Also, the AES provider will be linked to the preservation environment, where the signatures will be digitally stored.

So first of all, we need to create an AES provider.

Example
curl "https://api.webtrust.kopjra.com/v1/aesProviders"
  -X POST
  -d '{"name":"Death Star Company","email":"death.star@company.com","vatNumber":"IT01234567890"}'
  -H "Accept: application/json"
  -H "Content-Type: application/json"
  -H "Authorization: Basic NjhiOTkxMjEtYWIxNC00YzUwLWFlMzItNDgzZmQ4MWVkNWJkOnlBRG1YTDZ6IzNjVm4tWURPNmJsTWkybGY0MEpNMEdUcFpLVH5+Ujc1eUNEN3ZZVGU2fmJTdTJEOUZwNHFEVjl4RWhtVmRZSw=="

As a response you should get

{
     "id": 1,
     "name": "Death Star Company",
     "email": "death.star@company.com",
     "vatNumber": "IT01234567890"
}

Now that we have the provider, we can proceed to creating the AES.

Creating the AES

Using the AES provider ID, we can create an AES. Let’s use a minimal configuration.

Example
curl "https://api.webtrust.kopjra.com/v1/aesProviders/1/aesSignatures"
  -X POST
  -d '{"signerFullname":"Luke Skywalker","signatureType":"fullname_date","locale":"en","documents":[{"name":"Death Star Self-Certification.pdf","contentBase64":"PDF_IN_BASE64","failSignature":"BOTTOM_RIGHT"}],"otp":{"sms":"+39555555555"},"authProvider": "spid","signerFiscalCode": "TINIT-CSRGGL44L13H501E"}'
  -H "Accept: application/json"
  -H "Content-Type: application/json"
  -H "Authorization: Basic NjhiOTkxMjEtYWIxNC00YzUwLWFlMzItNDgzZmQ4MWVkNWJkOnlBRG1YTDZ6IzNjVm4tWURPNmJsTWkybGY0MEpNMEdUcFpLVH5+Ujc1eUNEN3ZZVGU2fmJTdTJEOUZwNHFEVjl4RWhtVmRZSw=="

This payload is fairly similar to the one in Creating a signature, with some important differences:

  • signatureType in this case is set to fullname_date, this means that the signer won’t need to draw the signature; instead, it will be generated automatically using her full name.

For the AES, the signatureType cannot take the value none, as opposed to the SES.

  • authProvider allows you to specify the identification provider between spid and cie. If this is left empty, then the system will present a choice to the signer.

  • signerFiscalCode is the signer’s fiscal code; that will be used in the process of identification.

  • documents.signatureFieldsType applies the signature in every Acrofield of type signature inside the PDF. Note that we still specified failSignature as a fail-safe in case there were no signature Acrofields inside the PDF.

When creating an AES, it is mandatory that at least one signing field selection criteria matches or failSignature is specified. Otherwise, you will get a 400 error.

As a response, you will get a signature very similar to the one in Creating a signature. The only difference you may notice is that instead of one document, there are two, even though you specified only one. This is because the contract with the AES provider is automatically added to the signature.

When you open the fUrl you will see the following:

This is the SPID/CIE page to identify the signer. Afterwards, the following will open:

As you can see, there are two documents to be reviewed, the first the one you specified:

And the second one, the contract with the AES provider:

Once the signer ends the signing process and the conclusion process is terminated, you will be able to retrieve both (or more) of the PDFs in the signature. Those PDFs will contain valid PAdES signatures.