Remote ID Standards-Compatibility Analysis (CC-8)

Andi Lamprecht ·2026-05-11· 12 min read· In Review

1. Question

Does the ATOMx attestation extension — a ≈140-byte signed payload that points back at the offline capsule by hash — live entirely inside optional fields of:

• ASTM F3411-22a (Remote ID and Tracking — the broadcast spec),
• ASTM F3586-22 (FAA-accepted Means of Compliance for Part 89),
• FAA 14 CFR Part 89 (the regulatory rule), and
• ASTM F3548-21 (USS-to-USS interoperability — the network side)?

…or does it require amendments, a Part 89 petition, or a new MoC?

2. Bottom Line

No FAA petition. No Part 89 amendment. No F3586 supplemental MoC strictly required. The optional-fields hypothesis in Origins §3.2 and Disconnected Ops §5.1 is correct.

The analysis is conditional on three implementation caveats (§5) and one recommended standards-body action (§6.2).

3. F3411-22a — Broadcast Remote ID

3.1 Authentication Message Envelope

The Authentication Message (Message Type 0x2) is a 25-byte block, fragmentable across up to 16 pages (LastPageIndex 0x0–0xF).

• Page 0 carries the header + 4-byte Unix timestamp + 17 bytes of Auth Data.
• Pages 1–15 each carry 23 bytes of Auth Data.
• The wire-level Length field is a uint8 capped at 255 bytes of concatenated payload (F3411 §5.4.5.15, Table 8, p. 16).

ATOMx’s ≈140-byte attestation payload fits in ≈7 pages (1 × 17 + 6 × 23 = 155 bytes capacity).

3.2 Authentication Type Field — Vendor Range Is Explicit

The 4-bit AuthType field (Table 2, p. 13) defines:

F3411 §5.4.5.11 (p. 14) blesses this explicitly:

“Custom authentication implementations can be created using Auth Types A-F. The details of a custom implementation are beyond the scope of this specification.”

The Auth Data bytes are described as “Opaque Authentication Data” — the spec does not constrain what they encode (§5.4.5.15). A hash pointer + signature is within the envelope F3411 contemplates.

3.3 Broadcast vs Network

The Authentication Message is broadcast-only. On the Network Remote ID side, F3411 mandates industry-standard auth (TLS + OAuth 2.0, NET0010/NET0020, §5.5.2.4, p. 27) but defines no analogous “Authentication Message” object — auth is transport-level. AuthType 4 is the bridge that declares “auth is delegated to the network” on the broadcast side.

This shapes ATOMx’s deployment topology: the attestation rides the broadcast channel; capsule retrieval / verification can use network paths but isn’t a F3411 Network RID artifact.

4. FAA Part 89 and F3586-22 — Regulatory Permission

4.1 Part 89 is a Floor, Not a Ceiling

Part 89 §§ 89.305/315 specify the minimum message element set; §§ 89.310/320 specify minimum performance. Reading Table 3 of F3586-22 (pp. 9–10) and the underlying CFR text:

• No payload-content prohibition. Part 89 does not state “only these elements may be broadcast.”
• § 89.310(g)(1) requires a “non-proprietary broadcast specification” — F3411’s Authentication Message is part of that non-proprietary spec, so using it is by definition not proprietary.
• § 89.310(d) (tamper resistance) restricts user-facing alteration of required elements. Adding new signed elements does not violate this.
• § 89.310(f) (non-interference) requires that the RID equipment not interfere with other systems and vice versa. Adding extra Auth Message broadcasts on the same channel is permitted provided required-message periodicity is preserved.

4.2 F3586-22 — Silent on the Authentication Message

F3586-22 is the FAA-accepted MoC. Its Part 89 mandatory message set (§5.1.3, Table 3) is:

• Basic ID Message
• Location/Vector Message
• System Message

The Authentication Message is neither mandated nor mentioned. F3586 §3.1 (p. 2) explicitly frames itself as an overlay of F3411 that “identif[ies] mandatory portions… and provid[es] additional requirements that are beyond the scope of Specification F3411” — preserving F3411 capabilities (including Auth Messages) that Part 89 does not address.

