Architecture

How SignLayer fits together.

A hub-and-spoke design around the Signing API. Every call is a synchronous HTTPS request; there are no message queues to operate.

SignLayer platformSigning channelsSignLayer platformTrust servicesWeb app + Browser SDKDesktop app → smart cardMobile app + iOS/Android SDKITIDA remote key + OTPERP / accountingInvoices as JSONYour backendDirect API callsSigning APIIsolated PDF engineAudit log and sessionsPer-customer trust and configeInvoice ServiceHSM gatewayYour HSMPKCS#11Timestamp AuthorityRFC 3161Revocation servicesOCSP and CRLEgyptian Tax Authoritye-invoice APIsRuns on your servers or hosted by SignLayer

Arrows show who calls whom. The mobile SDKs also talk directly to ITIDA's remote signing service, which holds the user's key.

Architecture

Component responsibilities

ComponentOwnsDoes not own
Signing APISignature formats, trust lists, timestamps, revocation checks, per-customer config, audit logPrivate keys (they stay in tokens, ITIDA and HSMs)
eInvoice ServiceETA canonical format, ETA API calls, batch rulesSignatures (delegated to the Signing API)
HSM gatewayPKCS#11 sessions with the HSMWhich customer may use which key (the Signing API decides)
Desktop appAccess to the person's token, PIN entry, approved-website listDocument formats
iOS and Android SDKsPDF preparation on the phone, visible stamp, OTP flowThe user's key (held by ITIDA) and the final embedding (Signing API)

Architecture

Signing flows

Smart card in the browser

  1. Your page asks the Signing API to prepare the PDF or data.
  2. The Signing API returns what must be signed.
  3. The desktop app asks for the PIN and signs on the token.
  4. Your page sends the signature back; the Signing API returns the signed document.

Phone with a remote certificate

  1. The mobile SDK gets the user's certificate from ITIDA.
  2. It prepares the PDF and stamp on the phone.
  3. The user confirms with an OTP; ITIDA signs the hash.
  4. The Signing API embeds the signature and the SDK validates the result.

Company seal

  1. Your system sends the PDF or data to the Signing API.
  2. The Signing API asks the HSM gateway to sign.
  3. The HSM signs with the seal key; the key never leaves it.
  4. The Signing API returns the signed PDF or signature.

ETA e-invoice

  1. Your ERP sends invoices to the eInvoice Service.
  2. It builds the ETA canonical form and asks the Signing API for a CAdES seal.
  3. The HSM signs; the eInvoice Service attaches the signature.
  4. It submits to ETA and returns ETA's response.

Architecture

Deployment topology

Your network
Signing API, PDF engine, database and cache on your Linux servers behind your HTTPS proxy.
Next to the HSM
The HSM gateway runs beside the HSM. Keep it on a private network reachable only by the Signing API.
On people's devices
The desktop app on Windows, macOS or Linux; the iOS or Android SDK inside your mobile app.
Outside
Timestamp Authorities, OCSP and CRL responders, ITIDA remote signing and the ETA APIs, over HTTPS.

Architecture

Design principles

Keys stay in hardware
Tokens, ITIDA and HSMs hold private keys. The platform handles hashes and signatures, not keys.
Isolated crypto engine
PDF signing runs in a separate internal service, reachable only over an encrypted internal channel.
Stateless where possible
Only the Signing API keeps state (audit log, two-step signing sessions). Other services are stateless.
Portable builds
Single-file server builds run on current and older enterprise Linux without extra runtimes.