Operator Authorization

Andi Lamprecht ·2026-05-11· 3 min read· Accepted

Operator Authorization

Context

We have been resisting the temptation to give Avatars storage because:

• Flight safety is a very strong requirement put on the Avatar and storage would be a point of failure.
• As it says on the tin, Avatar is an avatar (aka digital twin) of a drone. Its source of truth lives with the drone. There is hardly anything to store.
• To date, we only found one thing that we need the avatar to know that the drone has no business caring about: the mission_id. To solve it, we opted to use the drone itself as storage and we deposit the mission_id together with the mission on the drone. Had we spun up a Redis instance to store this mission_id there would be a chance, that the mission (on the drone) and its mission_id on Redis, go out of sync for some reason and the mission_id does not identify the mission actually present on the drone.

We now need to face the inevitable requirement: Only the operator assigned to a mission can control the UAV. There could be more than one operator assigned to a mission, but only one at a time.

This means that the Avatar must only admit those operators, whose sub is on a list the Avatar’s been told to admit or the Authorization header contains a some claim unique to this drone that the Avatar can trust.

Decision

We continue using the drone as the storage and send the operator sub to the drone, whenever that operator changes.

Consequences

We will be unable to send re-assign the operator mid-flight and when the UAV happens to be in C2 loss condition. C2 loss isn’t frequent, but we expect it to be fairly normal in short spills. When this happens, the request to reassign the pilot will fail and will need to tried again.

MAVLINK-Shim will have to store the operator ID in a similar way that it stores the mission_id. But what if it crashes? MAVLINK-Shim already has that problem with the mission_id. It doesn’t persist it and when it crahes the mission_id is gone. If the operator_id is gone in a same manner, then the avatar has no choice but to permit any operator (with a valid JWT token) to fly the drone.

Alternatives Considered

Tokens

We considered having our MissionsService issue operator JWT tokens signed by the service’s private key, but JWT tokens cannot be revoke and they expire - both of which is a problem for a sustained control over an aircraft.

Storage

We think storage is inevitable, but we’re at a crunch and can’t afford thinking it properly through.

Cited by queries

• DroneUp roles and permissions: as-is across Uncrew, Hubops, UTM, Boundary Creator, Frontegg, Okta, and Lumos — 2026-05-01