Local Processing

The Certifaction platform is privacy-first. Local processing is what makes that guarantee possible: document content never leaves your infrastructure in clear text. The Local Client — a piece of Certifaction software that runs inside your environment — handles every step that touches document content:

• reading the document,
• adding PDF signature fields,
• computing the document hash,
• generating any encryption key the document needs,
• embedding the returned signature into the PDF.

The Certifaction API only ever receives cryptographic material: hashes, metadata, and — when applicable — encrypted blobs. It never receives document content in clear text.

The PAdES signing keys are held by our Qualified Trust Service Providers (QTSPs) for all signature levels (SES, AES and QES); the Local Client never sees them. Conversely, document encryption keys never leave the Local Client.

How a signature is created

The document itself stays with the Local Client at every step. Only the hash reaches the Certifaction API, and only the hash reaches the QTSP.

When the encrypted document is uploaded

Two situations require an encrypted copy of the document to be uploaded to Certifaction:

• Digital Twin enabled — an encrypted copy is stored so it can be retrieved or verified later.
• Signature request with other signers — the encrypted document must be reachable by the people you invite to sign.

In both cases the Local Client generates a unique 256-bit symmetric encryption key for each document or signature request, encrypts the document with NaCl Secretbox (XSalsa20 + Poly1305), and uploads only the ciphertext to the Certifaction Encrypted Digital Archive. The archive holds the ciphertext; it never receives the key.

The encryption key is returned as a URL fragment appended to the document URL, for example:

https://example.com/DE6I239aEqI#zi9B6ioQcoLTCelSwsxrn0fIMPA9u6LthZCtRT7kP9c=

Per RFC 3986 §3.5, URL fragments are never transmitted in HTTP requests, so the key stays client-side even when the URL is used to fetch the document. Anyone who holds the full URL — including the fragment — has the key, and can therefore decrypt the document.

Sharing signature request URLs

The signature request URL must reach the invitees through a secure channel. You have two options:

• You distribute the URL yourself. The Local Client returns the full URL to your application; you share it with the invitees over a channel you already control (for example an existing customer portal or an authenticated messaging channel). Certifaction is not involved in the distribution.
• Certifaction distributes the URL for you. The Local Client can optionally generate a Key Encryption Key (KEK) and use it to encrypt the URL fragment. Certifaction then sends the invitees an email containing the URL with the fragment encrypted — meaning the email alone is not enough to decrypt the document. You take responsibility to hand the KEK to the invitees through a secure channel of your choice.

If you sign a document for yourself with no Digital Twin and no signature request, no document content of any kind is uploaded.

Running the Local Client

Certifaction offers several Local Client implementations. Two of them are relevant to developers integrating Certifaction:

Server mode (Local HTTP API)

Start the Local Client as a small HTTP server that exposes a Local API. Third-party applications call the Local API over HTTP to sign documents, with the guarantee that document content stays inside your environment. This is a good fit for centralized signing inside an automated document workflow.

Interactive / shell mode

The CLI can be used directly by standalone applications to sign and certify documents on the file system or through standard input and output — no library integration required.