Trust Model and Design Principles

Andi Lamprecht ·2026-05-11· 12 min read· Draft

1. Purpose

ATOMx needs a privacy-preserving, authorization-bound identity layer that improves on today’s public broadcast identity model without requiring the public disclosure of pilot/operator identity or control-station location.

The core product concept is simple: ATOMx binds pilot/operator identity, aircraft identity, and an approved flight plan or operating area into a cryptographically protected authorization package. That package allows ATOMx, approved systems, and approved field users to determine whether an aircraft is operating within authorization, while keeping sensitive identity and location fields protected from public exposure.

This capability is not just a Remote ID feature. It is part of the broader ATOMx airspace governance model. It gives responsible authorities a single operational source of truth for identity, authorization, conformance, trust confidence, disclosure, and audit within an assigned airspace.

2. Design Principles

2.1 Privacy by default, accountability by design

ATOMx should not expose pilot/operator identity, control-station location, permanent aircraft identity, or sensitive mission details to the public. Privacy does not mean anonymity. ATOMx must preserve the evidentiary record needed for authorized investigation, dispute resolution, enforcement, and after-action review.

2.2 Authorization-first identity

The public should not be asked to track permanent aircraft identifiers. The public-facing signal should be authorization-bound first and aircraft-linked internally.

The public token should answer: “Is this operation approved and operating within its approval?” It should not answer: “What aircraft is this forever?”

2.3 Public signal should be minimal and useful

The public does not need pilot identity, operator organization, control-station location, permanent aircraft identity, full mission purpose, or the approved flight plan. Where policy allows public visibility, the public should receive a simplified trust state:

1. Within Authorization
2. Not Within Authorization
3. Not Publicly Verifiable

2.4 Authorized users get operational detail

Authorized users and systems need more than a public trust state. They need reason codes, conformance detail, telemetry confidence, identity trust state, protected identity fields, revocation/amendment state, and security alerts.

Access to those details must be role-based, geography-aware, purpose-bound, time-bounded, and logged.

2.5 Separate authorization, trust, and security

ATOMx must not collapse all problems into a single green/red state.

A cooperative aircraft may remain trusted even if its authorization is amended or revoked. The issue is not that the aircraft is suddenly untrusted. The issue is that it is no longer approved to continue the prior operation and must comply with a new instruction.

The three independent dimensions are tabulated and developed in §4 Trust Model below; the ladder that resolves the Identity Trust dimension into the L1–L5 operator-facing levels is in Trust Ladder.

2.6 Connected first, disconnected capable

Connected verification is the primary operational model. ATOMx receives telemetry, compares it against the approved operation, generates conformance, manages disclosure, and logs all access.

Disconnected verification is a supported architectural path using pre-cleared authorization packages, approved field credentials, local verification, and later audit reconciliation.

3. Core Concepts and Objects

3.1 Authorization Package

The Authorization Package is the central object in this model. It is a cryptographically protected operational record that binds:

• Pilot/operator identity
• Operator organization
• Aircraft identity
• Public aircraft token
• Approved flight plan or operating area
• Validity window
• Authority context
• Public trust policy
• Protected disclosure policy
• Conformance policy
• Revocation/amendment policy
• Audit references
• Offline verification references, where applicable

The Authorization Package should be implemented as a signed manifest, not as a single oversized token.

3.2 Signed Manifest Model

The most logical implementation model is a signed manifest that references separate linked artifacts. The manifest should include stable references, hashes, signatures, versions, and policy pointers for:

• Aircraft identity record
• Pilot/operator identity record
• Operator organization record
• Approved operation
• Public trust policy
• Protected claims object
• Disclosure policy
• Conformance policy
• Revocation/amendment policy
• Offline capsule, where applicable
• Audit chain

Each linked artifact should be independently verifiable where possible. The manifest signature should cover the full binding.

The manifest groups its linked artifacts into four conceptual categories. Each artifact is referenced by stable ID and hash; the manifest signature covers the full binding.

    flowchart TB
    M["<b>Signed Authorization Package Manifest</b><br/>signature · version · hashes · refs"]
    M --> ID[Identity]
    M --> OP[Operation]
    M --> POL[Policies]
    M --> EV[Evidence & Offline]
    classDef cat fill:#eef3ff,stroke:#1f6feb
    class ID,OP,POL,EV cat
  

3.3 Public Aircraft Token

The public aircraft token is the only identifier visible to the public. It is bound to a specific authorization, not to a permanent aircraft identity.

Default behavior:

• Token is stable within a single authorization
• Token rotates across authorizations
• Stricter rotation policy available for protected missions
• Token cannot be used by the public to track aircraft across missions
• Token can be resolved to protected identity internally by ATOMx for authorized purposes

3.4 Protected Claims Object

Protected claims include:

