Signature levels: SES, AES, QES
This is SES, and only SES. AES and QES are coming soon, in the next wave of the product.
A simple electronic signature under Regulation (EU) 910/2014: admissible, with the evidence trail described in What the signer sees to support it, and not an advanced (AES) or qualified (QES) signature. No qualified certificate belonging to the signer is involved, and nothing about who signed is cryptographically attested.
Until they arrive, asking for "level": "AES" or
"QES" is refused with SIGNATURE_LEVEL_UNAVAILABLE, never
quietly served as SES. Under eIDAS those are three different legal objects —
at QES the burden of proof reverses — so being handed the weaker one while
believing you hold the stronger is the one failure this service will not
produce.
Each level is also something your organisation holds. SES is included with the signature
product; if a call asks for a level your organisation does not hold, it is refused with
FEATURE_NOT_ENABLED and details.feature set to
signatureSes, signatureAes or signatureQes — the
platform’s own “coming soon” for AES and QES is answered first and is a different
sentence. GET /api/v1/usage lists what you hold.
The seal is a different thing from the signature
A signed document can also carry a qualified electronic seal and a qualified timestamp. Both are available (2 credits, 6 with the timestamp) to every organisation that is not a test organisation; the seal says the file came from DoConure and is unaltered, not who signed (Qualified seal and qualified timestamp). Neither changes the level above, and the confusion between the two is worth spending a paragraph on, because the document you are comparing us against probably has exactly this shape.
| Whose act it is | What it asserts | |
|---|---|---|
| Signature | a natural person | this person agreed. SES: admissible, and if challenged the evidence trail is what supports it |
| Seal | a legal person — us, the service | these bytes left this organisation in this form and nobody has touched them since (eIDAS Art. 35). It says nothing whatever about who signed |
| Timestamp | an independent authority | these bytes existed at this hour (eIDAS Art. 41) |
What a seal buys is that the proof stops depending on us. Today the claim "this is the document that was signed" is a hash in our database — sound, and it is us vouching for our own record. A sealed PDF makes the same claim verifiable in Acrobat, offline, by someone who has never heard of us, for as long as the file exists.
Two switches, and what each combination produces
| Asked for | PAdES profile | What it is worth |
|---|---|---|
| neither | null | The ordinary signed PDF. Verify it through our /verify page. |
| timestamp only | — | Refused with TIMESTAMP_REQUIRES_SEAL (1012). The timestamp is an option of the seal and is never applied on its own. |
| seal only | B-B | Origin, until our sealing certificate expires — after that the signature can no longer be validated. Cheapest, and the one with an end date. |
| both | B-T / B-LT | Origin and time. B-LT embeds the validation material, so it keeps verifying after the certificate expires. This is what you want for anything you must still be able to prove in ten years. |
Read padesProfile from the completed envelope.
It is reported rather than implied, precisely because B-B and
B-LT do not age the same way and the difference is invisible
when the file is new.
Once they are offered, you will send "seal": true and/or
"timestamp": true in the envelope's settings. Both are
optional and tri-state: omit them and the organisation's own setting decides.
Until then leave them out (or send false): true is
refused as above.
Where level is set:
Compose and sign, in one call or
Signing on its own. Full error
table: Outcomes and error codes.