guides
Intended Documentation
Rust Safety-Critical Firmware
Wire format spec for the Intended edge verifier. Reference Rust crate ships at crates/intended-verifier.
Integrating Intended in Rust Safety-Critical Firmware (DOC-P4)#
Audience: firmware engineers writing Rust for safety-critical motion control: ros2_control hardware interfaces, no_std / RTOS motor controllers, automotive ECUs, surgical-robot real-time stacks.
Status of the Rust SDK: not yet shipped. This guide describes the canonical wire format, the JWT claim shape, and the verification contract that the Rust SDK + edge verifier (TOK-P1) will implement. Use this as the spec for in-house verifier code while we ship.
Why the Rust SDK is the certified path#
The Rust SDK + edge verifier binary (TOK-P1) is the commercial product in this stack. Everything else — the Python SDK, the ROS2 wrapper, the HTTP API — exists to make the Rust verifier the right choice for the hot path. Eventually it ships:
no_stdcore (Rustcoreonly) for embedded targets- A signed binary for industrial PCs and ARM gateways (TOK-P2)
- 24-hour offline operation via JWKS cache (TOK-P3)
- Sub-50ms verification latency at the edge
- Targeted at IEC 61508 SIL-2 / ISO 13849 PLd compliance, with a certification path to SIL-3 / PLe
If you need authority gating in Rust before TOK-P1 ships, the recommended path is to verify against the cloud's published JWKS on a non-RT thread and pass bool ok to your RT loop.
Wire format (canonical, locked for v1)#
An Authority Token is an RS256 JWT with the following physical-AI claims on top of the standard set:
exp is in seconds (RFC 7519); expiresAtMs is in milliseconds (operationally useful for sub-second TTLs that round to the same exp). Verifiers MUST enforce both.
Verification contract#
The verifier MUST reject the token if any of the following are true:
- Signature — does not validate against the issuer's published JWKS (
https://api.intended.so/.well-known/jwks.json). iss— not in the configured issuer allow-list.aud— notintended-edge-verifier.exp/expiresAtMs— past current attested time.actorIdentity— does not match the verifier's bound identity (typically the IEEE 802.1AR DevID provisioned at robot manufacture).oilCode— not in the operator's policy allow-list for this actor + cell.safetyBitmismatch — token claimssafetyBit: falsebut the action class requires safety-rated authorization on this site.physicalStateRef— required to be present and recent (≤deadlineMs). The verifier may optionally re-snapshot state and compare; the cloud-side snapshot is the authoritative one.
Verifiers MUST NOT rely on nbf for time-bounded operation; use expiresAtMs for sub-second windows.
Reference verifier sketch#
RT loop integration#
Verification is allocation-free with the right setup (heapless::Vec for the citations list, fixed-size buffers for claim strings). Target budget on a 1 GHz Cortex-A:
| Op | Budget |
|---|---|
| Header parse + kid lookup | < 5 µs |
| RS256 signature verify | 1–4 ms (key size dependent) |
| Claim extraction + checks | < 5 µs |
| Total hot path | ≤ 5 ms typical, 10 ms worst case |
For 10-ms control loops, this fits inside one cycle. For sub-1ms loops, verify out-of-band on a separate core and pass a verified-flag into the control task via a lock-free queue.
Time attestation#
The verifier's attested_now_ms MUST come from PTP / NTP (AUD-P7), NOT from SystemTime::now(). Spoofing system time is the obvious attack on time-bound credentials. The shipped verifier integrates with linuxptp / chrony / Microchip TSN cards.
JWKS rotation + offline#
Cache JWKS to disk (TOK-P3 — 24-hour offline operation). Refresh:
- Eagerly at startup
- On every
kidcache miss - Periodically (default: every 60 minutes)
- Never blocking the RT path
If JWKS cache is older than 24 hours and refresh fails, the verifier SHOULD fail closed for new tokens but continue accepting in-flight tokens until their expiresAtMs.
Until the SDK ships#
A minimal in-house verifier following this spec is a few hundred lines of Rust against jsonwebtoken and reqwest. Treat it as uncertified until you adopt the shipped intended_verifier crate — the Intended certified primitive applies only to our binary.
When TOK-P1 lands, migration is a crate swap: the public API matches this spec.
See also#
- DOC-P7 Authority API reference — the issuer side of the contract
- DOC-P5 safety-case writing — how to use the verifier's certification claims in your machine's safety case
- DOC-P8 edge-verifier operator guide — deployment, monitoring, key rotation once shipped