A signed PDF and an action receipt are not the same artefact
Legal teams reach for electronic signature platforms when they need proof of authorisation, and then discover the model does not fit: the thing being authorised is not a document, and the signer is not reading a page.
Why can't an eIDAS signature gate an API transaction?
Because eIDAS and PAdES were built for documents a human reads. Gating a payment needs a verifier that can recompute a digest from the payload it is about to execute, in milliseconds, thousands of times a day, without calling the signature platform. A PDF signature does none of that.
- Document signature frameworks assume a human-readable document, a signing session and a low event rate. All three fail for API actions.
- Legal equivalence provisions attach to signatures on documents, not to authorisation of machine operations.
- The two coexist: documents keep document signatures; actions need a structured, canonicalised statement verified at the point of effect.
Part of AI oversight and regulation
The assumptions built into document signing
| Assumption | Holds for a contract | Holds for an API action |
|---|---|---|
| There is a document a human reads | Yes | No — the object is a structured payload |
| Signing is a discrete session | Yes | No — it is a step inside a request |
| Latency of seconds to minutes is fine | Yes | No — budget is milliseconds |
| Volume is low | Yes | No — potentially thousands per day |
| The signature is verified by a person or archive | Yes | No — verified by a service before executing |
Every row is a design decision that was correct for the problem the framework addressed. None of them survives contact with transaction gating.
What legal equivalence actually covers
Electronic signature frameworks establish that a qualified signature has legal effect equivalent to a handwritten one. That provision is about the enforceability of signed documents.
It does not say anything about whether a payment should execute. A business gating a wire transfer is not asking whether a document is enforceable; it is asking whether to move money. The legal equivalence machinery is solving a different problem.
The canonicalisation difference
Document signature formats bind a signature to a rendered document, with the presentation embedded. The point is that what the signer saw is preserved.
An action receipt binds a signature to a canonical serialisation of structured data. The point is that a verifier can recompute the digest from the data it is about to act on.
# Document signing
sign(rendered_pdf_bytes)
→ verification: is this PDF unmodified since signing?
# Action receipt
statement = { "action": "payment.release",
"beneficiary": "Acme Ltd",
"account": "****9023",
"amount": 84000, "currency": "GBP" }
sign(sha256(JCS(statement)))
→ verification: does the payload I am about to execute
canonicalise to the digest that was signed?The second form is what lets the executing service refuse when the payload differs from what was approved. A PDF signature cannot do that, because there is no PDF at the execution point.
Where each belongs
| Artefact | Right mechanism |
|---|---|
| Employment contract, lease, NDA | Document signature — that is what it is for |
| Board resolution | Document signature |
| Payment release above a threshold | Action receipt |
| Production deployment approval | Action receipt |
| Consent to specific data processing | Either, depending on whether a document is the artefact |
| Agent delegation with scope and expiry | Action receipt — the scope is structured data |
The consent row is genuinely ambiguous and worth thinking about case by case. If the artefact is a form the person reads and keeps, a document signature is natural. If it is a scope a system enforces, it is structured data.
Why not use a document platform anyway
Teams try this and abandon it, usually for the same three reasons.
- Latency. Generating a document, routing it and awaiting a completion callback takes seconds at best. A transaction gate has a much smaller budget.
- Verification dependency. Checking the signature typically means calling the platform. That makes the platform a runtime dependency for executing payments.
- No payload binding. The document says the payment is 84,000 to Acme. Nothing stops the executing system from processing a different payment; the two are not connected.
The third is the substantive failure. The others are engineering irritations.
Using both without duplication
A pattern that works: the document signature covers the agreement, and an action receipt covers each execution under it.
- A supply agreement is signed as a document — legally enforceable, human-readable, archived
- Each payment under it carries an action receipt bound to the specific payload
- The receipt references the agreement, so the chain from execution to contract is traceable
- Neither mechanism is asked to do the other's job
This is close to how the paper world worked: a signed contract in a file, and an authorised instruction for each payment. The mistake is trying to make one artefact serve both functions.
This describes signature frameworks at a general level and is not legal advice. Legal effect and evidential weight vary by jurisdiction and context; take specifics to counsel.
Why teams try it and abandon it
| Problem | Detail |
|---|---|
| Latency | Generating a document, routing it and awaiting a completion callback takes seconds at best |
| Verification dependency | Checking the signature typically means calling the platform, which becomes a runtime dependency for executing payments |
| No payload binding | The document says the payment is 84,000 to Acme. Nothing stops the executing system processing a different payment — the two are not connected |
The third is the substantive failure; the first two are engineering irritations. Legal equivalence provisions are about the enforceability of signed documents, which is a different question from whether a payment should execute.
Objections and honest limits
“Qualified signatures have the strongest legal effect.” For documents, yes, and that is worth having where the artefact is a document. It says nothing about whether a machine operation should proceed.
“We would need two systems.” You already have two problems. The paper world had a signed contract in a file and an authorised instruction per payment; conflating them into one artefact is the modern mistake.
A workable pattern: the supply agreement is signed as a document, each payment under it carries an action receipt bound to the specific payload, and the receipt references the agreement so the chain from execution to contract is traceable.
Choosing the right mechanism
- Is the artefact a document a person reads? If yes, a document signature is the right tool.
- Does a machine need to check it before acting? Then it needs a canonical form and a recomputable digest.
- What is the latency budget? Seconds or milliseconds decides the architecture on its own.
- Can it be verified without calling the platform? A runtime dependency on a signature vendor for executing payments is a choice worth making deliberately.
Terms used here
- PAdES
- PDF Advanced Electronic Signatures: the ETSI profile binding a signature to rendered PDF bytes.
- Legal equivalence
- The provision that a qualified electronic signature has the effect of a handwritten one. About enforceability of documents, not about machine execution.
- Payload binding
- Tying a signature to the canonical form of the data the system will act on, so a changed payload produces a mismatch.
Frequently asked questions
Are qualified electronic signatures inadequate? They are appropriate for documents, which is what they were designed for. Gating a machine operation is a different problem with different constraints.
Why can't a signed PDF gate a payment? There is no PDF at the execution point, and nothing binds the document to the payload the system processes. Verification also typically requires calling the platform.
What does canonicalisation change? It lets the executing service recompute the digest from the payload it is about to act on, and refuse when it differs from what was signed.
Should we use both? Often yes. Document signature on the agreement, action receipt on each execution under it, with the receipt referencing the agreement.
Where this fits in Manav
Manav canonicalises the statement with RFC 8785 and has the executing service recompute the digest immediately before acting. It sits under a document signature rather than replacing it — the contract stays a contract, each instruction gets its own receipt.