• Pilot/operator identity
• Operator organization identity
• Permanent aircraft identity
• Control-station location
• Mission details (where sensitive)
• Approved operation details (where protected)

These fields are encrypted at rest. ATOMx decrypts them only inside controlled services after disclosure policy approval. Field-level disclosure is the default: a requester may be granted access to some protected fields but not others.

3.5 Public Trust State

The public trust state is the simplest possible signal. It tells the public whether an aircraft is verifiably operating within its approval, verifiably not operating within its approval, or not publicly verifiable.

Not Publicly Verifiable is not the same as unauthorized. It means the public signal alone is insufficient to determine authorization status. This may include cooperative aircraft in disconnected mode, aircraft with protected mission status, or aircraft where public broadcast is not available or not yet received.

4. Trust Model

ATOMx distinguishes three independent dimensions. They move independently — an aircraft has a current value on every axis at all times, and the resolved operator-facing color comes from the combination, not from any single axis.

Why three dimensions, not two

The dimensions could in principle be collapsed — “untrusted” could subsume both “spoofed” and “credential expired”. They are kept separate because the operator response differs:

• A cooperative aircraft with revoked authorization must respond to instruction (exit, hold, land) — it is not the target of investigation.
• A trusted-credential aircraft with an active security alert is cooperating but its environment may be hostile (interference, possible spoof of a different aircraft) — investigate without grounding.
• An untrusted aircraft has failed cryptographic validation — treat with caution; do not act on its claims.

Collapsing these would force every authorization change to read as a security event and every interference event to read as a credential failure. Neither is true.

Identity Trust State Vocabulary

The Identity Trust axis itself uses a coarse three-state machine inside the trust model (Trusted / Degraded / Untrusted); operator surfaces render it through the L1–L5 ladder. The mapping:

An aircraft may be:

• Authorized and trusted and presenting no security alerts (normal cooperative operation)
• Authorized and trusted but presenting a security alert (possible interference, needs investigation)
• Previously authorized but authorization revoked, identity still trusted, no security alert (cooperative aircraft responding to instruction)
• Not publicly verifiable because it is in disconnected mode or protected mission mode (does not mean untrusted)
• Not verifiable at all because ATOMx has no authorization record or telemetry (truly unknown)

The key product decision: a cooperative aircraft that loses authorization does not automatically become a security threat. The system should treat authorization changes and security anomalies as separate dimensions.

The three dimensions move independently. The diagram below shows each as its own state machine — an aircraft has a current value on every axis at all times.

    stateDiagram-v2
    direction TB
    [*] --> Approved
    Approved --> Amended
    Amended --> Approved
    Approved --> Revoked
    Amended --> Revoked
    Revoked --> [*]
  

    stateDiagram-v2
    direction TB
    [*] --> Trusted
    Trusted --> Degraded
    Degraded --> Trusted
    Degraded --> Untrusted
  

    stateDiagram-v2
    direction TB
    [*] --> NoAlert
    NoAlert --> Investigating
    Investigating --> Confirmed
    Investigating --> NoAlert
  

Example combinations the model must represent without collapsing:

5. Location Generalization and Protected Mission Mode

ATOMx should support two public location modes.

Protected Mission Mode may be:

• Requested by an operator
• Automatically applied by mission class
• Directed by a controlling authority
• Approved, denied, or downgraded by ATOMx policy

Public indication of Protected Mission Mode should be policy-based. Default: public may see that location is intentionally generalized. Sensitive cases: public may see only generalized location and limited trust state, without explanation. Authorized users see precise telemetry and protection reason if permitted.

6. Security Model

§6 is a summary. The full ten-category threat taxonomy with mitigations and residual-risk register is in Threat Model. The table below is the conceptual subset used to anchor the design principles in §2.

6.1 Primary threats

6.2 Key management assumptions

The system should assume:

• Protected fields are encrypted at rest and in transit.
• ATOMx may decrypt protected fields inside hardened controlled services after policy approval.
• Key access should be mediated through a managed KMS/HSM-backed pattern.
• Field-level encryption should support selective disclosure.
• Offline disclosure should use scoped credentials that can expire and be revoked.
• Hardware-backed aircraft identity should be supported as a higher assurance tier.
• Recipient-side encryption should be available for specialized deployments, but not required for all integrations.

6.3 Trust tiers

ATOMx should support at least two aircraft identity trust tiers.

Hardware-backed identity should be the stronger target state, especially for protected airspace, defense, critical infrastructure, and high-consequence operations.

Next

Continue to System Design and Implementation for components, flows, APIs, and the MVP boundary.

Implementation Readiness — Open Questions

Each entry below identifies a decision not yet locked. Items marked (ADR) should be formalized as an Architecture Decision Record before implementation begins. Items marked (blocking) must be resolved before the relevant feature can be built.