The Authorization Package

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

“Flight authorizations serve as cryptographic envelopes that bind together pilot identity, aircraft identity, and flight intent with a signature verified by the platform’s private key, creating non-repudiation.” — John Vernon, Apr 3, 2026

1. What It Binds

The Authorization Package is a cryptographically protected operational record that binds, at minimum:

• Pilot identity (verified per Pilot Identity)
• Operator organization
• Aircraft identity (anchored per Aircraft Hardware Identity)
• Public Aircraft Token
• Approved flight plan or operating area
• Validity window
• Authority endorsement(s)
• Public trust policy
• Protected disclosure policy
• Conformance policy
• Revocation / amendment policy
• Audit references
• Offline verification references (where applicable)

The conceptual framing is in Trust Model §3.1. This page covers the implementation.

2. Signed Manifest, Not One Big Token

The Authorization Package is implemented as a signed manifest that references separate linked artifacts by stable ID and hash. The manifest signature covers the full binding — every artifact is named and pinned, but each artifact is independently verifiable on its own.

    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. Multi-Authority Endorsement Model

A flight may require approval from more than one authority — by jurisdictional split, by competence-based split, or both. ATOMx dispatches the authorization request to all required authorities simultaneously. First-to-respond is the first endorser. The flight may not commence until all required endorsements are collected.

The two endorsement patterns

Each endorsement is scoped and independently signed. The authority’s signature covers both the endorsement’s own fields and the base token fields (pilot, drone, window, area, purpose) — binding the endorsement to this specific flight request so it cannot be detached and reused on a different authorization.

