When you build legal signing on top of our platform, you are trusting us with sensitive documents and real identities. Wthaiq is a documentation and evidence authority for transactions and contracts, built on the principle of defence in depth. Encryption for every connection, least-privilege authentication, strict data minimisation, documented Egyptian legal standing, and availability we target at 99.9%.
We do not rely on a single security control. Our layers intersect — encryption, authentication, data minimisation and legal standing — so breaching one layer is not enough to expose your documents or your signers' data.
All your data travels over a channel encrypted with TLS 1.2+. After that, access is limited to the holder of a valid key or an authorised role, and no one else.
Every document has a hash SHA-256 and a tamper-proof chronological audit trail. Any change, even of a single bit, breaks the hash and is detected immediately on verification.
Regular off-server backups and an incident response plan, targeting 99.9% availability. And a public status page that shows the current state live.
We protect data as it crosses the network and as events are delivered to your servers. And we seal every completed document with a fingerprint and a digital signature that expose any later change.
Every connection to our APIs and signing pages goes over TLS 1.2 or later exclusively, so no sensitive data travels over an unencrypted channel.
When signing completes we build a record and sign it with an asymmetric signature using Ed25519. Any party can verify it with our published public key, without coming back to us.
Every document has a cryptographic hash SHA-256 They are recorded in the audit trail and the completion certificate, revealing any later change however slight.
Every event we send to your servers is signed with the header Wthaiq-Signature via HMAC-SHA256 with your secret key, together with a timestamp to check freshness.
We keep signing keys and API keys separate from usage data. And we manage each of them through a clear lifecycle covering creation, rotation and revocation, without exposing them in the logs.
The time of signing is fixed with a timestamp RFC 3161 from a TSA server, and it is embedded inside the digital signature so that it holds up long term at the PAdES-LTA level.
HMAC-SHA256 over "the timestamp + the raw request body". Then compare the result with a constant-time comparison via hash_equals, and reject any request whose time difference exceeds 300 seconds.No one reaches your data without a valid key and a defined role. Keys for systems, passwordless human sign-in, and fine-grained team roles.
Two separate types: sk_… A fully privileged secret key for the server only — there is no test mode, so it is live from creation and is genuinely billed. Andpk_… publishable, safe to expose in the browser, locked to your domains (allowed_origins), and limited to a fixed set of paths. The type is determined by the key prefix alone.
Every key and role is granted the narrowest scope possible to do its job. No excess privileges, so the impact of any leaked key is confined to the narrowest limits.
Create new keys and revoke old ones at any time with no service downtime. Two keys can run in parallel during the transition, after which the previous one is revoked safely.
Every key carries a name, an identifying prefix and a last-used date last_used_at, so you can monitor active and idle keys and revoke any suspicious one immediately.
Your team members sign in to the dashboard with a one-time code OTP sent to their email, so there are no permanent passwords to leak or be reused.
Distribute permissions across clear roles, so each member sees only what their role covers and nothing beyond it.
sk_… Server-side secrets only. For signing embedded in your interface, use a publishable key pk_… locked to your domain, or request a short-lived session token from your server via signing_session instead of exposing the key.We adhere to data protection principles. We collect only what the service needs, we set a retention period for every piece of data, and we sign a data processing agreement on request.
Your documents are tied to your account alone, so no other account can browse or search them. And a signer reaches only the document they have been asked to sign.
We store The identity verification result and decision (approved/rejected), not the raw identity images. We keep the minimum that proves legal standing, and no more.
Each data type has a defined retention period appropriate to its legal purpose. Data is deleted or anonymised once that purpose ends, in line with a published policy.
We provide a data processing agreement (DPA) to enterprise customers on request, setting out the controller and processor roles and the obligations of each.
Built on the principles of personal data protection: a specified purpose, minimisation, security and the rights of data subjects. We are committed to complying with the applicable requirements.
We use a limited number of trusted sub-processors, and we disclose them transparently, together with the precise purpose of each.
Identity verification with an official document and a live face match. We receive the verification decision, not the raw identity images.
Processes subscription payments securely, without card data passing through our servers.
A trusted timestamp under RFC 3161 that proves the moment of signing and is embedded inside the digital signature.
Signing technically is not enough; the signature has to hold up before the courts and the regulators. Wthaiq is a documentation and evidence authority for transactions and contracts, and its legal framework is explicitly Egyptian.
The work is based on Egyptian Electronic Signature Law No. 15 of 2004 and its executive regulations, under the supervision of the Information Technology Industry Development Agency (ITIDA).
We are not a certification authority and we do not issue certificates. Where someone signs with their own token, we embed their signature inside the file and preserve it with its chain and its timestamp. The certificate is issued by their licensed authority, not by us.
We apply the full PAdES ladder to the embedded copy. It starts at B, moves to T with the timestamp, then LT with the validation material, all the way to LTA with an archival timestamp that keeps the legal standing intact for many years.
Every event is recorded chronologically — opening, viewing, verification and signing — together with the IP address and the user agent, in a log that cannot be altered retroactively.
Hash SHA-256 embedded in every signed document, so any later change breaks the hash and shows immediately as the status modified during public verification.
Every completed document has a public reference code WTQ-XXXXXX It lets any party confirm its integrity and its parties through Verification page without an account.
We target 99.9% availability through off-server backups and an incident response plan. And graceful degradation keeps signing running when any supporting service goes down.
We take a full copy of the database and upload it to cloud storage separate from the server, so a server failure does not take the copy down with it.
We check the integrity of every file as soon as it is created and reject an incomplete one before uploading it. And an on-demand verification tool imports the copy into a separate database and compares its tables and rows against the original.
A documented response plan with clear roles and escalation, including notification of the affected customers and a post-incident analysis for every material incident.
If the timestamping or LTV service is temporarily unavailable, signing continues at the lowest valid level and is then upgraded automatically once the service returns.
A summary of the core controls and their status. "Enabled" = in place today, "Committed" = a principle we apply and are working to document, "Target" = a percentage we strive for and do not guarantee, and "On request" = available to enterprise customers.
| Category | Control | Status |
|---|---|---|
| Encryption | TLS 1.2+ in transit for all connections | Enabled |
| Encryption | An Ed25519-signed record for every completed contract | Enabled |
| Encryption | Webhooks signed with HMAC-SHA256 | Enabled |
| Integrity | A SHA-256 hash for every document + an audit trail | Enabled |
| Access | Separate API keys (secret/publishable) + rotation | Enabled |
| Access | Passwordless human sign-in via OTP | Enabled |
| Access | Least-privilege team roles | Enabled |
| Privacy | Each account's data isolated from the rest | Enabled |
| Privacy | Data minimisation (the identity decision, not the raw images) | Enabled |
| Privacy | Alignment with personal data protection principles | we adhere to |
| Privacy | A data processing agreement (DPA) | On request |
| The law | Electronic Signature Law No. 15 of 2004 (ITIDA) | Enabled |
| The law | Embedding the customer's token signature inside the file and preserving it | Enabled |
| The law | PAdES signature up to LTA level | Enabled |
| Reliability | 99.9% availability | Target |
| Reliability | Off-server backup with an integrity check for every copy | Enabled |
| Reliability | A public status page with an automated self-check | Enabled |
| Governance | Responsible disclosure via security@wthaiq.com | Enabled |
We welcome security researchers and value their work. If you discover a vulnerability, contact us directly before publishing any details, and we commit to handling it seriously and within a published response window.
Write to our dedicated address with the steps to reproduce the vulnerability and the expected impact.
Do not publish details of the vulnerability before it is fixed, and do not use real user data during your research.
We acknowledge receipt within a response window, work on the fix and then inform you, and we appreciate responsible disclosure.
Only someone holding a valid key or an authorised role reaches your data. All data travels over a channel encrypted with TLS 1.2+, and we govern access to it by least privilege through API keys and passwordless human login. And your documents are tied to your account alone, so no other account can browse them.
No. We apply data minimisation: we store the identity verification result and its decision (approved or rejected, and the level) from the identity provider Didit, not the raw identity images. What legal standing requires is proof that the verification took place and what its outcome was, and reducing what we keep reduces what can be lost or misused.
Every event carries a Wthaiq-Signature header in the form t=<timestamp>,v1=<signature>. Compute HMAC-SHA256 over the text "the timestamp + a dot + the raw request body" using the endpoint secret whsec_. Then compare the result with a constant-time comparison, and reject any request whose time difference exceeds 300 seconds. See the implementation details on The Webhooks page.
We target 99.9% availability — a figure we strive for, not one we guarantee. We back it with off-server backups and an incident response plan. And if the timestamping service is temporarily unavailable, signing continues at a lower level and is upgraded later. Follow the automated check result and the fault log on The public status page.
Yes. The work is based on Egyptian Electronic Signature Law No. 15 of 2004 and its executive regulations, under ITIDA supervision. We are a documentation and evidence authority, not a certification authority. The strongest thing we offer on our own is signing with identity verification, with an audit trail and a fingerprint that reveals any change. And where someone signs with their token, we embed their signature inside the file up to PAdES-LTA level. For a breakdown of the legal standing levels, see The trust page.
Monitor our availability in real time on the status page, or contact our team for a data processing agreement or an enterprise security enquiry.