§ Security
Two independent controls, and an honest account of their edges.
To hold a valid access code, an attempt has to clear both barriers
A leaked or stale config file
Certificate encryption
Opens only on a device with the private identity.
Config Key proof
Passes only if the config matches current settings.
Access code released
Protects the file. Every .seb is wrapped to your public X.509 certificate (SEB pkhs). The private identity sits on approved managed devices — non-extractable where supported, and restricted to the SEB application.
Protects the code. The server re-verifies the Config Key hash against the assessment, the settings fingerprint, and the URL family before minting a single-use, two-minute proof token.
Controls
What the server checks, and when
Identity comes from a validated LTI launch or a server-issued, bound capability. Query parameters, request bodies, and page content are never accepted as authorization.
Signed launches only
Every launch is validated for RS256 signature against the Canvas JWKS, plus issuer, audience, nonce, token age, timestamps, LTI version, message type, deployment ID, target URI, and the initiating browser's transaction cookie.
Replay closed atomically
LTI state is encrypted, valid for ten minutes, bound to a short-lived HttpOnly cookie, and claimed through an atomic Firestore transaction. A replayed launch loses the race and is rejected.
Proof, not assertion
A code is released only after SEB proves its Config Key hash against current settings. A config from before a policy change cannot produce a valid proof — which is why stale files simply stop working.
Public material only, server-side
The service holds the public X.509 certificate and nothing more. The private identity belongs in your device-management platform, restricted to the approved SEB application.
A tool, not a Canvas proxy
Canvas calls are constrained to the configured origin and its /api/v1 base, with size limits and deadlines. Students authorize exactly one narrow scope.
Admission control
Initiation and token validation run against process-local and Firestore-backed budgets. Grant minting is rate-limited per principal and per IP — a valid launch is not a licence to mint configs in bulk.
Everything expires
Nothing sits around waiting to be reused
Grants, proofs, launch state, and sessions all carry a short lifetime. Transient records and operation locks carry an expiresAt for Firestore TTL to collect.
Bars scaled for legibility, not to a linear time axis.
Key custody
Who holds what
The single most important line: the service never holds the private identity, and the managed tier does not change that.
The service
Holds
Public X.509 certificate, LTI signing key, Canvas OAuth credentials
Never
The private client identity, its .p12, or its passphrase
Your MDM / vault
Holds
The private identity and its protection material
Never
Broad instructor, student, or runtime access
The approved client
Holds
A non-extractable, SEB-restricted private identity
Never
An exportable identity reachable by a student account
Data residency
It is your database
Self-hosted or managed, the store is a Firestore database in a cloud project scoped to your deployment. There is no shared multi-tenant datastore, because there is no multi-tenancy.
| Collection | Contents | Lifetime |
|---|---|---|
assessments | Discovery data and per-assessment SEB state | Durable |
courses | Defaults, setup state, exam-tool catalog | Durable |
canvasOAuthTokens | Tokens by numeric Canvas user ID | Per authorization |
sessions | Session payloads under a hashed ID | 30-min TTL |
transientStates | Replay claims, OAuth state, grants, proofs | TTL-collected |
operationLocks | Short assessment-update leases | TTL-collected |
Limits
What this does not do
Every one of these will come up in a procurement review. Better you read them here than discover them in week three of a pilot.
Not device management
The setup check confirms the app's SEB integration. It does not establish device trust or replace a managed-device baseline. An unmanaged machine cannot offer the same non-extractability assurance.
Accommodations need a plan
Automatic Assessment Configuration on macOS may block third-party assistive tech. That accommodation needs a separately approved arrangement — not a weakened config shared with everyone.
Validate against real clients
SEB settings are honoured by the client, and coverage varies across releases and operating systems. Validate the full policy with a real supported client after SEB or OS updates.
One tenant, one deployment
Environments that must stay isolated need their own service, database, secrets, and Canvas registration. Mixing them is a failure mode, not a shortcut.
Found something?
Security reports are welcome and handled seriously. Once the source is public, the repository will carry a disclosure policy; until then, reach us directly.