Skip to content
Jarvis home →
Docs / Reference / Security & launch checklist

Security & launch checklist

A working happy path is the beginning. These boundaries must hold when users decline, permissions change and services fail.

INTEGRATION REVIEWDEV ALPHAUpdated Sep 9, 2026
Section titled “Identity is not consent”

Use (issuer, subject) as the unique identity key. Each independent application has a stable pairwise subject for the same person; it is deliberately different across apps. Never correlate accounts by internal person ID or email.

Keep client secrets, OAuth state/nonce/PKCE transactions and access tokens in the confidential backend. ID tokens carry identity, not a grant to read personal facts. Context refusal must leave an established product session intact.

Section titled “Cookie isolation”

The legacy Kratos cookie domain is k8s1.aviproduction.org. An untrusted external product must not share that parent domain while those cookies exist. Use a separate owned domain, exact registered callbacks and no caller-controlled redirect.

Product cookies should be Secure, HttpOnly, Path /, host-only (no Domain), with appropriate SameSite behavior. The example sign-in binding uses __Host- and SameSite=Lax. Protect product mutations with Origin checks and CSRF tokens.

The external product receives only its own OIDC credentials and local database credentials. Jarvis internal APIs, admin ports, shared database owners and service keys do not belong in the integration.

Verify these scenarios

Section titled “Verify these scenarios”
  • Replay: expired, duplicate, mismatched and reused callbacks fail closed.
  • Pairwise identity: stable within the app; different in another registered app.
  • Consent denial: the user stays signed in, without personal-context access.
  • Minimal disclosure: requesting an extra field never returns a partial unauthorized answer.
  • Isolation: another user’s or app’s grant/request ID cannot disclose context.
  • Freshness: changed facts invalidate old work units; no automatic new-work-unit retry.
  • Revocation: the next export stops after revocation or expiry.
  • Audit failure: if a disclosure receipt cannot persist, context is not released.
  • Verification: signature, subject, audience, purpose and work-unit tampering are rejected.
  • Token custody: no bearer in browser JS, third-party pages, logs, prompts or telemetry.
  • Logout: product-local logout and Jarvis identity logout have distinct behavior; Jarvis identity logout invalidates existing external access tokens.

Before production

Section titled “Before production”

The dev reference was exercised in real Chromium with two synthetic people and two applications. Dated evidence covers 16 checkpoints and network isolation. It is not proof that your deployment works, and it does not verify delivery to a real mailbox.

Production still requires real email/recovery checks, proper domains, distributed abuse controls, availability, retention/deletion policy and tested key backup, restore and rotation. Pairwise HMAC keys and sector IDs are identity mapping material: changing them requires an explicit identity migration, not routine rotation.

Revocation prevents future exports; it cannot recall already copied data. Define how your product deletes authorized copies and derived answers, including backups. Do not advertise immediate global erasure or delegated actions this SDK does not provide.