The constraining clauses ATOMx must satisfy in the DOC:

• §7.5.2 — Tamper Resistance: required-element values are masked from user input. ATOMx does not alter required elements; it adds new ones.
• §7.6.3 — Interference: the RID system must not degrade RF-sensitive systems below performance/periodicity requirements.
• §7.8.2 — Periodicity: “all messages containing the Part 89 required data elements… shall be sent at least every 1 second.” ATOMx must not push Basic ID / Location/Vector / System below 1 Hz.

These are testable in the §8.6 packet-capture test that’s already part of the F3586 DOC.

4.3 No Petition Required

Because (a) F3411’s Authentication Message is part of the non-proprietary spec Part 89 invokes, (b) Part 89 does not enumerate prohibited payloads, and (c) F3586’s overlay model preserves non-mandated F3411 capability, no Part 89 amendment, FAA petition, or F3586 supplemental MoC is strictly required to broadcast ATOMx attestations. A defensible DOC should explicitly disclose the addition in the compliance file and include the §8.6 packet-capture evidence of preserved periodicity.

5. Implementation Caveats (Required Mitigations)

These are the three real constraints surfaced by the analysis. They are not blockers — but they shape design.

5.1 The 9-Messages-Per-Pack Cap

This is the most concrete F3411 envelope constraint ATOMx hits. The math is worth walking through because it shapes the broadcast schedule.

Where the cap comes from. F3411-22a §5.4.7.7 (requirement BB50120, p. 21):

“No more than 9 messages shall (BB50120) be included in a single Message Pack.”

A Message Pack (Message Type 0xF, §5.4.7) is the bundling envelope F3411 uses on Bluetooth 5 Long Range and Wi-Fi Beacon — broadcast methods that can carry larger PDUs than legacy Bluetooth 4 advertising. Instead of sending one 25-byte block per advertisement, the transmitter packs up to 9 blocks into a single Pack and emits the Pack on each transmission opportunity. Each block in the Pack is one of the standard 25-byte F3411 messages (Basic ID, Location/Vector, Self-ID, System, Operator ID, or one page of an Authentication Message).

Why ATOMx hits the cap. A multi-page Authentication Message counts each page as a separate block (§5.4.4.2 BUR0060: “If a message is multi-paged… the Message Counter shall be the same for each page in the page set” — same Counter, different blocks). ATOMx’s ≈155-byte attestation is 7 Auth pages (1 × 17 B on page 0 + 6 × 23 B on pages 1–6 = 155 B).

10 blocks exceeds the 9-block Pack cap by one. Visualized as a single naive Pack:

    flowchart TB
    subgraph Naive["Naive Pack — 10 blocks, EXCEEDS BB50120 (cap = 9)"]
        direction LR
        nB[Basic ID]
        nL[Loc/Vec]
        nS[System]
        nA0[Auth pg 0]
        nA1[Auth pg 1]
        nA2[Auth pg 2]
        nA3[Auth pg 3]
        nA4[Auth pg 4]
        nA5[Auth pg 5]
        nA6[Auth pg 6]
    end
    Naive -->|rejected by F3411 §5.4.7.7| X[/Non-compliant transmission/]
    classDef required fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
    classDef auth fill:#fef3c7,stroke:#b45309,color:#7c2d12
    classDef bad fill:#fee2e2,stroke:#b91c1c,color:#7f1d1d
    class nB,nL,nS required
    class nA0,nA1,nA2,nA3,nA4,nA5,nA6 auth
    class X bad
  

