Overview
How qualified signatures work
What a qualified signer sees during the ceremony, what happens behind the scenes, and what you get back
Private beta. Qualified signatures are available on request. See Request access.
A qualified signature takes a few more steps than a regular one, because the signer’s qualified trust service provider (QTSP) has to verify who they are and approve the signature.
What the signer sees
Open the ceremony
The signer opens the ceremony from the invitation email, or in your app if you embed it, and completes any authentication you added.
Consent, review and sign
This part is the same as for a regular signer. The signer consents to sign electronically, reviews the documents, adopts a signature and selects Finish. The qualified signature doesn't exist yet.
Confirm their identity
The ceremony shows Confirm your identity to continue and sends the signer to the provider. The provider checks who they are, for example with an identity document and a selfie, and issues a qualified certificate in their name. Then the signer comes back. A provider that already knows the signer can skip this step.
Authorize the signature
The ceremony shows Authorize your signature. The provider asks the signer to approve this one signature, with a page, a one-time code or its app. While the signer confirms in an app, the ceremony shows Waiting for your confirmation and updates on its own.
Done
SignatureAPI embeds the qualified signature in the document, and the ceremony completes.
In test mode, the sandbox worker plays the provider. It shows its own Identify yourself and Authorize your signature pages, and the ceremony shows a notice that the signature is not qualified.
Behind the scenes
SignatureAPI reaches the provider through a signing worker: an HTTPS service, run by you or by your provider, that translates SignatureAPI’s requests into calls to the provider’s API. In test mode, the hosted sandbox worker stands in for it. See Signing workers.
When the signer selects Finish, SignatureAPI asks the worker for three things, in order:
- The certificate. A PDF signature references the signer’s certificate, so SignatureAPI needs it before it can compute what to sign. If the provider must identify the signer first, the worker says so, and SignatureAPI sends the signer to the provider.
- The approval. SignatureAPI computes a digest, a short fingerprint of the exact document the signer reviewed, and asks the worker to get the signer’s approval for it.
- The signature. The worker has the provider sign the digest with the signer’s key.
The worker never sees the document, only the digest. Before embedding the result, SignatureAPI checks that the signature matches the digest and the certificate. A signature that fails the check never reaches the PDF.
What you get back
- On the recipient. The recipient’s
certificateshows the signing certificate’s subject, issuer, serial number and validity dates. - In the deliverable. A single PDF with all of the envelope’s documents, and no audit log. Each qualified signature sits in it as a PAdES signature, the standard format for signatures inside a PDF, so PDF readers list it in their signature panel.
Several qualified signers
An envelope can have as many qualified signers as you need. Each one gets their own signing session, one after another, in the order you list them. Each signature covers the document exactly as it stands at that signer’s turn, including the earlier signatures. That’s why these envelopes use sequential routing. See Envelope rules.