# Security and compliance

For API signing, the application submits a document hash and opens the signing frame for passkey approval. SecurySign verifies the approval, signs the hash with the account’s server-side key and returns the signature. The signing certificate provides the public key for verifying that signature.

## Keys

Server-side signing and encryption keys are generated and used in a hardware security module (HSM). A certificate authority (CA) key issues the X.509 certificates supplied to integrations. Applications use the public certificates and encryption keys; SecurySign performs the private-key operations.

The passkey is a separate WebAuthn credential. Its public key verifies approval, while its private key is managed by the signer's authenticator.

## Each signature is bound to one document and one approval

The signing frame requests approval of a challenge tied to the document. In challenges with display binding, the document name, embedding origin, level of assurance and hash are included:

```text
challenge = SHA256(nonce + SHA256(documentName | rpOrigin | loa | documentHash))
```

PAdES approval uses the prepared PDF hash as the challenge. SecurySign checks the assertion signature, challenge, WebAuthn relying party ID, permitted origin, user presence and user verification. When an authenticator supplies a signature counter, the assertion is also checked against the stored counter.

Retain the completed signature, document hash and signer certificate for independent verification. The [Verification API](#/docs/api-certificates) covers cryptographic and revocation checks.

## Tokens and secrets

| Item | How you use it |
|---|---|
| Signing token | You pass it to the frame for one document hash within five minutes. |
| Signing operation | You complete the pending operation with its approval; prepared PAdES operations expire after five minutes. |
| `LOA-4` token | You collect approval from the passkey assigned to the token. |
| SSC and OIDC secrets | Your backend supplies them from server-side configuration. |
| Liveness token | Your capture component uses it for its verification within 600 seconds. |
| Handoff link | Your customer opens it to complete capture within 900 seconds. |

## LOA-2 versus LOA-4

At level of assurance 2 (LOA-2), a token authorizes the registered signing flow and the customer selects a registered passkey. At LOA-4, the token request includes the signer's email and is bound to that account's most recently registered passkey. See [LOA-4 setup](#/docs/rp-integration-guide#5-enable-loa-4) for approval requirements.

## Privacy

OIDC scopes determine which claims an application receives, identified by the account's `sub`. Certificate and drawn-signature downloads require that account's access token. Identity-verification requests use RP credentials and return the verdict, extracted document fields and retained capture evidence when requested and available. The [Privacy Policy](#/docs/privacy) describes data handling.

## Compliance

A signing record provides evidence of document binding, verified approval and the signing certificate. For procurement requirements concerning certification, audit reports or legal classification, request the applicable evidence and current status from SecurySign. The integration's signing flow, certificate chain and verification results can form part of that review.

## Reporting a vulnerability

Report vulnerabilities to [security@tenda.world](mailto:security@tenda.world), including the impact and steps to reproduce the issue. Use the same address for audit reports, penetration-test reports or questions about bounty eligibility.