Mitigation: alternating Pack schedule. Auth Messages are statically-periodic (Table 3, §5.4.5.9) — they don’t need to ride every Pack. Required messages must meet ≥1 Hz periodicity per F3586 §7.8.2; ATOMx Auth pages can ride the static-refresh cadence ([BcMinStaticRefreshRate], Annex A3).

    flowchart TB
    subgraph Pack1["Pack N — t = 0 ms (Required + Auth pages 0-5)"]
        direction LR
        B1[Basic ID]
        L1[Loc/Vec]
        S1[System]
        A0[Auth pg 0]
        A1[Auth pg 1]
        A2[Auth pg 2]
        A3[Auth pg 3]
        A4[Auth pg 4]
        A5[Auth pg 5]
    end
    subgraph Pack2["Pack N+1 — t = ~1000 ms (Required + Auth page 6 + room to spare)"]
        direction LR
        B2[Basic ID]
        L2[Loc/Vec]
        S2[System]
        A6[Auth pg 6]
        SI[Self-ID*]
        OP[Operator ID*]
    end
    Pack1 -.next transmission opportunity.-> Pack2
    classDef required fill:#dbeafe,stroke:#1e40af,color:#1e3a8a
    classDef auth fill:#fef3c7,stroke:#b45309,color:#7c2d12
    classDef optional fill:#f3f4f6,stroke:#6b7280,color:#374151,stroke-dasharray: 3 3
    class B1,L1,S1,B2,L2,S2 required
    class A0,A1,A2,A3,A4,A5,A6 auth
    class SI,OP optional
  

*Self-ID and Operator ID are F3411 messages used by ATOMx for context but not mandated by Part 89; they fit in the slack of Pack N+1.

Result: Pack N is full (9 blocks). Pack N+1 carries the last Auth page plus the next required-message tick. Across two Packs, ATOMx delivers a complete 7-page attestation and meets Part 89 ≥1 Hz on required messages.

Cost: verifiers need to receive at least two consecutive Packs to assemble a full ATOMx attestation. At BT5 Long Range cadence this is sub-2-second worst case — well within field-verification UX expectations. On Bluetooth Legacy 4.x, Packs don’t apply (each advertisement is one 25-byte block); Auth pages are simply interleaved with required messages over time at the static refresh rate.

Action item for engineering. Produce a concrete timing diagram for the chosen ATOMx attestation cadence against [BcMinStaticRefreshRate] before locking the Auth payload size. If we can shrink the attestation by ≤14 bytes we drop to 6 Auth pages (141 B capacity) and fit everything in one Pack (9 blocks exactly) — worth a hard look during message-format finalization. The current ATOMx broadcast composition lives in Local Broadcast & Messaging §5.

5.2 “Ignore Unknown AuthType” Is Not Normatively Mandated

F3411 §5.4.5.11 blesses private AuthType use but does not contain an explicit “MUST ignore unknown AuthType” receiver clause. The Annex A1 Verifier Service API enumerates AuthType 1–5 only. Implementations in practice drop unknown-type messages, but this is observed behavior, not spec-mandated.

Mitigation:

• Functionally, no action — every shipping receiver we’ve inspected ignores unknown AuthTypes silently.
• For the regulatory deliverable, submit an editorial clarification request to ASTM F38.02 asking for an explicit normative clause. This is a request for a non-substantive sentence-level addition, not an amendment to behavior.

5.3 Private AuthType Codes Are Not Centrally Allocated

AuthType 0xA–0xF (“Available for Private Use”) has no ASTM-operated registry. Multiple vendors using overlapping values cannot interoperate.

Mitigation paths (preferred-to-least-preferred):

1. Register a Specific Authentication Method Type via Annex A5 (1–224 registered range; 225–255 experimental). This is the path the spec explicitly contemplates for this scenario (F3411 §5.4.5.15, BMG0185). It uses AuthType 5 (Specific Authentication Method) and a registered Method Type byte. Lighter-weight than a spec amendment. Recommended.
2. Request an AuthType allocation from the reserved 6–9 range via ASTM F38.02 ballot. This would be a spec amendment, slower and heavier.
3. Squat on a 0xA–0xF value with ecosystem agreement. Workable for an MVP-scale rollout, fragile at industry scale.

6. Network Side (F3548-21) — Compatibility Note

F3548-21 does not define Network Remote ID interop; it delegates Remote ID to F3411 (§1.7). There is no F3548 Authentication Message equivalent. The relevant findings for ATOMx:

