@o3co/auth.policy-verifier.cedar-wasm

Last updated: 2026-09-23

The in-process Cedar engine for @o3co/auth.policy-verifier.cedar: the official @cedar-policy/cedar-wasm bindings behind cedar's CedarEngine port.

Importing this package is all a deployment does to select it:

import { cedarPolicyModule } from "@o3co/auth.policy-verifier.cedar";
import "@o3co/auth.policy-verifier.cedar-wasm";

The import registers the engine as "wasm". CedarPolicyRuleCollector picks it whenever its config names no engine, and engine = "wasm" spells the same choice out — that setting refuses to start when this package was not imported, naming it. Nothing else about the collector's config changes with the engine; see cedar's README for the whole of it.

It also vouches for the policy revision behind every answer (confirmsRevision, #244): the set is compiled in this process, from the files the revision was computed over, under an id nothing else holds — so an answer cannot have come from any other policies. It is the engine requireConfirmedRevision = true boots over; see cedar's Policy revision.

Responsibility

Role. One engine behind cedar's CedarEngine port (engine.mts). It depends on @o3co/auth.policy-verifier.cedar and on @cedar-policy/cedar-wasm. No package in this repository depends on it (only the integration tests do); a deployment imports it.

Owns (src/wasmEngine.mts):

• Parse-checking each policy file at boot, so a syntax error names its file, and compiling the set once into wasm memory under an id minted per load.
• Evaluating each request against that compiled set, synchronously, and rendering the bindings' answer as a CedarDecision.
• Naming the revision of the source it compiled on every answer.
• The exact version of @cedar-policy/cedar-wasm.
• Registering itself as "wasm" when imported (src/index.mts).

Does not own. Policy loading, the policy revision itself, the attribute-to-request mapping, what an answer means (the answer table, onNoDeterminingPolicy, the revision check) and which engine is selected. All of that is cedar's, and is identical whichever engine runs.

Why a separate package. The cost below: about 12 MB of wasm instantiated on import. Kept out of cedar, it is carried only by a deployment that evaluates in-process; one that runs cedar's http engine never loads it.

What it costs, and when to choose it

The policy set is compiled once, at boot, into wasm memory; each request references the compiled set and re-parses nothing. A decision is synchronous, deterministic, and takes a few tens of microseconds — no network, no timeout to tune, no second process to run. That is the right trade for a policy set whose evaluation is cheaper than a loopback hop, which is most of them.

The cost is paid at import: the wasm module is about 12 MB on disk and is instantiated when the bindings load, on the verifier's own event loop. A deployment whose policy set is large enough that evaluation competes with request handling — or that wants Cedar's evaluator scaled and upgraded apart from the verifier — runs cedar's http engine against a cedar-agent instead and leaves this package out — see Running out of process and the measured sizing table. That is a dependency change, not a config change.

Version pinning

@cedar-policy/cedar-wasm is pinned exactly: Cedar minor releases can carry policy-language changes, so upgrades should be deliberate and re-validated, not fall out of a range resolution.