notary/cloud
ProductHow it worksChainsSecurityFAQFor partnersTrust
Scope a pilot
Trust and security posture

What is live, what is not, and how to verify us without trusting us.

This page is public on purpose. It is updated as posture changes, and it states planned surfaces as planned.

Control posture

The public posture is deliberately specific.

Each row names the control and its current state. LIVE means live in code or record design today. PLANNED means not live.

  1. 01
    CRYPTOLIVE WHEN CONFIGURED
    Configurable signing

    ECDSA P-256 is implemented when key directories are configured. HMAC remains the dev and legacy default.

  2. 02
    INTEGRITYLIVE
    Append-only record storage

    Records get monotonic sequence numbers and database-level append-only enforcement. UPDATE and DELETE are blocked under row-level security. This is not a per-record blockchain.

    Maps to: record alteration detection

  3. 03
    STORAGELIVE WHEN CONFIGURED
    Customer-held WORM retention

    When the customer's Object-Lock bucket is configured, signed records replicate into it (write-once retention), so the bytes sit under the institution's retention control, not ours. Deleting or rewriting a record inside the retention window is blocked by the customer's storage layer itself.

    Maps to: record retention; record-alteration detection (storage layer)

  4. 04
    TIMESTAMPLIVE — ON THE DEMO RECORD
    Merkle + RFC 3161 timestamp

    Daily batches are hashed into a Merkle root and countersigned by an independent RFC 3161 timestamp authority. The public demo record carries the token; it verifies offline with openssl. The anchor proves the record existed no later than registration time — it does not date the decision itself. Fallback endpoints are configurable; none ships as a built-in default.

    Maps to: time-of-record evidence

  5. 05
    VALIDATIONLIVE
    Fail-closed validation

    Records with unknown chains, missing fields, or malformed rationale are rejected before storage.

  6. 06
    PRIVACYLIVE
    AES-256-GCM encryption at rest

    Stored enforce payloads and evidence blobs are encrypted with AES-256-GCM before storage.

  7. 07
    ISOLATIONLIVE
    Tenant isolation

    Row-level security and FORCE RLS separate tenant records from runtime roles.

  8. 08
    PRIVACYPARTLY LIVE
    Payload minimization

    The public sample exposes only verification fields. Customer schemas require explicit allowlists before any real customer record is public.

  9. 09
    OWNERSHIPDEMONSTRATED IN DEMO
    Deployer-controlled record

    The record format is designed to sit in the deployer's evidence layer: exportable, reconcilable, contract-independent of vendor terms. Deployer-held key custody is the pilot target mode; the synthetic public demo verifies against a key served from a separate origin.

  10. 10
    OPERATIONSPLANNED
    Transparency surfaces

    Public status page, incident history, and key rotation log are planned. They must ship before any production pilot claim.

Data flow

Notary Cloud records. It does not decide.

  • The deploying system makes the decision.
  • The decision, rationale, and scoped inputs are sent to Notary Cloud.
  • The payload is canonicalized, minimized through an allowlist, signed, and stored append-only.
  • The public verifier checks the signature client-side against a public key served separately.
BOUNDARY

Notary Cloud does not decide, screen, approve, deny, or file SARs. It records the decision event after the upstream system has decided, then exposes a tamper-evident record when policy allows public verification.

Data handling

Subprocessors are named only when finalized.

HOSTING

Current hosting and storage

Deployment, hosting, and storage details should be named only after the subprocessor list is finalized. This page does not fabricate vendor names.

SUBPROCESSORS

Published list

Subprocessor list is published here and kept current. Status: publication pending.

DATA

Public record boundary

Public samples expose verification fields. Real customer schemas require explicit allowlists before any customer record becomes public.

Keys

Signing keys sit outside the producing runtime.

CURRENT STATE

The signing key is held outside the producing runtime. The ECDSA P-256 sample key is served at https://demo-bank-keys.pages.dev/.well-known/notary-cloud/demo_bank_ec_1.pem. Because the institution can retain this key and its published location, producing and verifying new records does not depend on Notary Cloud's signing service staying available. Storage follows the same principle as keys: when the customer's write-once bucket is configured, signed records replicate into it, so retention is enforced by the institution's storage layer, not by Notary Cloud remaining in business.

PLANNED

Customer BYOK and HSM/KMS-backed signing are planned, not live. A public key rotation log is planned.

Continuity

Verification should survive company and vendor change.

INCIDENTS

Incident history

Incident history is planned. It should be public before any production pilot claim.

DISAPPEARANCE

Record continuity

If the deployer retains the signed record and public key, verification does not require Notary Cloud to re-run the system or the original vendor.

Export

The record is exportable and independently verifiable.

  • Proof JSON with proof ID, key ID, timestamp, algorithm, input hash, decision, and signature.
  • Canonical string used for signature verification.
  • Public key URL served separately from the proof payload.
  • Verifier URL that can be opened by an examiner or reviewer when policy allows access.
Verify

Every claim here should be checkable against a live verifier.

The signed sample record and appendix expose the proof fields, canonical string, and public verification path.