• §1.6 — Value-Added Capabilities Clause: “USSs may also provide additional, value-added capabilities and still be compliant with this specification as long as the value-added capabilities do not conflict with the services defined in this specification.” This is the extensibility hook for any ATOMx data on USS APIs.
• OAuth 2.0 + JWT are mandatory on every interoperability API (§X1.1, §A2). The audience claim (aud, §X1.1.2.3) prevents transparent token-relay — ATOMx attestations must not ride OAuth tokens.
• Optional JWS message signing (§X1.2) is the natural existing crypto surface to layer attestation references; ICAO IATF basis, already used in FAA UPP2 for safety-critical providers.
• No standardized vendor-extension field exists in DSS entity references. Attestation hashes must travel via peer-to-peer USS GETs on operational-intent details, not via the DSS.

ATOMx attestation references can therefore be layered as either (i) extra fields in peer-to-peer operational-intent details, or (ii) an optional JWS-signed claim extending the §X1.2 architecture, without violating F3548. Non-ATOMx USSs will simply ignore the field (permitted under §1.6); ecosystem-wide interop will need a future F3548 revision to standardize the slot.

7. Standards-Body / FAA Path (Recommended Actions)

In priority order:

1. Submit ASTM A5 registrar request for a Specific Authentication Method Type allocation for ATOMx — light-weight, contemplated by the spec, gives a clean interoperable code. (§5.3 path 1.)
2. Submit ASTM F38.02 editorial clarification requesting an explicit normative “MUST ignore unknown AuthType” receiver clause in the next F3411 revision. Non-substantive; helpful for ecosystem hardening. (§5.2 mitigation.)
3. Document in the F3586 DOC compliance file that the device emits an additional F3411 Authentication Message, with §8.6 packet-capture evidence that Part 89 required messages still meet the ≥1 Hz periodicity floor.
4. No FAA petition. No Part 89 amendment. No F3586 supplemental MoC.

8. Confidence and Open Items

High confidence:

• F3411 envelope, AuthType vendor range, and 16-page fragmentation behavior are explicit in the spec text.
• Part 89 / F3586 floor-not-ceiling reading is grounded in F3586 §3.1’s overlay framing and Part 89’s lack of a payload-content prohibition.
• F3548’s §1.6 value-added clause is unambiguous.

Items worth a second pass before final commit:

• The 9-messages-per-pack cap interacts with [BcMinStaticRefreshRate] in a way that needs concrete numeric modeling against the chosen ATOMx attestation cadence. Engineering should produce a timing diagram before locking the Auth payload size.
• The “ignore unknown AuthType” behavior should be empirically validated against a representative receiver matrix (FAA-accepted Standard RID receivers, ASTM reference implementations, popular drone-detection products). The §5.2 editorial-clarification request to F38.02 is the long-term fix; the empirical sweep is the short-term confidence boost.
• F3548-21 is the current published revision; if the next revision (F3548-22+) introduces a standardized extensibility slot, ATOMx should plan to migrate to it.

9. Sources

• ASTM F3411-22a — Standard Specification for Remote ID and Tracking. §5.4.5.9–5.4.5.15 (Auth Message), Table 2 (AuthType enum), Table 8/9 (page layout), §5.4.7.7 BB50120 (9-msg pack cap), Annex A5 (registrar), Annex A1 (Verifier API). 48 pp.
• ASTM F3586-22 — Standard Practice for Remote ID Means of Compliance to 14 CFR Part 89. §3.1 (overlay model), §5.1.3 + Table 3 (Part 89 mandatory message set), §7.5 / §7.6 / §7.8 (tamper / interference / periodicity), §8.6 (DOC packet-capture test). 19 pp.
• ASTM F3548-21 — USS Interoperability. §1.6 (value-added capabilities), §1.7 (Remote ID delegated to F3411), §X1.1 (OAuth/JWT requirements), §X1.2 (optional JWS message signing), §A2 (entity model).
• 14 CFR Part 89 — §§ 89.305 / 89.310 / 89.315 / 89.320 (Standard RID + Broadcast Module requirements). Quoted via F3586-22 Table 3.

10. Cross-References

• Origins and Decisions §3.2 — Layer on top of Remote ID, do not invent a sideband
• Disconnected Operations §5.1 — Coexistence with Regulatory Remote ID
• Open Questions Roll-Up CC-8