Endorsement {
  authority_id:   "FAA-Eastern"
  scope:          "flight_path"
  segment:        <geofence sub-polygon>          ← optional, for jurisdictional splits
  time_window:    { from: "14:00Z", until: "16:00Z" }
  decision:       "approved"
  signature:      <authority key over (base token fields + this endorsement's fields)>
}

Approval invariant

Every overlapping jurisdiction must independently approve before the Authorization Package is issued. Operators do not see the count or identity of jurisdictions involved — they see one queue, one outcome. See Origins and Decisions §7.1.

4. Composition and Outer Signature

The Authorization Package is the manifest plus its linked artifacts plus the endorsements collected from each authority. ATOMx assembles all of this into a single signed envelope and seals it with its own signature.

Naming. Throughout this cluster, Authorization Package is the canonical name for the whole signed object. Older artifacts and some internal code refer to the same object as the Authorization Token or Authorization Object — they all denote the package. The Public Aircraft Token (§5) is a distinct, separate object: a public-facing rotating identifier carried by the package, not the package itself.

The denormalized resolved view of a single package is shown below for readability. The normative wire form is the manifest in §2 — it carries hashed references to separate signed artifacts (Approved Operation, Protected Claims, etc.) instead of inlining them, which keeps the wire object small and lets each artifact be verified independently. Field names below match system-design §5.1 AuthorizationPackageManifest.

AuthorizationPackage (resolved view) {
  package_id:               "auth-943da899"
  package_version:          1
  pilot_identity_ref:       "login.gov:john.doe@agency.gov"
  operator_identity_ref:    "op:contoso-inspection-llc"
  aircraft_identity_ref:    "DRN-00492"
  aircraft_assembly_cert:   <Drone Assembly Certificate fingerprint>
  aircraft_assurance: {
    key_storage:      "hardware-tpm",
    tpm_manufacturer: "Infineon",
    pcr_verified:     true,
    secure_boot:      true,
    attested_at:      "2026-04-12T09:00Z"
  }
  public_token_id:          <see §5>
  approved_operation_ref:   <ref to ApprovedOperation artifact>
  validity_start:           "2026-06-01T14:00Z"
  validity_end:             "2026-06-01T16:00Z"
  purpose:                  "infrastructure inspection"
  endorsements: [
    { authority_id: "FAA-Eastern",   scope: "flight_path",      decision: "approved", signature: <...> },
    { authority_id: "DoD-NORTHCOM",  scope: "security_context", decision: "approved", signature: <...> }
  ]
  protected_claims_hash:    <hash of envelope-encrypted ProtectedClaims>
  disclosure_policy_ref:    <ref>
  conformance_policy_ref:   <ref>
  revocation_policy_ref:    <ref>
  audit_chain_ref:          <ref>
  offline_capsule_ref:      <ref, optional>
  issuing_system_id:        "atomx-authorization-service"
  signature_algorithm:      "ECDSA-P256-SHA256"
  signature:                <platform key over entire manifest including endorsements>
  created_at:               "2026-06-01T13:55Z"
}

The platform’s outer signature seals the composite — it attests that the endorsements were collected honestly and prevents an endorsement from one flight being transplanted into another.

Who holds the authority key

The authority’s signing key is managed by the platform in an HSM — authorities do not bring their own keys. ATOMx acts as the CA for the authorization layer. This trades a small reduction in pure non-repudiation (an authority cannot independently prove its key was not misused by ATOMx) for a large reduction in operational complexity (no per-authority HSM enrollment, key rotation, or revocation channels). The audit log of every signing event is the compensating control.

5. Public Aircraft Token vs. Permanent Identity

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.

This is what prevents the public from using Remote ID broadcasts to track a drone across missions while still allowing authorized users (with policy clearance and purpose code) to resolve protected identity for an investigation or incident response.

6. Protected Claims and Envelope Encryption

Protected claims (pilot identity, operator details, control-station location, permanent aircraft identity, sensitive mission details) are envelope-encrypted: the actual data is encrypted with a one-time random data-encryption key, and that data-encryption key is itself encrypted with a long-lived key managed by ATOMx’s KMS. The capsule carries both: the encrypted data and the wrapped data-encryption key.

This pattern lets ATOMx issue distinct wrapped keys for different recipient classes (e.g., one wrap for authority field devices in a given jurisdiction, another for the aircraft itself) without re-encrypting the bulky payload, and lets keys be revoked or rotated without invalidating already-encrypted data.

For the disclosure-policy logic that gates decryption, see Trust Model §6.

7. Validity Criteria — What Makes a Package “Valid”

A verifier (whether ATOMx itself, an authority field device, or an integrating partner) accepts a package only when all of these checks pass. The order matters — earlier failures short-circuit the later, more expensive checks.

A package that fails any check is not “partially valid.” It is invalid; the response is graceful degradation in the operator-facing UI (per Trust Model §3.5), not silent acceptance.

8. Partial States and Conflict Resolution

8.1 Partial-Endorsement State

Between submission and full issuance, an authorization request walks through observable states:

The first authority to respond is recorded as the first endorser; the operator does not see which authority is still pending until policy permits it.

8.2 Conflict Resolution Between Authorities

When two authorities have overlapping jurisdiction over the same flight and one approves while another denies, the package is denied — there is no precedence rule that lets one authority override another inside the cryptographic structure. The conflict is surfaced to operator and authorities for out-of-band resolution. Reasons:

• A precedence rule baked into the protocol would let one authority unilaterally override another, defeating the inter-agency design.
• Operators get a deterministic answer: “you do not have authorization.”
• Authorities can pre-coordinate (via the federation model in Onboarding Authorities §4) to avoid the conflict entirely.

8.3 Amendment vs Re-Issuance

An amendment keeps the same package_id and increments package_version. The audit chain links the new version to the prior. Use cases: TFR pop-up, dynamic re-route, validity-window extension.

A re-issuance is a new package_id — used when the underlying flight is materially different (different pilot, different aircraft, different operating area). The new package may reference the prior in its audit chain, but it is a distinct cryptographic object.

Verifiers accept the highest package_version they have seen for a given package_id; older versions are deprecated immediately on amendment.

9. Lifecycle Authority

The authorization is not a token issued once and forever. Pop-up TFRs, jurisdiction state changes, or authority action can rescind a live authorization. The capsule and broadcast must reflect amendment / revocation, and the conformance engine compares against current-authorized-state, not authorized-at-issuance. See Origins and Decisions §3.11.

10. Cross-References

• The conceptual frame and design principles: Trust Model §3
• The full pre-flight authorization flow: Flight Lifecycle §2
• How the package is shipped to a disconnected aircraft: Disconnected Operations §4

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.