# Contraktia signature and evidence policy Identifier: contraktia-sig-policy-v3 Version: 3 of 27 September 2026 (draft to be reviewed by a lawyer) Publisher: Contraktia, platform for preparing, signing and monitoring contracts This policy describes the electronic signature process implemented by Contraktia, the evidence it produces, how that evidence is kept and how it can be verified. Its identifier and SHA-256 fingerprint appear in every evidence file issued under this version. Compared with version 1, it also describes, where applicable, the signing of a document supplied as is by the issuing organisation (PDF file). Compared with version 2, there is a single signing code: it is sent by SMS when the issuing organisation has enabled that channel for the signature, otherwise by email, with a possible fallback to email when the SMS is not received (unless the issuing organisation requires the SMS); there is no longer a second code. ## 1. Signature level and limits - Simple electronic signature (eIDAS Regulation, Article 3; French Civil Code, Article 1367). It is neither an advanced nor a qualified signature, including when the signing code is sent by SMS: it does not benefit from the presumption of reliability provided for by Decree No 2017-1416. Its reliability is established by the items described below and, between the parties, by the evidence agreement (identifier contraktia-evidence-agreement). - The signing code received by SMS proves possession, at the time of signature, of the phone line designated by the issuing organisation; received by email, it proves control of the email address used. Neither proves by itself the civil identity of the signatory or their powers of representation. - The process is not suitable for deeds for which the law requires a specific form (notarial deed, handwritten statements, qualified signature), nor for deeds excluded from electronic form by Article 1175 of the French Civil Code. ## 2. Freezing the document - Before signing opens, the document is frozen: its content (title, parties, clauses, signatories and signing order) is recorded as a snapshot. Its SHA-256 fingerprint is computed over the canonical JSON of this snapshot (sorted keys, no whitespace). - Supplied document: when the issuing organisation has an existing document signed as is, the signed document is a PDF file. It is a checked copy of the uploaded file: the platform refuses content that could be displayed differently depending on the reader (scripts, forms, layers, embedded files, annotations, existing digital signatures…) and rewrites the file without active content; the uploaded file is kept separately and is never presented as signed. The snapshot then contains, instead of clauses, the SHA-256 fingerprint of the exact bytes of the signed file, its size and its number of pages. This file is displayed identically to every signatory, who can download it. - The frozen document can no longer be changed: to change the text (or the file), the signing campaign must be cancelled and the document frozen again, which produces a new fingerprint. All signatories of a campaign sign the same fingerprint. - Signatories sign in the defined order; each one must have an email address, otherwise sending for signature is refused. An external party is invited by an email containing their personal link; a member of the issuing organisation is notified in the application and by an email that refers them to their account, with no personal link or access code; the member who sends the document for signature and must sign first is taken straight to their signature. ## 3. Access and identification of the signatory - Member of the issuing organisation: personal Contraktia account. - External party: personal link sent by email, then a one-time access code sent to the same address. This code opens a session limited to the document; it never counts as a signature. - Agent: member signing on behalf of another member under a mandate confirmed by the principal, limited to document types and to a period. The mandate is checked at the exact time of signature and the principal is notified. - Where applicable, mobile number of an external party: it is designated by the issuing organisation (phone number of the third party's contact, read in the third party's country, which must be a mobile number of an allowed country) and frozen when the document is frozen. The signatory never enters it and cannot change it. ## 4. Signing journey 1. Reading and consent: the complete frozen document is displayed. The signatory ticks a box that is not pre-ticked, whose exact text is recorded, and accepts the evidence agreement with a second box that is not pre-ticked (version, language and fingerprint recorded). 2. Signing code: after seeing the preview of their signature and a reminder of what they are signing, the signatory requests their signing code, a 6-digit code separate from the access code. It is sent by SMS to the designated number when the issuing organisation has enabled SMS for that signature (item 3), otherwise to the signatory's address (to the agent's address when an agent acts). A single code is entered. Default parameters of the email code: valid for 15 minutes; only the latest code issued is valid; single use; at most 3 sends per address within 5 minutes and 10 sends per IP address; 5 consecutive failures block verification for 15 minutes. The code is never stored in clear text (only a keyed HMAC fingerprint is) and never appears in any log or evidence file. 3. Where applicable, signing code by SMS: when the issuing organisation has enabled it for the campaign ("if the mobile number is known" or "mandatory" setting, chosen when sending for signature) and a mobile number has been designated for the signatory, the signing code is sent by SMS to that number, not by email. Only external signatories are concerned. Default parameters: valid for 15 minutes; only the latest code issued is valid; single use; for each signature, at most 3 sends within 15 minutes and 5 sends per designated number (a correction of the number or a replacement of the signatory by the issuing organisation opens a new allowance); 5 consecutive failures block verification of that signature for 15 minutes; sending restricted to mobile numbers of allowed countries, within daily caps. The text of the SMS contains no data of the document. If the SMS does not arrive, the signatory can request a new sending within these limits. With the "if the mobile number is known" setting, they can also, two minutes after the SMS was sent (or immediately if the SMS cannot be sent), receive their signing code by email instead; this fallback, its date and its reason are recorded in the evidence and in the audit log; it is no longer offered after the issuing organisation has corrected the number. With the "mandatory" setting, no fallback is possible: the signatory can notify the issuing organisation, which alone can correct the number (reason recorded; the journey then restarts from the beginning), and no signature is possible without the SMS code. 4. Final confirmation: a separate box restates the title, the reference and the signature statement (for a supplied document, also the number of pages and the fingerprint of the file). On click, the server re-checks within a single transaction the contract status, the campaign, the signing order, the deadline, the recomputed fingerprint of the frozen document (and, for a supplied document, the fingerprint of the file read again), the consent and signing code verified less than 15 minutes earlier by the same person, on the channel used (by SMS: for the designated number; fallback to email: only if the campaign setting allowed it), the acceptance of the evidence agreement and the mandate relied upon. If any check fails, nothing is signed and the journey restarts at step 1. ## 5. Evidence recorded For each signature: declared identity, capacity and organisation; email address; type of access (account or external party); exact text and language of the ticked boxes; acceptance of the evidence agreement (identifier, version, language, fingerprint, date, IP address, browser); dates and times of consent, of sending and verifying the signing code and of confirmation; channel of the signing code (SMS or email) and, where applicable, fallback from SMS to email (date, reason, masked number); code challenge identifier (never the code); IP address and browser; signature statement; signed fingerprint; where applicable, a snapshot of the mandate. Where applicable, for the SMS code: masked number (for example "+33 6 •• •• •• 78"); cryptographic commitment to the number, equal to the SHA-256 of the text made of the salt (32 hexadecimal characters, specific to the signature) immediately followed by the number in E.164 international format; date on which the issuing organisation designated the number; dates and times of sending and verification; challenge identifier (never the code); sending provider and message identifier at that provider; known delivery status. The full number and the salt are kept by the platform with the signature request; they appear neither in the audit log nor in the evidence file given to the parties. When the code is not sent by SMS, the evidence states why (campaign setting, member of the organisation, mobile number unknown, fallback to email). Where applicable, for a supplied document: fingerprint, size and number of pages of the signed file. Dates are those of the platform's servers, in Coordinated Universal Time (UTC). ## 6. Chained audit log - Every significant action is written to an append-only audit log, specific to each organisation. - The fingerprint of each event is the SHA-256 of the concatenation of the fingerprint of the organisation's previous event (in hexadecimal, empty string for the first one) and of the canonical JSON of its content: scope, organisation, contract, actor type and identifiers, actor label, action, object type and identifier, result, IP address, browser, support access, details, date to the millisecond. Any change to or deletion of an event breaks the chain. - The evidence file includes the events of the contract's signing phase (no internal note), with the whole of their hashed content, their fingerprint, the previous fingerprint and their sequence number, together with the result of the check of the organisation's chain at sealing time and the head fingerprint of that chain. Where applicable, they include the designation of the mobile number at freezing (masked number and commitment), any correction by the organisation (with its reason), the sending and verification of the SMS code and any fallback to email, never the full number or the code. ## 7. Sealing - Once all signatures have been collected, the platform produces: the final PDF copy (frozen document, signature block with the exact statements, signature certificate); the proof.json file (frozen snapshot, evidence for each signature, mandates, audit events, references to this policy and to the evidence agreement); the PDF evidence report, readable by a non-specialist. For a supplied document, the final copy reproduces the pages of the signed file, unchanged, each with a banner ("Electronically signed", reference, shortened fingerprint, page n/N), followed by the signature page and the certificate; the signed file is added to the evidence file ("original" folder), and the file uploaded before checking, if different, is added separately and presented as not signed. - A sealing manifest (version 2) states the SHA-256 fingerprints of these three files, the fingerprint of the frozen document, the signatures, the sealing date, the signature level (code SES_EMAIL_OTP: simple electronic signature with a one-time code; the channel of the code, SMS or email, is recorded in the evidence of each signature), the identifier and fingerprint of this policy, the versions and fingerprints of the evidence agreement that were accepted, the address where keys are published, the time-stamping rules applied (standard, fingerprint algorithm, time-stamped items, whether the service was enabled at sealing, declared qualification of the authority) and the head fingerprint of the organisation's audit log at sealing time. It is signed with Ed25519 over its canonical JSON (sorted keys, no whitespace) with the platform's sealing key. - The private sealing key is generated by the platform and kept encrypted (AES-256-GCM) in its vault; it is never logged or transmitted. Each key is identified by the first 16 hexadecimal characters of the SHA-256 of its public key (SPKI, DER encoding). Public keys, current and past, are published with their validity dates. - Sealing is idempotent; a failure leaves the contract awaiting sealing, can be retried and does not alter the signatures collected. - An evidence file that has been issued is never changed. Evidence files issued under an earlier version of this policy remain verifiable under the rules in force when they were issued. ## 8. Time-stamping and anchoring - Recorded dates come from the clocks of the platform's servers. - When the time-stamping service is enabled, two RFC 3161 timestamp tokens (SHA-256 fingerprints) are requested from a third-party time-stamping authority after each sealing: one for the final PDF copy, the other for the sealing manifest. Only the fingerprint is sent to the authority. Each token is checked on receipt: fingerprint, signature of the authority, time-stamping usage of its certificate and certification chain up to the authority's root designated by the operator; the service cannot be enabled without that root. - An unavailable authority never prevents sealing: the request is automatically renewed at increasing intervals, and the operator is alerted after several failures. A token obtained after sealing (retry, or contract sealed before the service was enabled) proves that the document existed at the date it bears, not at the date of signature; it is presented as such. - Anchoring of the audit log: when the service is enabled, the platform draws up, periodically (every 24 hours by default) and at each sealing, a statement of each audit chain: segment covered, number of events, head fingerprint, root of a Merkle tree (RFC 6962) of the fingerprints of the segment's events and reference to the previous statement. The fingerprint of that statement is time-stamped by the authority, within 72 hours of its creation at the latest. A later rewriting of the log, even fully recomputed, would contradict a statement dated by a third party; the platform regularly checks that no statement is contradicted and alerts the operator otherwise. Each time-stamped statement is recorded, by the fingerprints of the statement and of the token and by its date alone, with no organisation and no content, in an append-only public log (/.well-known/contraktia-audit-anchors.json) whose entries are chained: anyone who keeps a copy can detect a later removal or change. - The tokens, the anchoring statements covering the contract's events and the proofs of inclusion of those events in the statements (fingerprints only, with no content of any other contract or organisation) are added to the evidence file as additional files, without changing the sealed items. They are listed in an index signed with Ed25519 with a published sealing key, and can be checked with the openssl ts -verify command and with the independent verifier. - The "eIDAS qualified" status of a time-stamping authority is a declaration of the operator, shown as such in the evidence file; only the authority's listing on the EU trusted list makes the time-stamp qualified. - The absence of time-stamping or anchoring (service disabled or unavailable) is visible in the evidence file and does not affect the other items. ## 9. Retention - The final copy, proof.json, the evidence report, the signed manifest, the audit log and, for a supplied document, the signed file are kept durably with the contract archive of the issuing organisation, encrypted (AES-256-GCM); the fingerprint of each file is checked every time it is read. - Where applicable, the designated mobile number and the salt of its commitment are kept with the signature request, like the signatory's email address; the full number attached to an SMS code (challenge) is erased with the short-lived technical data. - Short-lived technical data (code challenges, sessions) is purged in accordance with the privacy policy; the items needed as evidence are copied into the signature evidence at the time of signature. - Each signatory receives the final copy and the evidence report by email. The complete evidence file (ZIP) can be downloaded by authorised members of the issuing organisation and by authenticated signatories. ## 10. Verification - Public verification page (/verify): an uploaded PDF copy is compared with the sealed copies and the seal of its manifest is checked. The file is not kept. - Independent verification: each evidence file contains a standalone verifier (verify.mjs, Node.js, no dependency) and instructions to check by hand with sha256sum and OpenSSL: file fingerprints, Ed25519 signature of the manifest, match between the key and the published keys, fingerprint of the frozen document, audit log events, reference documents, timestamp tokens, anchoring statements and proofs of inclusion and, since its version 1.3.0, presence of the signed file of a supplied document and consistency of the code by SMS (masked number, commitment, dates, audit events of the verification and of the designation of the number, no signature without the SMS code the designation required, that is with the "mandatory" setting). The verifier does not trust the key included in the evidence file: it compares it with the keys published at the official address written in its code, never at an address given by the evidence file. It only takes a timestamp as established if the certification chain of the authority leads to a root that it recognises or that the user designates. The copy included in an evidence file comes from the same server as the file: the official version can be downloaded from the /seal-keys page, which publishes the SHA-256 fingerprint of each version. - SMS code in case of dispute: the issuing organisation may disclose the full number and the salt, which an administrator of the issuing organisation obtains on the platform through a reasoned action recorded in the audit log without the number; anyone can then recompute the commitment recorded in the evidence (verifier: --sms-phone and --sms-salt options) and thereby establish that this number is the one that received the code. - Public sealing keys: /.well-known/contraktia-seal-keys.json and the /seal-keys page; public anchor log: /.well-known/contraktia-audit-anchors.json. ## 11. Changes Any change to the process leads to a new version of this policy, under a new identifier. A published version is never changed. An evidence file remains verifiable under the version under which it was issued.