Network Working Group S. Das Internet-Draft Independent Inventor Intended status: Informational 18 September 2026 Expires: 22 March 2027 Cleared to Fly or Drive Is Not Cleared to Act: Actuator-Level Execution Finality and Compact Act Evidence for UAS and Autonomous Vehicles draft-das-drip-uas-act-finality-00 Abstract Problem: Unmanned Aircraft System (UAS) trust infrastructure answers two questions well. Remote Identification (RID), strengthened by the Drone Remote ID Protocol (DRIP), answers "who is this aircraft?", and UAS Traffic Management (UTM), U-space, and geo-awareness answer "may this flight take place here and now?". Neither answers the question that decides physical consequence: may this specific act -- arming motors, crossing into a newly restricted volume, releasing a delivery payload, activating a camera over a protected area, emitting on a radio band, or joining a coordinated multi-aircraft manoeuvre -- become effective at this actuator, at this instant, under the airspace and revocation state that is current now? Authorizations are granted before or at take-off, while acts are executed continuously by mission computers and autonomy stacks that can be compromised, misled, coerced with validly signed commands, or cut off from their authorities. Observers on the ground, in turn, can verify an aircraft's identity but not whether what it is doing was authorized before it happened. Solution: The IETF-facing contribution of this document is Compact Broadcast Act Evidence: 16-octet per-act decision records authenticated with a TESLA-style one-way key chain sealed inside a Protected Enforcement Domain and anchored to the aircraft's DRIP identity. This lets an Observer verify, after a short disclosure delay and within the 25-octet Broadcast RID message budget, that the protected enforcement domain made an allow, deny, or safe-state decision before the corresponding evidence key was disclosed, without requiring a public-key signature on every act. The evidence mechanism is coupled to an execution-finality profile in which each safety-significant or externally consequential act remains non- effective as a Candidate Act until the Protected Enforcement Domain verifies an act-bound, sink-bound Execution Handle against live trusted context, consumes current authority state atomically, commits a Finality Receipt, and only then releases the physical enablement condition at the Finality Sink. The profile also specifies act classes and sinks, self-contained object fields, sink processing pseudocode, envelope handles for high-rate control, a boundary- Das Expires 22 March 2027 [Page 1] Internet-Draft UAS/AV Act Finality September 2026 proximity revalidation policy, bounded offline operation, and composite multi-aircraft semantics. For constrained onboard, air-to- air, telemetry, or other small-frame links, the profile also defines an optional Beacon Proof Capsule (BPC): a compact act-bound and sink- bound execution-proof representation using an Authority Reference, freshness and generation state, a context commitment, a keyed binding commitment, explicit truncation-risk sizing, authenticated multi- frame reconstruction when necessary, and fail-closed resolver semantics. A BPC is an input to execution verification; the AER/KDR/ Anchor mechanism is output evidence of the PED decision, and the two roles are intentionally non-interchangeable. Additional profiles: This document also describes three narrowly scoped execution-finality embodiments: conflict-set-bound Detect-and- Avoid (DAA) resolution finality for UAS, emergency-scene temporary authority finality for autonomous road vehicles as an informative cross-domain application, and atomic control-authority handover with monotonic authority epochs for autonomous motion platforms. These profiles preserve the same rule: an authenticated or correctly computed instruction remains a Candidate Act until the current effectuation boundary independently verifies the state on which that instruction depends. In an autonomous road vehicle, that boundary may be a protected motion-admission gate rather than a motor or ESC gate, so the architecture can coexist with the vehicle's existing perception, planning, braking, steering, and minimal-risk-control functions. Industrial context and complementarity: The mechanism complements, and does not replace, Broadcast and Network RID, DRIP Entity Tags and authentication, DET resolution through DNS, UTM and U-space services, geo-awareness, Detect-and-Avoid, flight-control safety logic, automotive ADAS/autonomy stacks, remote-assistance systems, and authenticated command channels. Publicly described examples of the kinds of software-defined or autonomy-enabled platforms to which this boundary can be complementary include Tesla driver-assistance systems, BYD DiPilot and related intelligent-driving platforms, DJI enterprise drone automation, Boeing autonomous and uncrewed aircraft systems, and Lockheed Martin/Sikorsky autonomous aircraft systems. These names are illustrative only: this document does not state or imply that any named organization uses, endorses, requires, or has evaluated this profile. Their existing perception, planning, stabilization, DAA, ADAS, command-and-control, and safety mechanisms remain in place; the proposed finality layer operates later, at a protected motion-admission or actuator boundary, to verify the concrete pending act against current protected authority and state before effectuation. The scope of this document remains strictly civil and excludes weapon release, targeting, and counter-UAS engagement. This is an individual Informational Internet-Draft, not Das Expires 22 March 2027 [Page 2] Internet-Draft UAS/AV Act Finality September 2026 a DRIP WG work item. In short, its IETF/IRTF relevance is to DRIP (DET-anchored compact act evidence for Observers), RATS (attestation of the protected enforcement domain), COSE/CBOR (deterministic compact objects), ACE (constrained scoped authorization as input rather than effectuation), SCITT (later audit of receipts), and T2TRG (constrained Things with multiple authorities). No WG adoption or code-point allocation is requested in this version; the draft is offered for technical discussion in those communities and in UAS, Remote ID, constrained-security, autonomous-vehicle, and aviation standards forums. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on 22 March 2027. Copyright Notice Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/ license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 6 Das Expires 22 March 2027 [Page 3] Internet-Draft UAS/AV Act Finality September 2026 1.1. Problem Space . . . . . . . . . . . . . . . . . . . . . . 6 1.2. Why Standardization Is Required . . . . . . . . . . . . . 7 1.3. Existing Solutions and Their Boundaries . . . . . . . . . 8 1.4. Contributions of This Profile . . . . . . . . . . . . . . 9 1.5. Scope and Non-Goals . . . . . . . . . . . . . . . . . . . 11 1.6. Relationship to Companion Documents . . . . . . . . . . . 11 2. Conventions and Terminology . . . . . . . . . . . . . . . . . 12 3. Mathematical and Cryptographic Notation . . . . . . . . . . . 14 3.1. General Operators and Cryptographic Values . . . . . . . 14 3.2. Execution-Finality and BPC Notation . . . . . . . . . . . 15 3.3. Delayed-Disclosure AER and KDR Notation . . . . . . . . . 17 3.4. Autonomous-Motion Profile Notation . . . . . . . . . . . 18 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . 20 5. UAS Candidate Act Classes and Finality Sinks . . . . . . . . 22 6. Objects . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. UAS Candidate Act Descriptor . . . . . . . . . . . . . . 23 6.2. Compact Integer Keys . . . . . . . . . . . . . . . . . . 25 6.3. Airspace Authority Object . . . . . . . . . . . . . . . . 26 6.4. Execution Handle and Finality Receipt . . . . . . . . . . 26 7. Constrained Execution Proof Capsules . . . . . . . . . . . . 27 7.1. Act, Context, and Binding Commitments . . . . . . . . . . 28 7.1.1. Session-Key Derivation and Key Separation . . . . . . 28 7.2. Compact Authority References . . . . . . . . . . . . . . 29 7.3. Representative BPC and Field Compression . . . . . . . . 29 7.4. Truncation, Collision, and Attacker-Work Budgets . . . . 30 7.5. Capsule Authentication . . . . . . . . . . . . . . . . . 31 7.6. Authenticated Multi-Frame Reconstruction . . . . . . . . 31 7.7. Resolver-Assisted and Cache-Assisted Verification . . . . 32 7.8. Sink-Side BPC Verification . . . . . . . . . . . . . . . 33 7.9. Separation of Execution Proof and Observer Evidence . . . 35 8. Finality Sink Processing . . . . . . . . . . . . . . . . . . 35 8.1. Core Finality Predicate and Atomic Ordering . . . . . . . 35 8.2. Reference Finalization Procedure . . . . . . . . . . . . 36 8.3. Representative Hot-Path Cost Model . . . . . . . . . . . 38 8.4. Envelope Handles for High-Rate Streams . . . . . . . . . 38 9. Live-Context Predicates and Mathematics . . . . . . . . . . . 39 9.1. Corridor Containment and Envelope Predicates . . . . . . 39 9.2. Boundary-Proximity Revalidation Bound . . . . . . . . . . 39 9.3. Multi-Source Position Consistency . . . . . . . . . . . . 40 9.4. Ordering and Residual-Risk Decomposition . . . . . . . . 40 10. Mid-Flight Generation Changes . . . . . . . . . . . . . . . . 41 11. Degraded Link and Bounded Offline Operation . . . . . . . . . 42 12. Fail-Closed Safe States . . . . . . . . . . . . . . . . . . . 42 13. Commands from Authenticated Sources . . . . . . . . . . . . . 43 14. Multi-Aircraft Coordinated Acts . . . . . . . . . . . . . . . 44 15. Conflict-Set-Bound Detect-and-Avoid Maneuver Finality . . . . 45 15.1. Technical Problem . . . . . . . . . . . . . . . . . . . 45 15.2. Architecture and Protected State . . . . . . . . . . . . 46 Das Expires 22 March 2027 [Page 4] Internet-Draft UAS/AV Act Finality September 2026 15.3. Conflict-Set and Safety Mathematics . . . . . . . . . . 47 15.3.1. Current Conflict-Set Equivalence . . . . . . . . . . 48 15.3.2. Resolution Epoch and Competing DAA Sources . . . . . 48 15.4. DAA Finality Workflow . . . . . . . . . . . . . . . . . 48 15.5. DAA Finality Pseudocode . . . . . . . . . . . . . . . . 49 16. Emergency-Scene Temporary Authority Finality . . . . . . . . 50 16.1. Technical Problem . . . . . . . . . . . . . . . . . . . 51 16.2. Emergency Scene Authority Capsule . . . . . . . . . . . 51 16.3. Scene and Authority Mathematics . . . . . . . . . . . . 52 16.4. Emergency-Scene Workflow . . . . . . . . . . . . . . . . 54 16.5. Emergency-Scene Pseudocode . . . . . . . . . . . . . . . 55 17. Atomic Control-Authority Handover and Split-Brain Prevention . . . . . . . . . . . . . . . . . . . . . . . 56 17.1. Technical Problem . . . . . . . . . . . . . . . . . . . 57 17.2. Protected Authority State . . . . . . . . . . . . . . . 57 17.3. Exclusivity and Acceptance Mathematics . . . . . . . . . 58 17.4. Transactional Handover . . . . . . . . . . . . . . . . . 59 17.5. Control-Handover Workflow . . . . . . . . . . . . . . . 59 17.6. Control-Handover Pseudocode . . . . . . . . . . . . . . 60 18. Compact Broadcast Act Evidence for DRIP . . . . . . . . . . . 61 18.1. Technical Problem . . . . . . . . . . . . . . . . . . . 61 18.2. Design . . . . . . . . . . . . . . . . . . . . . . . . . 62 18.3. Default Endorsement Path . . . . . . . . . . . . . . . . 63 18.4. Construction . . . . . . . . . . . . . . . . . . . . . . 63 18.5. Record Formats . . . . . . . . . . . . . . . . . . . . . 64 18.6. Emission Rules . . . . . . . . . . . . . . . . . . . . . 65 18.7. Observer Verification . . . . . . . . . . . . . . . . . 66 18.8. What a Verified Record Does and Does Not Establish . . . 68 18.9. Size and Cost Comparison . . . . . . . . . . . . . . . . 68 18.10. Carriage and Open Issues for DRIP . . . . . . . . . . . 69 19. Onboard Bus Considerations . . . . . . . . . . . . . . . . . 70 20. Relevance to IETF and IRTF Work . . . . . . . . . . . . . . . 70 20.1. Why This Is an Internet-Protocol Boundary Problem . . . 70 20.2. Mapping of the Three Extended Embodiments . . . . . . . 71 20.3. Group-by-Group Relevance . . . . . . . . . . . . . . . . 72 21. Security Considerations . . . . . . . . . . . . . . . . . . . 74 22. Privacy Considerations . . . . . . . . . . . . . . . . . . . 77 23. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 77 24. Reference Implementation, Red-Team Harness, and Reproducibility . . . . . . . . . . . . . . . . . . . . . 77 24.1. How the Reference Harness Was Produced . . . . . . . . . 79 24.2. Current Packaged Test Status . . . . . . . . . . . . . . 79 24.3. Interpretation and Limitations . . . . . . . . . . . . . 80 25. Assumptions, Limitations, and Invitation for Review . . . . . 80 26. References . . . . . . . . . . . . . . . . . . . . . . . . . 81 26.1. Normative References . . . . . . . . . . . . . . . . . . 81 26.2. Informative References . . . . . . . . . . . . . . . . . 82 Das Expires 22 March 2027 [Page 5] Internet-Draft UAS/AV Act Finality September 2026 Appendix A. Appendix: Industrial Deployment Context and Complementarity . . . . . . . . . . . . . . . . . . . . . 85 Appendix B. End-to-End Example: Parcel Delivery with a Mid-Flight Restriction . . . . . . . . . . . . . . . . . . . . . . . 91 Appendix C. Test Vector Classes . . . . . . . . . . . . . . . . 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 92 1. Introduction This document is an individual Informational Internet-Draft. It is not a DRIP Working Group work item and does not request allocation of a DRIP or ASTM/ICAO carriage code point in this version. The compact evidence format and its carriage are presented for technical review and possible future standardization. 1.1. Problem Space An uncrewed aircraft is a moving actuator. Its acts have immediate physical consequence and, once effective, often cannot be recalled: a rotor that spins up near people, a payload that leaves its latch, a camera frame captured over a private garden, or a transmission that interferes with a protected band. Current UAS governance authorizes the flight, identifies the aircraft, and records what happened. It does not, in general, make an individual consequential act depend on authority that is verified at the actuator at the moment of effect. The gap is structural rather than a matter of stricter policy. Consider the following civil situations, each of which occurs within a flight that was validly authorized at take-off: 1. Mid-flight restriction. A delivery aircraft is authorized for a corridor at 14:00. At 14:07 a temporary restriction is activated over part of that corridor for an emergency response. The authorization token held by the ground software is still cryptographically valid; the next corridor segment is no longer lawful. Whether the aircraft enters depends on whether the new geo-zone data reached, and was obeyed by, software that may be stale or compromised. 2. Compromised or misled mission computer. The perception or planning stack is fed adversarial input, runs a faulty update, or is controlled by an attacker with root access. If it has effective write access to motor output registers, ESC arming, the payload latch, or the camera power rail, a software failure becomes a physical event. A software-only geofence running on the same processor can be altered or bypassed by the same failure. Das Expires 22 March 2027 [Page 6] Internet-Draft UAS/AV Act Finality September 2026 3. Validly signed but unsafe command. A ground station, fleet service, or remote pilot sends a correctly authenticated command to release a payload at an unapproved coordinate, disable RID transmission, or enter a restricted volume. Link authentication (for example, MAVLink 2 message signing) establishes that the command came from a key holder. It does not establish that this act is permitted in the present context. 4. Degraded or lost link. The aircraft loses contact with its operator, UTM service, and revocation source. A revocation issued after link loss cannot be learned. Without an explicit bound, cached authority may continue to permit acts indefinitely. 5. Partial coordinated manoeuvre. Several aircraft must change formation or hand off an inspection segment together. If some commit and others do not, separation assumptions are violated. Retries and compensations are themselves new acts. 6. Unverifiable conduct for Observers. A police officer, facility operator, or member of the public can use DRIP to verify that Broadcast RID messages come from the registered owner of a DRIP Entity Tag (DET). They cannot verify whether an act they are watching -- a camera pointed at a stadium, a payload lowered in a car park -- was authorized before it happened, and Broadcast RID has no room for per-act public-key signatures at typical broadcast rates. In all six cases, the missing element is the same: a boundary, positioned immediately before the physical effect, at which authority for this act is verified against current state and consumed, and without which the actuator lacks the physical means to act. 1.2. Why Standardization Is Required Execution finality for aircraft cannot be delivered by one vendor in isolation, for four reasons. 1. Authority originates outside the aircraft. Corridor approvals, temporary restrictions, geo-zone data, operator credentials, revocations, and payload permissions are produced by UTM service suppliers, U-space service providers, aviation authority interfaces, fleet operators, and customers. The aircraft's enforcement domain must interpret their outputs identically. Without a common descriptor, generation model, and binding rule, each airframe would re-implement ad hoc checks that cannot be audited against one another. Das Expires 22 March 2027 [Page 7] Internet-Draft UAS/AV Act Finality September 2026 2. Evidence must be verifiable by parties who did not issue the authority. Regulators, insurers, investigators, and Observers need portable receipts and broadcast evidence with defined formats and verification rules. DRIP already provides the identity and broadcast authentication foundation; act evidence needs to be compatible with it rather than parallel to it. 3. Constrained links force interoperable compactness. Broadcast RID messages are 25 octets. Legacy transports can lose Authentication Message pages. Onboard buses such as classic CAN carry 8-octet payloads. Compact encodings only interoperate if they are specified. 4. Multi-aircraft and multi-authority acts cross administrative domains. A coordinated manoeuvre across operators, or a handoff between service areas, requires common prepare, commit, abort, and hold semantics. 1.3. Existing Solutions and Their Boundaries Each of the following is necessary and well established. None of them, alone or together, makes an individual act non-effective until authority for that act is verified and consumed at the sink. +======================+================+=========================+ | Mechanism | Question it | Boundary relative to | | | answers | this document | +======================+================+=========================+ | Broadcast and | Who is this | Identity and telemetry; | | Network RID (ASTM | aircraft, | no act-level authority. | | F3411 [F3411]; | where is it, | | | regional rules such | who operates | | | as 14 CFR Part 89 | it? | | | and EU Regulation | | | | 2019/945) | | | +----------------------+----------------+-------------------------+ | DRIP: DET [RFC9374], | Who controls | Trustworthy identity, | | architecture | the claimed | resolution, and message | | [RFC9434], | DET, and can | provenance; does not | | authentication | its identity/ | state whether a | | formats [RFC9575], | authentication | physical act was | | and DET/DIME | material be | authorized before it | | resolution in DNS | resolved and | occurred. | | [RFC9886] | verified? | | +----------------------+----------------+-------------------------+ | UTM (ASTM F3548 | May this | Strategic and tactical | | [F3548]) and U-space | flight or | flight authorization; | | (EU Implementing | operation take | enforcement onboard is | Das Expires 22 March 2027 [Page 8] Internet-Draft UAS/AV Act Finality September 2026 | Regulation | place in this | left to the aircraft. | | 2021/664); | airspace and | | | authorization | time? | | | services such as | | | | LAANC | | | +----------------------+----------------+-------------------------+ | Geo-awareness, geo- | Is the | Usually software- | | zone data (for | aircraft | mediated and co-located | | example EUROCAE ED- | inside a | with the stack that can | | 269), vendor geo- | permitted | fail; typically | | zone databases, | volume, and | movement-centric, not | | autopilot geofences | what should it | covering payload, | | and failsafes | do if not? | sensor, and RF acts; | | | | not bound to consumable | | | | per-act authority. | +----------------------+----------------+-------------------------+ | MAVLink 2 message | Did this | Authenticates the | | signing; | message come | channel or sender; a | | authenticated | from a key | valid key holder may | | onboard messaging | holder, and is | still request a | | (for example AUTOSAR | it fresh? | contextually | | SecOC-style | | unauthorized act. | | truncated MAC with | | | | freshness) | | | +----------------------+----------------+-------------------------+ | Secure boot, | Is the | Establishes platform | | measured boot, and | software that | state; runtime | | remote attestation | booted the | deviation, coercion, | | [RFC9334] | expected | and stale authority | | | software? | remain possible after | | | | boot. | +----------------------+----------------+-------------------------+ | Flight logs, post- | What happened? | After the fact; the | | flight analysis, | | effect has already | | Network RID records | | occurred. | +----------------------+----------------+-------------------------+ Table 1: Existing mechanisms and the question each answers 1.4. Contributions of This Profile 1. Compact Broadcast Act Evidence: fixed 16-octet per-act records authenticated with a TESLA-style [RFC4082] one-way key chain sealed in the Protected Enforcement Domain and anchored through DRIP identity, giving Observers loss-tolerant, delayed- disclosure verification inside the Broadcast RID size envelope without a public-key signature on every act (Section 18). Das Expires 22 March 2027 [Page 9] Internet-Draft UAS/AV Act Finality September 2026 2. A constrained execution-proof transport profile using Beacon Proof Capsules (BPCs), compact Authority References, keyed act/sink/context commitments, explicit collision and attacker- work sizing for truncated values, authenticated fragmentation, and resolver-assisted reconstruction (Section 7). A BPC is verification input and is never accepted as broadcast evidence merely because it was received. 3. An act-level UAS profile mapping Candidate Act classes to concrete Finality Sinks and to the physical enablement condition withheld at each sink (Section 5). 4. A placement rule in which the Protected Enforcement Domain sits on every command-to-enablement path, so that a compromised command source cannot itself synthesize actuator authority (Section 4). 5. Live-context enforcement including corridor containment, multi- source position consistency, generation currentness inside atomic consume, and a conservative boundary-proximity revalidation scheduling policy (Section 9). 6. Envelope handles for high-rate actuation streams, so motor setpoints at hundreds of hertz are checked by bounded comparison rather than a public-key operation per setpoint (Section 8.4). 7. A bounded offline mode that converts link loss into a finite residual exposure rather than open-ended cached authority (Section 11). 8. A composite profile for multi-aircraft acts whose prepare step does not move an aircraft and whose HOLD state is a physically safe holding manoeuvre (Section 14). 9. A conflict-set-bound DAA finality profile that binds an accepted avoidance resolution to the conflict set, ownship state, motion sink, and monotonic Resolution Epoch on which the resolution was computed; the sink revalidates the current conflict set and all relevant intruders before admitting the maneuver (Section 15). 10. An informative emergency-scene profile for autonomous road vehicles in which temporary responder authority is bound to the incident, scene, vehicle, bounded traffic-rule exception, concrete motion, expiry, and independent local scene corroboration, and automatically extinguishes when the scene authority ceases to apply (Section 16). Das Expires 22 March 2027 [Page 10] Internet-Draft UAS/AV Act Finality September 2026 11. An atomic control-authority handover profile in which protected current-controller state and monotonic Control Authority Epochs prevent two otherwise valid controllers from simultaneously acquiring ordinary effectuation authority over the same governed sink (Section 17). 1.5. Scope and Non-Goals In scope: civil UAS in the specific and certified categories and comparable national regimes, including delivery, infrastructure inspection, agriculture, mapping, emergency and public-safety support, and urban air mobility support functions. Out of scope: weapons, weapon release, targeting, and counter-UAS engagement. This document does not define airworthiness or certification requirements, does not replace flight-control safety design, does not define legal rules, and does not decide which acts a regulator permits. It defines how a permission that has been issued is technically enforced at the moment of effect, and how that enforcement can be evidenced. A safe-state manoeuvre (hover, loiter, controlled descent, landing, return-to-home) is never blocked by this profile for lack of a fresh handle; safe states are pre-authorized as described in Section 12. Section 16 is intentionally included as an informative cross-domain application to autonomous road vehicles because the same effectuation-boundary problem occurs when a temporary first-responder instruction requests a bounded exception to ordinary motion policy. It does not change the UAS interoperability scope of the BPC, AER, RID, or DRIP mechanisms in this document. Section 17 applies to UAS and may also be reused by other autonomous motion platforms. 1.6. Relationship to Companion Documents This document is intended to be implementable without requiring any companion Internet-Draft. The UAS Candidate Act fields, Authority Object fields, handle bindings, consume ordering, receipt semantics, failure behavior, composite rules, and broadcast-evidence procedures required by this profile are stated locally. Companion individual Internet-Drafts provide broader cross-domain background on execution handles [DAS-HANDLE], registries [DAS-REG], composite finality [DAS-COMPOSITE], jurisdiction binding [DAS-JURISDICTION], actuation binding [DAS-ACTUATION], state continuity [DAS-STATE], revocation [DAS-REVOCATION], consequence-path completeness [DAS-PATH], and the general architecture [DAS-PROTOCOL]. Those references are informative; in case of a difference, the rules in this UAS profile control for this document. Symbolic failure names not allocated by Das Expires 22 March 2027 [Page 11] Internet-Draft UAS/AV Act Finality September 2026 an IANA registry are local to this document. 2. Conventions and Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here. RID, UA, UAS, DET, HDA, Observer, and Broadcast Endorsement are used as in [RFC9153], [RFC9434], and [RFC9575]; DET/DIME resolution through DNS is described by [RFC9886]. The following terms are used in addition. Candidate Act: A proposed UA action whose effect is held non- effective until finality is reached, for example "open payload latch at this location now". Protected Enforcement Domain (PED): An isolated execution environment onboard the UA (secure microcontroller, FPGA region, safety processor, TEE, or HSM-backed controller) that holds verification keys, sealed reference state, consume state, and the evidence key chain, and that controls the enablement conditions of Finality Sinks. The mission computer cannot read its keys, rewrite its predicates, or synthesize its release signal. Finality Sink: The component at which an act first becomes physically or externally effective, for example an ESC enable input, motor output register bank, payload latch driver, RF power- amplifier enable, or camera power rail. Enablement Condition: The physical or cryptographic condition without which the sink cannot produce the effect: an enable line, gated power rail, register write window, radio key, or sensor- output key. UAS Candidate Act Descriptor (U-CAD): The canonical descriptor of a Candidate Act defined by this document. It is compatible in concept with the broader Candidate Act Descriptor described in [DAS-HANDLE], but this document does not depend on that draft. Airspace Authority Object (AAO): A signed object issued by an operator, UTM or U-space service, aviation authority interface, or payload authority that states the corridor, time window, envelopes, and act classes permitted, together with the generations it was issued against. Das Expires 22 March 2027 [Page 12] Internet-Draft UAS/AV Act Finality September 2026 Execution Handle: A non-bearer, sink-bound, act-bound authorization object that the PED verifies and consumes. Possession of a handle confers nothing. Envelope Handle: An Execution Handle with the ENVELOPE reuse policy that authorizes a bounded parameter set over a bounded time window for a high-rate stream. Generation: A monotonically increasing version number of an authority input: airspace and geo-zone data (g_air), revocation state (g_rev), and operator policy (g_pol). Finality Receipt: A PED-signed record of an allow or deny decision committed before release. A receipt is evidence and is never accepted as a handle. Safe-State Set (S_safe): The pre-authorized set of manoeuvres and subsystem states that the PED may select without a fresh handle. Beacon Proof Capsule (BPC): A compact, machine-verifiable representation that carries or references execution-finality evidence for a Candidate Act over a constrained link. A BPC binds the act to its intended sink, authority reference, freshness and current generation state, and selected context. Receipt or possession of a BPC is not by itself authority; the PED and Finality Sink still reconstruct and verify the actual impending act. Authority Reference: A compact identifier, keyed digest, index, cache key, or resolver key by which the PED identifies an AAO or other authority state. The reference is not authority and a cache or resolver miss never degrades to authorization. Binding Commitment: A preferably keyed cryptographic commitment that binds the Candidate Act digest to the Finality Sink, Authority Reference, current-generation inputs, selected context, freshness, and validity scope. A compact BPC may carry only a truncated form selected according to the risk rules in Section 7.4. Evidence key: A PED-held public key, distinct from the UA Host Identity / DET key, used to sign an evidence-epoch Anchor. The DET / Host Identity key endorses the evidence key for a bounded validity period as described in Section 18.3. Conflict Set: The policy-relevant set of cooperative or non- cooperative traffic tracks whose state, uncertainty, freshness, and encounter class are material to a DAA resolution at a given resolution horizon. Das Expires 22 March 2027 [Page 13] Internet-Draft UAS/AV Act Finality September 2026 Conflict-Set Root: A deterministic cryptographic commitment to the canonical Conflict Set used as the safety basis for an accepted DAA resolution. Resolution Epoch: A protected monotonically increasing value identifying the currently selected DAA resolution. Superseding a resolution advances the epoch and invalidates ordinary motion authority bound to an earlier epoch. Emergency Scene Authority Capsule (ESAC): An informative cross- domain authority object binding a temporary first-responder or incident instruction to a vehicle, incident, scene, bounded exception class, concrete motion envelope, expiry, epochs, nonce, and local scene corroboration requirements. Control Authority Epoch: A protected monotonically increasing value associated with the controller currently authorized to exercise ordinary effectuation authority over a governed sink or sink class. Current Controller: The controller identifier recorded in protected authority state for the current Control Authority Epoch of a governed sink. Act Evidence Record (AER): The 16-octet broadcast record defined in Section 18. (The acronym is local to this document.) 3. Mathematical and Cryptographic Notation This section collects notation used by the cryptographic, execution- finality, delayed-disclosure, and autonomous-motion constructions in this document. Symbols are local to this specification unless an external reference states otherwise. In artwork, || denotes byte- string concatenation, not logical OR. Structured objects that are hashed or authenticated are first encoded using the deterministic representation required by the applicable section. 3.1. General Operators and Cryptographic Values H(x), SHA-256(x): A collision-resistant cryptographic hash of x. Where this document writes H(x) generically, a profile may instantiate it with SHA-256 or another specified cryptographic hash. HMAC-SHA-256(K, x) or HMAC_K(x): A keyed message-authentication code over x under secret key K, using HMAC with SHA-256 in the concrete constructions of this profile. Das Expires 22 March 2027 [Page 14] Internet-Draft UAS/AV Act Finality September 2026 Trunc_b(x): The first or otherwise profile-defined b bits of x. The retained length b is security-significant and is selected according to the collision, substitution, or forgery bounds stated in the relevant section. HKDF(K_root, info): A key-derivation operation that derives a purpose- and context-specific key from protected root material K_root and the indicated domain-separation and scope information. det-CBOR(X), C(X), canonical(X): The deterministic or canonical byte serialization of semantic object X. Equality of semantic fields is not sufficient when a cryptographic operation is defined over bytes; the required deterministic encoding is used before hashing or authentication. DOM or quoted domain-separation string: A fixed label separating one cryptographic use from another. For example, "UAS-BPC-ACT", "UAS- BPC-BIND", "UAS-AFE-chain", "UAS-AFE-tag", and "UAS-AFE-rec" prevent values from different cryptographic roles from being treated as interchangeable. In generic explanatory notation, DOM_E denotes the AER record-authentication domain; in this profile its concrete record-domain label is "UAS-AFE-rec". TRUE / FALSE and AND / OR / NOT: Boolean predicates and operators. An implication X => Y means that whenever X is true, Y is required to be true under the stated invariant. 3.2. Execution-Finality and BPC Notation U: The UAS Candidate Act Descriptor (U-CAD) for the concrete pending act. d(U): The deterministic digest of U, defined by this profile as SHA- 256(det-CBOR(U)) unless a section defines a more specific domain- separated act digest. D_A: The domain-separated Act Commitment derived from the canonical Candidate Act. D_C: The domain-separated Context Commitment derived from the selected live or semi-live context material relevant to effectuation. B: The full Binding Commitment that cryptographically binds the act to the Finality Sink, Authority Reference, current-generation state, context, freshness, and validity scope. B_t: The t-bit compact representation Trunc_t(B) carried by a Das Expires 22 March 2027 [Page 15] Internet-Draft UAS/AV Act Finality September 2026 constrained BPC. K_root: Protected root key material from which role-specific keys may be derived. Possession of ordinary mission-computer state does not imply access to K_root. K_B: The BPC or compact-transport authentication key derived for the applicable session and scope. K_bind: The act-binding key used to bind execution semantics to the Candidate Act and Finality Sink. K_bind and K_B are distinct key roles. K_R: The protected Authority-Reference derivation key used by keyed compact Authority Reference constructions. K_frag: The protected key used to authenticate individual fragments belonging to an authenticated multi-frame BPC reconstruction. K_S: A protected sink-local capability-authentication key used to create or verify a bounded execution capability after successful finality verification. K_S is held by, derived within, or otherwise available only to the PED, the applicable Finality Sink, and any specifically authorized downstream capability verifier; it is unavailable to the ordinary act-proposing component. t, r, m: Respectively, the retained Binding-Commitment length, Authority-Reference length, and authentication-tag length, in bits, where used by the relevant construction. q: The approximate number of distinct compact commitments in the collision domain for the birthday-collision estimate. In the emergency-scene q-of-n corroboration equation, q is separately defined locally as the required number of independent validated evidence channels; the local definition controls. W: The assumed offline attacker-work budget, measured in candidate hash or commitment trials, for an unkeyed compact binding. A_online: The maximum or assumed number of online substitution attempts permitted by freshness, replay, rate-limit, lockout, or escalation controls. epsilon_c, epsilon_s, epsilon_f: Target upper bounds for accidental collision, targeted substitution, and aggregate authenticator forgery probability, respectively. R_n: The nth protected Finality Receipt in a receipt chain. Das Expires 22 March 2027 [Page 16] Internet-Draft UAS/AV Act Finality September 2026 H(R_(n-1)) denotes the cryptographic linkage to the preceding committed receipt. 3.3. Delayed-Disclosure AER and KDR Notation The delayed-disclosure construction uses a reverse one-way chain. The indexing in this subsection is normative for interpreting the equations in Section 18. AER intervals are zero-based. Interval i uses a tag key K'_i derived from the then-undisclosed chain value K_(i+1); K_0 is only the public Anchor commitment. K_seed: A random master seed generated inside the PED for an evidence epoch. K_seed is never disclosed to an Observer or transmitter and may be erased after the terminal chain value K_N has been derived and sealed. K_N: The terminal value of the reverse evidence chain. In the concrete profile it is derived from K_seed and the evidence epoch, for example K_N = Trunc_128(SHA-256("UAS-AFE-seed" || K_seed || epoch_id)). Unlike K_seed, K_N is a chain value and may become public if the final usable evidence interval is reached and its scheduled disclosure occurs. K_i: Chain value i in the reverse one-way chain, related by K_i = F(K_(i+1)) for i = N-1 ... 0. F: The domain-separated one-way chain function. The concrete profile defines F(x) = Trunc_128(SHA-256("UAS-AFE-chain" || x)). F': A distinct domain-separated one-way function used only to derive an AER authentication key from an undisclosed chain value. The concrete profile defines F'(x) = Trunc_128(SHA-256("UAS-AFE- tag" || x)). K_0: The public chain commitment carried in the signed Evidence Anchor. K_0 is used to authenticate later disclosed chain values and is not used, directly or through F', as an AER authentication secret. K'_i: The AER authentication key for zero-based evidence interval i, defined as K'_i = F'(K_(i+1)). The prime denotes a derived tag key; K'_i is not itself a member of the reverse chain. I_i: Evidence interval i, defined as [T_0 + i*Delta, T_0 + (i+1)*Delta). i: The zero-based evidence-interval index associated with an AER. Das Expires 22 March 2027 [Page 17] Internet-Draft UAS/AV Act Finality September 2026 j: A later evidence interval whose disclosed chain value K_(j+1) may be used in disclosure verification and loss recovery. Where j is later than i, K_(j+1) can be iterated through F to recover K_(i+1). N: The terminal chain index and the number of zero-based evidence intervals in the epoch: intervals 0 through N-1 use chain values K_1 through K_N. T_0: The authenticated start time of the evidence epoch carried in the Anchor. Delta: The duration of one evidence interval. d: The disclosure lag expressed in whole evidence intervals. The chain value K_(i+1) used for AER interval i becomes public only after the configured delay. hdr or Header_i: The canonical 8-octet AER header associated with interval i. The concrete construction names this value hdr; Header_i is equivalent explanatory notation when the interval must be explicit. tag or TAG_i: The truncated HMAC appended to hdr to form the 16-octet AER. In the default profile it is a 64-bit truncation computed under K'_i. epoch_id: The identifier of the current evidence epoch. It is bound both into terminal chain derivation and AER authentication so chain material and records from one evidence epoch cannot be transplanted into another. ua_det: The DRIP Entity Tag identifying the UA to which the evidence epoch and AER are bound. protected master seed: K_seed (never disclosed) terminal chain value: K_N = Trunc_128(SHA-256( "UAS-AFE-seed" || K_seed || epoch_id)) reverse chain: K_i = F(K_(i+1)) public anchor: K_0 interval i tag key: K'_i = F'(K_(i+1)) disclosure: K_(i+1) after delay d chain authentication: F^((j+1)-k)(K_(j+1)) = K_k loss recovery: K_(i+1) = F^(j-i)(K_(j+1)), j > i 3.4. Autonomous-Motion Profile Notation d(t): The protected estimate of distance from the current position Das Expires 22 March 2027 [Page 18] Internet-Draft UAS/AV Act Finality September 2026 to the nearest relevant boundary of the permitted spatial region at time t, positive while inside the permitted region. eps_pos: The conservative position-uncertainty bound used by the boundary-revalidation rule. v_max: The maximum outward or otherwise relevant permitted speed used in the revalidation bound. tau: The enforcement-to-actuator reaction latency assumed by the stopping-distance model. a_brk: The guaranteed positive deceleration magnitude used by the stopping-distance model. Delta_r: The maximum permitted time between spatial-authority revalidations under the selected boundary-proximity model. p_i and sigma_i: Respectively, the position estimate reported by source i and that source's stated one-sigma uncertainty for the multi-source consistency check. k: A positive, profile-selected uncertainty multiplier defining the required confidence margin in the multi-source position- consistency predicate. q_min: The minimum number of sufficiently independent or partially independent position sources required to agree within the stated uncertainty-dependent consistency bound. ||x||: The applicable spatial-distance norm for vector x; a deployment selects the norm consistently with its position representation and safety analysis. C_root: The deterministic Conflict-Set Root binding the canonical policy-relevant intruder set used as the safety basis of a DAA resolution. r_j, v_j: Relative position and relative velocity of policy-relevant intruder j with respect to ownship for the illustrative closest- point-of-approach calculation. T: The prediction horizon for the illustrative DAA safety calculation. t_CPA,j and d_CPA,j: The predicted time to closest point of approach and distance at closest point of approach for intruder j under the stated illustrative motion model. Das Expires 22 March 2027 [Page 19] Internet-Draft UAS/AV Act Finality September 2026 D_req,j: The required separation distance or applicable well-clear threshold for encounter class j. epsilon_j: A conservative uncertainty margin accounting for surveillance, estimation, latency, or model error relevant to intruder j. m_j(M): The safety margin for candidate maneuver M against intruder j. A negative value indicates failure of the illustrative margin predicate. C_auth, C_now: Respectively, the conflict set used when the maneuver was authorized and the protected current conflict set reconstructed near motion admission. S_scene: The Emergency-Scene Commitment binding the incident, scene geometry, locally validated evidence, temporary-control state, and Scene Epoch. v_i and q in scene corroboration: v_i is the protected binary validation result for independent evidence channel i; q is the locally specified minimum number of independently validated channels required by the q-of-n corroboration rule. E(t): The Boolean predicate stating whether temporary emergency authority remains effective at time t. delta_loc: The conservative localization margin used when dilating an emergency-scene polygon for location-bounded authority. A(c,s,e,t): A Boolean indicator equal to 1 when controller c possesses ordinary effectuation authority over governed sink s in authority epoch e at time t, and 0 otherwise. CurrentController[s], CurrentEpoch[s], CurrentEnvelope[s]: Protected sink-local authority state identifying the controller, monotonic Control Authority Epoch, and permitted act or motion envelope currently valid for sink s. 4. Architecture The mission computer keeps every function it has today: perception, planning, route optimization, obstacle avoidance, inspection logic, and operator assistance. What changes is that its outputs become proposals. The PED sits on every path from a command source to an enablement condition. Das Expires 22 March 2027 [Page 20] Internet-Draft UAS/AV Act Finality September 2026 Off-board authorities Observers / auditors +-----------------------------+ +--------------------+ | Operator | UTM/U-space USS | | DRIP Observer app | | Aviation authority | Payload| | Regulator, insurer | +--------------+--------------+ +---------^----------+ | AAO, revocation, g_air | AER + key v | disclosure +--------------------------- UA ----------------------|------------+ | | | | +------------------+ proposals +---------------+--------+ | | | Mission computer |-------------->| Protected Enforcement | | | | autonomy, AI, | | Domain (PED) | | | | planner, GCS link|<--decisions---| keys | sealed refs | | | +------------------+ | consume | receipts | | | | evidence key chain | | | +------------------+ trusted | safe-state logic | | | | GNSS/RTK, VIO, |-------------->| | | | | IMU, baro, time, | context +---+-----+-----+-----+--+ | | | battery, ESC tel.| | | | | | | +------------------+ enable/ | | | | | | release v v v v | | +------+ +-----+ +----+ +-------+ | | RID module <-- AER ---------| ESC / | |Latch| | RF | |Camera/| | | (Broadcast RID, DRIP) | motor | |power| | PA | |sensor | | | | regs | | | | EN | | power | | | +------+ +-----+ +----+ +-------+ | | Finality Sinks (default: disabled) | +-------------------------------------------------------------------+ Figure 1: Placement of the Protected Enforcement Domain Three authorities are kept separate. Computation authority belongs to the mission computer. Resource and airspace authority belongs to off-board issuers and is carried in AAOs. Effect authority exists only at the PED and is expressed as a released enablement condition. A compromise of the first does not yield the third. The PED MUST hold every protected enablement condition in the non- effective state by default. A command signal that reaches a sink without the corresponding enablement condition MUST NOT produce the effect. The mission computer, debug ports, maintenance interfaces, and radio command links MUST NOT have a path to a protected register bank or enable line that bypasses the PED; this is the path- completeness requirement of [DAS-PATH] applied to the airframe. Das Expires 22 March 2027 [Page 21] Internet-Draft UAS/AV Act Finality September 2026 The stabilizing inner control loop may run in the flight controller outside the PED. The PED gates the envelope within which that loop may drive the motors, and the arming condition, rather than every inner-loop computation. This keeps real-time attitude control where it is today. 5. UAS Candidate Act Classes and Finality Sinks +==================+=================+=============+================+ | Act class | Example |Finality Sink| Withheld | | (code); reuse | | | condition | +==================+=================+=============+================+ | ARM (0x01); | Arm motors for |ESC arming | ESC enable | | SINGLE_USE | take-off |register / | asserted | | | |enable line | | +------------------+-----------------+-------------+----------------+ | KINETIC_ENVELOPE | Fly segment k |Motor output | Write window | | (0x02); ENVELOPE | within |register | for setpoints | | | corridor at |bank, thrust | inside | | | speed <= v_max |limit | envelope | +------------------+-----------------+-------------+----------------+ | VOLUME_ENTRY | Enter geo-zone |Envelope | New envelope | | (0x03); | Z or next |expansion at | released | | SINGLE_USE | corridor |PED | | | | segment | | | +------------------+-----------------+-------------+----------------+ | PAYLOAD_RELEASE | Lower or |Latch | Solenoid power | | (0x04); | release a |solenoid or | window | | SINGLE_USE | delivery |winch driver | | | | parcel at drop | | | | | zone D | | | +------------------+-----------------+-------------+----------------+ | SENSOR_ACTIVATE | Camera on, |Camera power | Rail enable or | | (0x05); ENVELOPE | resolution R, |rail or | output key | | | field of view |sensor-output| | | | F, area A |key | | +------------------+-----------------+-------------+----------------+ | RF_EMIT (0x06); | Transmit video |Power | PA enable, | | ENVELOPE | downlink on |amplifier | register | | | band B at |enable, | permit | | | power P |frequency | | | | |register | | +------------------+-----------------+-------------+----------------+ | MODE_TRANSITION | Switch from |Flight-mode | Register write | | (0x07); | assisted to |register | permit | | SINGLE_USE | autonomous | | | | | BVLOS mode | | | +------------------+-----------------+-------------+----------------+ Das Expires 22 March 2027 [Page 22] Internet-Draft UAS/AV Act Finality September 2026 | RID_CHANGE | Change RID |RID module | Configuration | | (0x08); | transmission |enable and | write permit | | SINGLE_USE | state |configuration| | +------------------+-----------------+-------------+----------------+ | COORDINATED | Formation |Each | Per-child | | (0x09); | change across |aircraft's | release after | | Composite child | N aircraft |kinetic sink | composite | | | | | commit | +------------------+-----------------+-------------+----------------+ | SAFE_STATE | Hover, loiter, |Flight | Pre-authorized | | (0x3F); n/a | descend, land, |controller | (no handle) | | | return-to-home |safe-state | | | | |path | | +------------------+-----------------+-------------+----------------+ Table 2: Act classes, sinks, and enablement conditions RID_CHANGE requests that would suppress legally required RID transmission MUST be denied unless an authority object explicitly permits the change, since the enforcement domain is the component that must not be coercible into making the aircraft anonymous. 6. Objects Objects are encoded as deterministic CBOR [RFC8949] (Section 4.2 of that document) when carried onboard or over constrained links, and MAY be encoded as JCS JSON [RFC8785] off-board. Signatures use COSE [RFC9052]. The CDDL [RFC8610] below uses text keys for readability. The compact integer-key mapping in Section 6.2 is the encoding RECOMMENDED on onboard buses. Implementations that speak only the text-key form MUST still produce the same deterministic digest over the integer-key encoding when computing d(U), or declare that they use the text-key encoding for digesting and never mix the two. 6.1. UAS Candidate Act Descriptor Das Expires 22 March 2027 [Page 23] Internet-Draft UAS/AV Act Finality September 2026 u-cad = { "v" : 1, "act_class" : uint, ; Table 2 code "ua_det" : bstr .size 16, ; DRIP Entity Tag of this UA "sink_id" : bstr .size 8, ; PED-local sink identifier "act_id" : bstr .size 16, ; random per Candidate Act "params" : act-params, ; load-bearing parameters only "ctx_digest" : bstr .size 32, ; digest of live context snapshot "g_air" : uint, ; airspace/geo-zone generation "g_rev" : uint, ; revocation generation "g_pol" : uint, ; operator policy generation "aao_digest" : bstr .size 32, ; authority object relied on ? "composite": { "id": bstr .size 16, "digest": bstr .size 32 } } act-params = kinetic-env / volume-entry / payload / sensor / rf / other kinetic-env = { "corridor_id" : bstr, "segment" : uint, "v_max_cms" : uint, "a_max_cms2" : uint, "h_min_dm" : int, "h_max_dm" : int, "t_start" : uint, "t_end" : uint ; seconds, GNSS time } payload = { "drop_zone_id" : bstr, "h_max_dm" : uint, "v_max_cms" : uint, "tilt_max_cdeg" : uint } sensor = { "sensor" : uint, "res_class" : uint, "fov_cdeg" : uint, "area_id" : bstr, "t_end" : uint } rf = { "band_id" : uint, "p_max_dbm" : int, "t_end" : uint } volume-entry = { "zone_id" : bstr, "g_air" : uint } other = { * tstr => any } The descriptor digest is d(U) = SHA-256(det-CBOR(U)) [RFC6234]. Only load-bearing fields are included; fields that do not change the effect MUST NOT be added, so that the sink can reconstruct the descriptor from the pending act rather than trusting a caller- supplied digest. Das Expires 22 March 2027 [Page 24] Internet-Draft UAS/AV Act Finality September 2026 6.2. Compact Integer Keys When the compact profile is used, text keys MUST be replaced by the following major integers before deterministic encoding. Unknown keys are rejected. +===============+=========+=====================================+ | Text key | Integer | Object | +===============+=========+=====================================+ | v | 1 | U-CAD, AAO, handle, receipt, anchor | +---------------+---------+-------------------------------------+ | act_class / | 2 | U-CAD / AAO | | act_classes | | | +---------------+---------+-------------------------------------+ | ua_det | 3 | all UA-bound objects | +---------------+---------+-------------------------------------+ | sink_id | 4 | U-CAD, handle | +---------------+---------+-------------------------------------+ | act_id | 5 | U-CAD | +---------------+---------+-------------------------------------+ | params | 6 | U-CAD | +---------------+---------+-------------------------------------+ | ctx_digest | 7 | U-CAD, receipt | +---------------+---------+-------------------------------------+ | g_air / | 8 | U-CAD / AAO | | g_air_min | | | +---------------+---------+-------------------------------------+ | g_rev / | 9 | U-CAD / AAO | | g_rev_min | | | +---------------+---------+-------------------------------------+ | g_pol | 10 | U-CAD | +---------------+---------+-------------------------------------+ | aao_digest | 11 | U-CAD | +---------------+---------+-------------------------------------+ | composite | 12 | U-CAD | +---------------+---------+-------------------------------------+ | issuer | 13 | AAO | +---------------+---------+-------------------------------------+ | corridor | 14 | AAO | +---------------+---------+-------------------------------------+ | envelopes | 15 | AAO | +---------------+---------+-------------------------------------+ | t_start / | 16 / 17 | AAO, params | | t_end | | | +---------------+---------+-------------------------------------+ | quorum | 18 | AAO | +---------------+---------+-------------------------------------+ | offline | 19 | AAO | Das Expires 22 March 2027 [Page 25] Internet-Draft UAS/AV Act Finality September 2026 +---------------+---------+-------------------------------------+ | reuse | 20 | handle (0=SINGLE_USE, 1=ENVELOPE) | +---------------+---------+-------------------------------------+ | expiry | 21 | handle | +---------------+---------+-------------------------------------+ | nonce | 22 | handle | +---------------+---------+-------------------------------------+ | act_digest | 23 | handle (= d(U)) | +---------------+---------+-------------------------------------+ | decision | 24 | receipt (0=DENY, 1=ALLOW, 2=SAFE) | +---------------+---------+-------------------------------------+ | n | 25 | receipt counter | +---------------+---------+-------------------------------------+ | prev | 26 | previous receipt digest | +---------------+---------+-------------------------------------+ | handle_digest | 27 | receipt | +---------------+---------+-------------------------------------+ | code | 28 | receipt deny code | +---------------+---------+-------------------------------------+ Table 3: Compact CBOR keys for U-CAD and AAO 6.3. Airspace Authority Object aao = { "issuer" : tstr, ; operator, USS/USSP, authority "ua_det" : bstr .size 16, "act_classes" : [+ uint], "corridor" : corridor, "envelopes" : { * uint => any }, ; per act class bounds "g_air_min" : uint, ; lowest acceptable g_air "g_rev_min" : uint, "t_start" : uint, "t_end" : uint, "quorum" : { * uint => uint }, ; act class => required signers "offline" : { "t_max" : uint, "classes" : [* uint] } } corridor = [+ prism] prism = { "poly" : [3* [lat_e7: int, lon_e7: int]], "h_min_dm" : int, "h_max_dm" : int } ; carried inside COSE_Sign1; multiple issuers => COSE_Sign The AAO is resolved by the PED and never by the mission computer. Possession of an AAO by any software component confers no authority. 6.4. Execution Handle and Finality Receipt An Execution Handle in this profile is a COSE_Sign1 (or COSE_Sign, when the AAO quorum requires it) object that binds at minimum: Das Expires 22 March 2027 [Page 26] Internet-Draft UAS/AV Act Finality September 2026 * d(U) (field act_digest), sink_id, ua_det; * g_air, g_rev, g_pol as known to the issuer at issuance; * reuse policy (SINGLE_USE or ENVELOPE), expiry, and a nonce; * for ENVELOPE, the envelope parameters and any aggregate ceiling (for example D_max). The handle is non-bearer: possession without a successful consume at the named sink confers no effect. Identical SINGLE_USE handles MUST be refused on the second consume. A Finality Receipt is a PED-signed COSE_Sign1 that binds the decision, d(U) when known, the handle digest when a handle was presented, ctx_digest when a context snapshot was taken, the selected safe state on deny, a monotonic receipt counter n, the previous receipt digest, and, when evidence is emitted, the same 8-octet AER header that was queued. A receipt MUST NOT be accepted as a handle (deny code EF-008). A protected receipt chain may authenticate each committed receipt against the preceding receipt. One representative construction, preserving the provisional receipt-chain invariant, is: R_n = Auth_K( Header_n || B_n || Counter_n || H(R_(n-1)) ) Here B_n is the applicable Binding Commitment or equivalent act-bound decision commitment. The exact authenticator is profile-specific; the required property is that deleting, reordering, substituting, or rolling back a committed receipt is detectable by the protected receipt state. 7. Constrained Execution Proof Capsules This section defines an optional compact transport profile for execution verification over links where the full AAO, full Execution Handle, or complete policy state is too large or too costly to transmit on every act. It is distinct from the Compact Broadcast Act Evidence mechanism of Section 18. A BPC is presented before effectuation as verification input. An AER, KDR, Anchor, or Finality Receipt is evidence about a decision and MUST NOT be accepted as a BPC or Execution Handle. Das Expires 22 March 2027 [Page 27] Internet-Draft UAS/AV Act Finality September 2026 7.1. Act, Context, and Binding Commitments The U-CAD already provides the canonical Candidate Act U and d(U). For a BPC, the PED additionally forms a selected Context object Ctx containing only state material to the effect, for example corridor or geo-zone generation, geographic cell, altitude band, mission phase, payload state, flight mode, RF mode, and policy or revocation state. Exact coordinates need not be broadcast. D_A = SHA-256( "UAS-BPC-ACT" || det-CBOR(U) ) D_C = SHA-256( "UAS-BPC-CTX" || det-CBOR(Ctx) ) B = HMAC-SHA-256(K_bind, "UAS-BPC-BIND" || D_A || sink_id || authority_ref || g_air || g_rev || g_pol || D_C || freshness || expiry) B_t = Trunc_t(B) K_bind is held or derived inside the PED and the verifying Finality Sink and is unavailable to the mission computer, ordinary transmitter, and other act-proposing components. A deployment may use an unkeyed binding only where the retained length is sized against the offline substitution budget in Section 7.4. Changing a load-bearing act field, sink, authority, generation, context, freshness value, or expiry therefore changes the expected binding. Sink_2 != Sink_1 => Binding(A, Sink_2) != Binding(A, Sink_1) except with the bounded cryptographic collision probability 7.1.1. Session-Key Derivation and Key Separation A deployment may derive distinct capsule-authentication and act- binding keys from a common protected root. A representative derivation is: K_B = HKDF(K_root, "BEACON" || SessionNonce || DeviceID || PolicyEpoch || SinkClass) K_bind = HKDF(K_root, "BIND" || SessionNonce || DeviceID || SinkID) The derivations intentionally use different domain-separation labels and different scope inputs. K_B authenticates the compact transport object; K_bind binds execution semantics to the act and Finality Sink. Disclosure or compromise of one derived-key role therefore does not intentionally collapse the two roles. Equivalent KDFs may be used where they provide the same separation property. Das Expires 22 March 2027 [Page 28] Internet-Draft UAS/AV Act Finality September 2026 Key evolution used for ordinary undisclosed session keys is distinct from the reverse chain used for delayed-disclosure evidence. A forward erasure ratchet may evolve as: K_(i+1) = H(K_i) ; erase K_i after use Because disclosure of K_i would reveal all later values in that construction, a forward ratchet MUST NOT be used as the delayed- disclosure evidence chain of Section 18. That evidence chain runs in the reverse direction so that disclosure authenticates past intervals without revealing later undisclosed evidence keys. 7.2. Compact Authority References A BPC need not carry the AAO in full. The PED may maintain an authenticated local cache of AAOs and use a compact Authority Reference. A preferred keyed construction first derives a stable full digest of the deterministic AAO payload and then derives a short reference under a protected reference key K_R: D_AAO = SHA-256( det-CBOR(AAO-payload) ) R = Trunc_r( HMAC-SHA-256(K_R, "UAS-BPC-AUTHREF" || D_AAO) ) K_R is not available to the mission computer or ordinary beacon transmitter. An unkeyed reference may be used only when r is selected using an applicable attacker-work budget. Resolution MUST occur in or under control of the PED or Finality Sink. Unknown, stale, ambiguous, revoked, or unresolved Authority References MUST NOT authorize effectuation. 7.3. Representative BPC and Field Compression A representative BPC contains the following logical fields. The precise byte layout is profile-specific; fields may be implicit from protected session state, dictionary-indexed, delta-encoded, or recovered from local state. This version defines no IANA allocation for BPC profiles. Das Expires 22 March 2027 [Page 29] Internet-Draft UAS/AV Act Finality September 2026 ; Semantic BPC. Integer keys are illustrative profile-local labels. bpc = { 0 : 1, ; version 1 : uint, ; profile_id 2 : uint, ; act_class 3 : uint, ; sink class or compact sink id 4 : bstr, ; authority_ref, typically 4 or 8 octets 5 : uint, ; g_air or session-relative airspace generation 6 : uint, ; g_rev 7 : uint, ; g_pol 8 : uint, ; freshness / sequence 9 : uint, ; expiry delta or time-slot 10 : bstr, ; context_ref_or_digest 11 : bstr, ; B_t, compact Binding Commitment 12 : uint, ; flags / risk profile 13 : bstr ; capsule authenticator } Non-limiting compression includes compact act and sink dictionaries, a 32- or 64-bit Authority Reference, expiry delta instead of an absolute timestamp, corridor or geo-cell references instead of coordinates, a compact Context Commitment, and bitmaps for authenticated predicate state. A predicate bitmap is advisory unless covered by the capsule authenticator and never substitutes for the sink's own protected checks. 7.4. Truncation, Collision, and Attacker-Work Budgets Truncation length is selected explicitly rather than by convenience. Let t be the retained number of Binding Commitment bits and q the approximate number of distinct commitments in the relevant collision domain. The birthday estimate for accidental coincidence is: P_coll ~= q(q-1) / 2^(t+1) for target epsilon_c: t >= ceil( log2( q(q-1) / (2 * epsilon_c) ) ) For an unkeyed commitment whose inputs are known or predictable, an attacker may search offline for a substituted act producing the same short value. With W offline trials: P_sub ~= W / 2^t for target epsilon_s: t >= ceil( log2( W / epsilon_s ) ) Das Expires 22 March 2027 [Page 30] Internet-Draft UAS/AV Act Finality September 2026 For a keyed binding where offline search is unavailable without K_bind, a targeted attacker is limited to online attempts that encounter freshness and replay controls: P_sub <= A_online / 2^t These expressions size compact fields; they are not an airworthiness or total system-failure probability. The selected t therefore depends on safety class, act rate, fleet size, session lifetime, replay-cache lifetime, whether the binding is keyed, and the accepted attempt budget. Higher-consequence act classes may use longer compact commitments. If a receiver's protected cache or reconstruction process finds more than one full candidate consistent with the same short value, it MUST NOT choose one heuristically. It MUST deny the consequential act or escalate to a profile carrying a longer commitment or full proof. Trunc_t(B_1) = Trunc_t(B_2) AND B_1 != B_2 => Ambiguous Ambiguous => Effectuate(CandidateAct) = FALSE 7.5. Capsule Authentication In addition to B_t, the BPC is authenticated as a complete transport object. A symmetric constrained profile may compute: Tag = Trunc_m( HMAC-SHA-256(K_B, "UAS-BPC-CAPSULE" || canonical(BPC_without_Tag)) ) K_B is a protected session or link key. For an expected aggregate attacker verification budget A and permitted aggregate forgery probability epsilon_f, a deployment can select: A / 2^m <= epsilon_f m >= ceil( log2( A / epsilon_f ) ) Other authenticated constructions may be used where their security and field sizes meet the applicable profile. The capsule authenticator protects the transport representation; B_t separately binds the execution semantics to the actual act and sink. 7.6. Authenticated Multi-Frame Reconstruction If a complete BPC or its referenced proof material does not fit one transport unit, it may be fragmented. Let P be the complete encoded proof and p_i its ordered fragments. A protected sender computes: Das Expires 22 March 2027 [Page 31] Internet-Draft UAS/AV Act Finality September 2026 P = p_0 || p_1 || ... || p_(n-1) Root = SHA-256( "UAS-BPC-FRAG-ROOT" || P ) F_i = { SessionID, Root, i, n, p_i, Auth_i } Auth_i = Trunc_m( HMAC-SHA-256(K_frag, "UAS-BPC-FRAG" || SessionID || Root || i || n || p_i) ) No individual fragment is execution authority. The verifier MUST authenticate the required fragment set, require a common SessionID and Root, reconstruct the ordered proof, and verify the Root before continuing normal finality verification. A fragment from another session, root, fragment count, policy generation, or device context MUST NOT be mixed into the reconstruction. IncompleteEvidence => NoEffectuation FragmentsReceived < RequiredFragments => Effectuate(CandidateAct) = FALSE Verify(BPC) != TRUE => Effectuate(CandidateAct) = FALSE A missing or corrupted fragment, unknown Authority Reference, unresolved context reference, stale generation, invalid capsule tag, ambiguous sink, collision-guard trigger, absent freshness state, or incomplete reconstruction therefore leaves the consequential Candidate Act non-effective. Safe-State Set actions remain available. 7.7. Resolver-Assisted and Cache-Assisted Verification A protected resolver may be used when the constrained link carries only an Authority Reference and compact commitment. The PED supplies at least the Authority Reference, Binding Commitment or compact value, UA reference, current generation information, and requested act class. The resolver may return the resolved AAO and authenticated resolver proof. The resolver does not decide the physical act; the PED and Finality Sink still reconstruct the actual impending U-CAD and apply current local state. Das Expires 22 March 2027 [Page 32] Internet-Draft UAS/AV Act Finality September 2026 PROCEDURE RESOLVE_BPC_AUTHORITY(bpc): aao := PROTECTED_CACHE_LOOKUP(bpc.authority_ref) IF aao IS NOT NULL: RETURN aao IF authenticated_resolver_available: response := RESOLVER_QUERY(bpc.authority_ref, bpc.binding_commitment, SELF.det, CURRENT_GENERATIONS()) IF VERIFY_RESOLVER_RESPONSE(response): CACHE_PROTECTED(response.aao) RETURN response.aao RETURN UNKNOWN UNKNOWN is not EMPTY and is not authorization. A cache miss or resolver failure MUST result in no permission expansion; the PED may hold, request refresh, use a permitted Safe-State Set action, or require a full AAO over another authenticated path. 7.8. Sink-Side BPC Verification The sink never trusts an upstream description of the act merely because the BPC authenticated correctly. It independently reconstructs the pending U-CAD and recomputes the expected binding from actual local command and actuator state. Das Expires 22 March 2027 [Page 33] Internet-Draft UAS/AV Act Finality September 2026 PROCEDURE PED_FINALIZE_BPC(pending_act, bpc, sink): ASSERT sink.enable == DISABLED IF NOT BPC_COMPLETE_AND_AUTHENTIC(bpc): RETURN SAFE_DENY("BPC_INCOMPLETE_OR_INVALID") U_actual := RECONSTRUCT_UCAD(pending_act, sink) IF U_actual IS NULL: RETURN SAFE_DENY("BPC_ACT_RECONSTRUCT_FAILED") AAO_current := RESOLVE_BPC_AUTHORITY(bpc) IF AAO_current == UNKNOWN: RETURN SAFE_DENY("BPC_AUTHORITY_UNKNOWN") C_current := SNAPSHOT_TRUSTED_CONTEXT() D_A := SHA256("UAS-BPC-ACT" || DET_CBOR(U_actual)) D_C := SHA256("UAS-BPC-CTX" || DET_CBOR(SELECT_BOUND_CONTEXT(C_current))) B_actual := HMAC_SHA256(K_bind, "UAS-BPC-BIND" || D_A || sink.id || bpc.authority_ref || bpc.g_air || bpc.g_rev || bpc.g_pol || D_C || bpc.freshness || bpc.expiry) IF TRUNC(B_actual, bpc.binding_bits) != bpc.binding_commitment: RETURN SAFE_DENY("BPC_BINDING_MISMATCH") BEGIN ATOMIC G := READ_CURRENT_GENERATIONS() IF NOT BPC_GENERATIONS_CURRENT_OR_PERMITTED(bpc, G, U_actual): ABORT SAFE_DENY("BPC_GENERATION_STALE") IF NOT CONSUME_BPC_FRESHNESS(bpc): ABORT SAFE_DENY("BPC_REPLAY") R := MAKE_RECEIPT(ALLOW, HASH(U_actual), HASH(bpc), CTX_DIGEST(C_current), n := counter + 1, prev := r_last) COMMIT(R) END ATOMIC IF COMMIT_STORE_UNAVAILABLE: RETURN SAFE_DENY("BPC_RECEIPT_STORE_UNAVAILABLE") RELEASE(sink, SCOPED_ENABLEMENT(U_actual, AAO_current, bpc.expiry)) EMIT_ACT_EVIDENCE(R) # optional evidence output; never authority input RETURN ALLOW Das Expires 22 March 2027 [Page 34] Internet-Draft UAS/AV Act Finality September 2026 7.9. Separation of Execution Proof and Observer Evidence The BPC and AER mechanisms serve opposite directions of trust. A BPC is consumed before effectuation to help determine whether the exact impending act may become effective. An AER is emitted only after the PED has committed an allow, deny, or safe-state receipt and is later verified by Observers. Accordingly: AcceptAsAuthority(x) => x NOT IN {Receipt, AER, KDR, Anchor} TreatAsObserverEvidence(BPC) => FALSE unless separately profiled as evidence This role separation is load-bearing. Replaying a valid AER, KDR, Anchor, or Finality Receipt at a sink cannot create execution authority, and possession of a BPC cannot be used to claim that the corresponding physical act actually occurred. 8. Finality Sink Processing The following non-normative pseudocode shows the processing order. The order is normative: static verification, then reading current state and consuming inside one atomic section, then committing the receipt, then releasing. 8.1. Core Finality Predicate and Atomic Ordering A representative conjunction for the BPC path is: ALLOW = AuthValid AND ActMatch AND SinkMatch AND Fresh AND NotReplayed AND PolicyCurrent AND RevocationCurrent AND ContextMatch AND BeaconAuthentic AND EvidenceComplete Additional act-class predicates may strengthen this conjunction. No omitted predicate is implied to be optional where another section requires it. The replay and receipt state transitions precede capability release: Das Expires 22 March 2027 [Page 35] Internet-Draft UAS/AV Act Finality September 2026 Consumed(N) = TRUE => Accept(N) = FALSE CapabilityReleased => NonceConsumed AND ReceiptCommitted ReadCurrentEpochs <= ConsumeNonce <= CommitReceipt(n) < ReleaseCapability < Effectuate(A) Epoch_presented != Epoch_current(read inside commit) => Effectuate(A) = FALSE unless an explicitly defined compatibility rule applies Within the ordering artwork, X < Y means that X strictly completes before Y may occur, while X <= Y means that X occurs no later than Y and may be ordered within the same protected atomic transaction. These symbols express required happens-before relationships rather than wall-clock duration. Current policy and revocation state used for the deciding result are read inside the protected commit, not only during an earlier pre-check. Where the verifying PED and physical actuator boundary are separate, successful verification may derive a short-lived sink-local capability: E = MAC_KS( B || SinkID || ActuatorEnvelope || Counter ) Effectuate(A) => Verify_KS(E) K_S is the protected sink-local capability-authentication key defined in Section 3.2. E is local bounded execution authority, not a transferable bearer token; it is scoped to the verified Binding Commitment, sink, actuator envelope, and protected counter state. 8.2. Reference Finalization Procedure PROCEDURE PED_FINALIZE(pending_act, handle, sink): # 0. Default: enablement condition is withheld. Initialize audit fields # so any early denial can be recorded without dereferencing unset state. ASSERT sink.enable == DISABLED U := NULL dU := NULL C := NULL raw_handle_digest := HASH_IF_PRESENT(handle) # 1. Reconstruct; never trust a caller-supplied digest. U := RECONSTRUCT_UCAD(pending_act, sink) IF U IS NULL: DENY(RECONSTRUCT_FAILED) dU := SHA256(DET_CBOR(U)) Das Expires 22 March 2027 [Page 36] Internet-Draft UAS/AV Act Finality September 2026 # 2. Static verification (no mutable state read). IF NOT VERIFY_COSE(handle, issuer_keys): DENY(SIG_INVALID) IF handle.act_digest != dU: DENY(ACT_MISMATCH) IF handle.sink_id != sink.id: DENY(SINK_MISMATCH) IF handle.ua_det != SELF.det: DENY(UA_MISMATCH) IF U.act_class NOT IN AAO(handle).act_classes: DENY(CLASS_NOT_PERMITTED) # 3. Live context from trusted sources inside the PED. C := SNAPSHOT_TRUSTED_CONTEXT() # GNSS/RTK, VIO, IMU, baro, # time, battery, ESC telemetry IF NOT POSITION_CONSISTENT(C): SELECT_SAFE(LOC_CONFIDENCE_LOW) IF NOT PREDICATES_HOLD(U, AAO(handle), C): DENY(PREDICATE_FAILED) # 4. Atomic section: currentness + consume + receipt commit. BEGIN ATOMIC G := READ_CURRENT_GENERATIONS() # g_air, g_rev, g_pol IF handle.g_rev < G.g_rev AND REVOKES(G, handle): ABORT DENY(EF-062) IF handle.g_air < G.g_air AND AFFECTS(G.airspace_delta, U): ABORT DENY(EF-061) IF handle.g_air < G.g_air AND NOT AFFECTS(G.airspace_delta, U): NOTE(GEN_ADVANCED_NOT_AFFECTING) # only if AAO permits IF NOT CONSUME(handle, U, reuse_policy): ABORT DENY(CONSUMED) R := MAKE_RECEIPT(ALLOW, dU, raw_handle_digest, CTX_DIGEST_IF_PRESENT(C), n := counter + 1, prev := r_last) COMMIT(R) # crash-consistent, monotonic END ATOMIC IF COMMIT_STORE_UNAVAILABLE: DENY(EF-081) # fail closed # 5. Release only after receipt commit. RELEASE(sink, SCOPED_ENABLEMENT(U, handle, t_expiry)) EMIT_ACT_EVIDENCE(R) # broadcast evidence, optional RETURN ALLOW PROCEDURE DENY(code): # dU and C may be NULL for an early parsing or signature failure. # The denial receipt records only values already established by the PED. R := MAKE_DENY_RECEIPT(code = code, act_digest = dU, raw_handle_digest = raw_handle_digest, ctx_digest = CTX_DIGEST_IF_PRESENT(C), sink_id = sink.id, n = counter + 1, prev = r_last) IF COMMIT(R): EMIT_ACT_EVIDENCE(R) Das Expires 22 March 2027 [Page 37] Internet-Draft UAS/AV Act Finality September 2026 sink.enable := DISABLED # unchanged SELECT_SAFE(MAP_TO_SAFE_STATE(IF_DEFINED(U.act_class), code)) RETURN DENY A denial MUST NOT cause loss of controlled flight. Denial of a payload act keeps the latch locked and continues flight; denial of a sensor act removes sensor power while preserving navigation sensors; denial of a volume entry holds or reroutes; denial of a kinetic envelope clamps to the last valid envelope or begins a controlled descent according to Section 12. 8.3. Representative Hot-Path Cost Model For a locally cached authority path, a representative verification latency may be decomposed as: T_verify = T_parse + T_lookup + T_MAC + T_hash + T_replay + T_receipt + T_compare This is an implementation cost model, not a mandated latency target. It makes explicit why certificate-chain validation, resolver synchronization, and complex policy parsing are preferably cold-path operations while the actuation hot path uses bounded local checks. 8.4. Envelope Handles for High-Rate Streams Motor setpoints are issued at hundreds of hertz; per-setpoint handles are neither necessary nor practical. An Envelope Handle authorizes the set E = { u : |v(u)| <= v_max, |a(u)| <= a_max, h_min <= h(u) <= h_max, p(u) in Corridor_k } over window W = [t_s, t_e] and every setpoint u_j at time t_j is admitted by the sink-side comparator if and only if u_j is in E and t_j is in W and the aggregate ceiling is not exceeded, for example cumulative distance D_j = sum over i <= j of |p_i - p_(i-1)| <= D_max. This check is a set of range comparisons that can be implemented in FPGA logic or a secure microcontroller within one control period. Leaving E, leaving W, or exceeding the ceiling ends the envelope; further motion requires a new handle or a safe state. Identical repeats of a SINGLE_USE handle MUST be refused. Das Expires 22 March 2027 [Page 38] Internet-Draft UAS/AV Act Finality September 2026 9. Live-Context Predicates and Mathematics This section states predicates and conservative scheduling relationships used by the PED. They are protocol-policy inputs, not airworthiness or certification formulas. Notation: p(t) is the UA position in a local East-North-Up frame derived from trusted sources; Corridor_k is the permitted volume for segment k; d(t) is the signed horizontal-or-vertical distance from p(t) to the nearest boundary of Corridor_k (positive inside); v_max is the envelope speed bound; a_brk is a conservative guaranteed deceleration value established for the applicable airframe/state by protected configuration or attested safety data; tau is a conservative upper bound on sensing, PED, controller, and actuator reaction delay; and eps_pos is the position uncertainty bound. 9.1. Corridor Containment and Envelope Predicates P_corr(t) := p(t) in Corridor_k AND h_min <= h(t) <= h_max P_time(t) := t_start <= t <= t_end P_vel(t) := |v(t)| <= v_max AND |a(t)| <= a_max P_gen := g_air(handle) = g_air* OR (g_air(handle) < g_air* AND delta(g_air*) does not intersect Corridor_k over [t, t_end]) P_rev := NOT revoked(handle, g_rev*) P_payload := p(t) in DropZone AND h(t) <= h_drop_max AND |v(t)| <= v_drop_max AND tilt(t) <= tilt_max P_sensor := footprint(p(t), attitude, fov) subset of PermittedArea AND res_class <= res_permitted Starred quantities are read inside the atomic section of Section 8. P_sensor uses the projected sensor footprint rather than aircraft position, because a camera outside a protected area can still image inside it. 9.2. Boundary-Proximity Revalidation Bound Envelope authority is revalidated at an interval Delta_r. Between two revalidations the aircraft can move at most v_max * Delta_r, and after a failed revalidation it needs a stopping distance s_stop(v_max) = v_max * tau + v_max^2 / (2 * a_brk) For the aircraft never to leave Corridor_k undetected, the following condition is sufficient: v_max * Delta_r + s_stop(v_max) + eps_pos <= d(t) => Delta_r(t) <= ( d(t) - eps_pos - s_stop(v_max) ) / v_max Das Expires 22 March 2027 [Page 39] Internet-Draft UAS/AV Act Finality September 2026 When this scheduling profile is selected, the PED MUST use conservative, protected values for a_brk, tau, and eps_pos and schedule the next revalidation no later than the resulting Delta_r(t). A deployment MUST substitute a more conservative certified or safety-engineered stopping model where the point-mass expression is not adequate. If the right-hand side is less than or equal to zero, the PED MUST NOT release further outward motion and MUST either reduce v_max or select a safe state. The revalidation rate therefore rises near boundaries and may fall in the interior. Worked example: d = 60 m, eps_pos = 5 m, v_max = 15 m/s, a_brk = 5 m/ s^2, tau = 0.1 s gives s_stop = 1.5 + 22.5 = 24 m and Delta_r <= (60 - 5 - 24) / 15 = 2.07 s; at d = 30 m the bound is 0.07 s and the PED instead lowers v_max to 8 m/s, giving s_stop = 7.2 m and Delta_r <= 2.23 s. Revalidation is also triggered by events, independent of Delta_r: arrival of a new generation, waypoint transition, altitude-band change, payload-state change, RF-mode change, sensor disagreement, and battery or thermal threshold crossings. 9.3. Multi-Source Position Consistency Given m independent position sources with estimates p_i and stated one-sigma uncertainties sigma_i, the PED computes the fused estimate p_hat and requires for all i, j : |p_i - p_j| <= k * (sigma_i + sigma_j) eps_pos := k * max_i sigma_i count of agreeing sources >= q_min (q_min >= 2 RECOMMENDED) with k a positive profile-selected uncertainty multiplier (for example 3), q_min the minimum number of sufficiently independent or partially independent sources that must agree, and |.| denoting the profile's applicable spatial-distance norm. Disagreement is treated as insufficient location confidence: no envelope expansion, no volume entry, no payload release, no sensor activation over area-scoped permissions. A single spoofed GNSS source that diverges from visual- inertial odometry or barometric altitude beyond the bound therefore removes authority rather than steering it. 9.4. Ordering and Residual-Risk Decomposition For every allowed act the following ordering holds: t_verify_static < t_read_current <= t_consume <= t_commit(R) < t_release < t_effect Das Expires 22 March 2027 [Page 40] Internet-Draft UAS/AV Act Finality September 2026 The remaining risk is usefully decomposed, but this document does not assign a single numerical probability bound to the complete cyber- physical system. Relevant contributors include cryptographic collision or forgery risk (eps_hash, eps_sig), protected-state or crash-consistency failure (eps_store), an unmodelled or bypassing consequence path (eps_path), and trusted-context failure within the accepted tolerance (eps_ctx): residual_risk := { eps_hash, eps_sig, eps_store, eps_path, eps_ctx } The cryptographic terms may be made negligible under their stated assumptions; eps_path and eps_ctx are engineering and assurance quantities, not cryptographic constants. In particular, eps_ctx depends on sensor independence, q_min, stated uncertainty, environmental conditions, and the applicable threat model. The decomposition is intended to expose these assumptions rather than to present an airworthiness or certification probability. 10. Mid-Flight Generation Changes A new airspace generation g_air' (for example activation of a temporary restriction) can arrive through Network RID services, a USS or USSP, or a data link. On receipt, the PED verifies its signature and monotonicity (g_air' > g_air*), atomically updates g_air*, and evaluates the delta against every outstanding handle: ON NEW_GENERATION(update): IF NOT VERIFY(update) OR update.g <= g_air*: IGNORE_AND_LOG BEGIN ATOMIC g_air* := update.g FOR h IN OUTSTANDING_HANDLES(): IF INTERSECTS(update.delta, h.corridor, [now, h.t_end]): INVALIDATE(h) # future consume fails IF h.reuse == ENVELOPE AND h.active: END_ENVELOPE(h) # stops admitting setpoints SELECT_SAFE(REROUTE_OR_HOLD) END ATOMIC REQUEST_NEW_AAO_IF_LINK_AVAILABLE() A UA that has not received a generation cannot enforce it. This is why the offline bound of Section 11 exists and why AAOs carry g_air_min: an authority can refuse to issue handles to an aircraft whose last acknowledged generation is stale. Das Expires 22 March 2027 [Page 41] Internet-Draft UAS/AV Act Finality September 2026 11. Degraded Link and Bounded Offline Operation At link loss time t_L the PED enters offline mode. In offline mode it MAY continue to honour handles that were already issued, only for act classes listed in the AAO's "offline.classes", and only until t_off_end = min( t_L + T_off_max , h.t_end for each handle h ) after which only S_safe is permitted. New handles MUST NOT be created offline for SINGLE_USE classes other than those listed. PAYLOAD_RELEASE and SENSOR_ACTIVATE SHOULD NOT be listed as offline classes. Receipts are appended to a sealed local buffer protected by the monotonic counter and are reconciled when the link returns. The residual exposure to a revocation or restriction issued after t_L is therefore bounded and computable: T_exposure <= T_off_max D_exposure <= v_max * T_off_max (inside last released envelope) Operators and authorities can choose T_off_max per operation class. This converts "the aircraft kept flying on cached authority" into a stated, auditable bound. 12. Fail-Closed Safe States +==================+=========================+=====================+ | Condition | Kinetic effect | Other subsystems | +==================+=========================+=====================+ | Volume entry | Hold (multirotor hover, | Unchanged | | denied / | fixed-wing loiter) or | | | generation | reroute inside last | | | affects corridor | valid corridor | | +------------------+-------------------------+---------------------+ | Payload | Continue flight | Latch locked, | | predicate fails | | solenoid unpowered | +------------------+-------------------------+---------------------+ | Sensor predicate | Continue flight | Camera power | | fails | | removed; navigation | | | | sensors kept | +------------------+-------------------------+---------------------+ | RF predicate | Continue flight | Payload radio | | fails | | silent; command- | | | | and-control and RID | | | | links kept | +------------------+-------------------------+---------------------+ | Location | Hold, then controlled | Payload locked, | | confidence low | descent if not | area-scoped sensors | Das Expires 22 March 2027 [Page 42] Internet-Draft UAS/AV Act Finality September 2026 | | recovered in T_loc | off | +------------------+-------------------------+---------------------+ | Envelope | Clamp to envelope, or | Unchanged | | exceeded | controlled landing if | | | | clamping is unsafe | | +------------------+-------------------------+---------------------+ | Offline window | Return-to-home or land | Payload locked | | expired | at nearest pre-approved | | | | site | | +------------------+-------------------------+---------------------+ | Consume or | Hold, then land | All non-safety | | receipt store | | sinks disabled | | unavailable (EF- | | | | 081) | | | +------------------+-------------------------+---------------------+ Table 4: Denial causes and default safe-state selection S_safe is fixed in PED firmware or FPGA logic and is part of the attested measurement. It cannot be widened by the mission computer. Safe-state manoeuvres use the flight controller's existing stabilization and landing logic. a IN S_safe => Available(a) regardless of Verify(BPC) The invariant applies only to the pre-authorized stabilizing or risk- reducing action set; failure of ordinary authorization therefore does not itself remove the protected means to maintain or reach a safe state. 13. Commands from Authenticated Sources A command from a ground station, fleet service, or remote pilot that is correctly signed is treated as a Candidate Act, not as authority. The PED evaluates it against the same predicates. A validly signed command to enter a restricted volume, release a payload outside a drop zone, exceed an envelope, activate a sensor over a protected area, disable RID, or join an unauthorized coordinated act is denied. For act classes that the AAO marks with a quorum, the handle MUST carry the required COSE_Sign signatures (for example remote pilot plus fleet safety authority plus payload authority). Q = { A_1, A_2, ... , A_n } QuorumValid(Q, k) <=> | { A_i : Verify(A_i) = TRUE } | >= k Das Expires 22 March 2027 [Page 43] Internet-Draft UAS/AV Act Finality September 2026 The threshold result is still only one input to finality: the exact act, sink, freshness, current epochs, and live context remain independently verified. 14. Multi-Aircraft Coordinated Acts A coordinated act across N aircraft (formation change, synchronized handoff of an inspection segment, simultaneous corridor swap) follows [DAS-COMPOSITE] with the ALL_REQUIRED join rule and the following UAS-specific constraints. 1. Prepare never moves an aircraft. Prepare reserves consume state for the child handle and verifies predicates for the post-act envelope; the current envelope stays in force. 2. Each child PED releases its new envelope only after reading COMMIT for the composite identifier from the composite decision log. 3. HOLD is a physical holding manoeuvre within the current envelope, not an idle software state. A fixed-wing child holds by loitering inside its current corridor. 4. If the decision log is reachable and empty when a child's reserve expires, the child writes ABORT by compare-and-swap (first writer wins). If the log is unreachable, the child holds (EF-048) and never commits on silence. 5. Compensation (for example returning to the original formation) is a new Candidate Act with new handles, never a reuse of consumed ones. NON_EFFECTIVE --all prepared--> PREPARED --log COMMIT--> EFFECTUATED | | \ | any prepare fails | \--log unreachable--> HOLD v v | ABORTED <-- CAS ABORT on reserve expiry (log reachable) <------+ (log returns) Figure 2: Composite states for a coordinated act Each participating unit also derives its own act/sink/context binding. One representative per-unit construction is: B_i = HMAC_(K_bind,i)( D_A || Sink_i || Context_i || N_i ) Das Expires 22 March 2027 [Page 44] Internet-Draft UAS/AV Act Finality September 2026 A common high-level coordinated proposal therefore does not create transferable authority between units; a proof valid for unit i does not automatically authorize unit j. For the informative autonomous-road-vehicle application, a cooperative manoeuvre negotiated between vehicles or roadside infrastructure may use a more specific participant binding: B_v = HMAC_(K_bind,v)( D_M || Sink_v || TrajDigest_v || LaneGroup || SpeedBand || TimeSlot || E_P || E_R || N_v ) D_M is the digest of the agreed manoeuvre and TrajDigest_v is the trajectory envelope assigned to vehicle v. The vehicle motion- admission sink reconstructs the trajectory actually produced by its planner and admits it only on match. For an all-required cooperative manoeuvre, the protected HOLD state is the current lane-and-speed envelope or another profile-defined minimal-risk state. No-split property: because every child release requires reading the same committed log entry, and the log accepts exactly one of COMMIT or ABORT per composite identifier, no execution exists in which one child effectuates under COMMIT while another effectuates under ABORT. Liveness depends on log reachability; safety does not. 15. Conflict-Set-Bound Detect-and-Avoid Maneuver Finality 15.1. Technical Problem A DAA system can correctly identify an intruder and compute a valid resolution maneuver at an initial time, while the traffic picture changes before that maneuver reaches the motion-admission boundary. A second intruder can become relevant, a track can move or be reclassified, uncertainty can expand, a surveillance source can become stale, ownship state can diverge, or another DAA source can supersede the earlier resolution. Authentication of the original DAA output proves neither that its safety basis is still current nor that the trajectory actually presented to the flight controller is the trajectory that was evaluated. Das Expires 22 March 2027 [Page 45] Internet-Draft UAS/AV Act Finality September 2026 The profile therefore does not reduce DAA finality to "check for collisions before moving". It binds the accepted resolution to the complete policy-relevant Conflict Set, ownship state, Resolution Epoch, motion sink, and validity horizon on which the resolution was computed. Immediately before motion admission, the protected domain reconstructs the current Conflict Set and the actual impending motion and refuses effectuation if the accepted safety basis is no longer equivalent. 15.2. Architecture and Protected State +--------------------+ +--------------------+ | Traffic sources | | Protected ownship | | cooperative / | | GNSS / IMU / VIO | | non-cooperative | | time / flight state| +---------+----------+ +---------+----------+ \ / \ / v v +------------------------------+ | DAA computation engine | | proposes resolution M | +--------------+---------------+ | Candidate M v +------------------------------+ | Protected DAA Finality Domain| | ConflictSetRoot | ResEpoch | | current-set revalidation | +-----------+------------------+ | scoped motion capability v +------------------------------+ | Motion-admission Finality Sink| | reconstruct actual trajectory | +-----------+------------------+ | match + current safety v Flight controller | deny ---->+----> Safe-Action Set Figure 3: Conflict-set-bound DAA finality The DAA engine may remain ordinary or high-performance software. It computes proposed resolutions but does not itself hold the final actuator authority. The protected DAA Finality Domain maintains at least the canonical Conflict Set or an authenticated membership Das Expires 22 March 2027 [Page 46] Internet-Draft UAS/AV Act Finality September 2026 representation, its Conflict-Set Root, protected ownship state, source-health and freshness state, the current Resolution Epoch, nonces or sequence state, and the receipt state used by the motion- admission sink. For each policy-relevant intruder j, a canonical descriptor may include track reference, source class, cooperative or non-cooperative class, relative position, relative velocity, acceleration estimate where used, covariance or bounded uncertainty, freshness, closest- point-of-approach quantities, track confidence, provenance reference, and an encounter or right-of-way class. Descriptors are deterministically sorted before the Conflict-Set Root is computed. 15.3. Conflict-Set and Safety Mathematics C_root = H( CanonicalSort(I_1 || I_2 || ... || I_n) ) A DAA Resolution Descriptor binds at least C_root, an ownship-state commitment, the proposed maneuver or trajectory-tube digest, the Resolution Epoch, the motion-admission sink, a validity horizon, the applicable safety profile, sensor-source epochs, policy and revocation state, freshness, and a nonce. One non-limiting constant-velocity safety check for intruder j is: t_CPA,j = clamp( -(r_j . v_j) / ||v_j||^2, 0, T ) d_CPA,j = || r_j + v_j * t_CPA,j || m_j(M) = d_CPA,j(M) - (D_req,j + epsilon_j) MultiIntruderSafe(M) <=> min_j m_j(M) >= 0 r_j and v_j are relative position and velocity, T is the prediction horizon, D_req,j is the required separation for the encounter class, and epsilon_j is a conservative margin for surveillance uncertainty, state-estimation error, latency, and applicable model error. This document does not require constant-velocity CPA; a certified DAA algorithm, reachable-set method, probabilistic conflict model, velocity-obstacle method, well-clear logic, or another deterministic safety predicate may replace it. The load-bearing requirement is multi-intruder atomicity: a maneuver accepted to resolve one conflict does not obtain authority if it creates or leaves an unacceptable conflict with another policy- relevant track. Das Expires 22 March 2027 [Page 47] Internet-Draft UAS/AV Act Finality September 2026 15.3.1. Current Conflict-Set Equivalence Eq(C_auth, C_now) = SameRelevantMembers AND FreshEnough AND DeltaUncertainty <= U_max AND NoNewHigherRiskTrack Exact set equality is the strongest profile, but an implementation may define a deterministic equivalence predicate that admits bounded changes proven not to invalidate the resolution. A newly relevant intruder, a removed track without a trusted termination reason, stale source state, material uncertainty expansion, or a changed encounter class SHOULD force recomputation unless the selected profile defines and verifies a safe equivalence rule. 15.3.2. Resolution Epoch and Competing DAA Sources When airborne DAA, ground-based DAA, UTM conflict services, autopilot obstacle avoidance, or a remote pilot can each propose a resolution, the protected domain maintains a monotonic Resolution Epoch. Superseding the accepted resolution increments the epoch and invalidates all ordinary motion capabilities bound to the prior epoch. Accept(M) => M.resolution_epoch == CurrentResolutionEpoch This prevents two individually authenticated or individually valid DAA outputs from simultaneously steering the aircraft under different traffic snapshots. 15.4. DAA Finality Workflow 1. Acquire protected ownship state and cooperative and non- cooperative traffic state, including source provenance, freshness, uncertainty, and source health. 2. Classify policy-relevant tracks for the applicable horizon, canonicalize their descriptors, and compute the Conflict-Set Root. 3. Allow the DAA engine to compute candidate resolutions, but keep each resolution non-effective. 4. Bind the selected resolution to the Conflict-Set Root, ownship state, Resolution Epoch, motion sink, trajectory digest, safety profile, horizon, freshness, and current authority state. Das Expires 22 March 2027 [Page 48] Internet-Draft UAS/AV Act Finality September 2026 5. Evaluate the selected maneuver against every relevant intruder and create a prepared finality record if the selected safety predicate succeeds. 6. Immediately before motion admission, rebuild the current policy- relevant Conflict Set and current ownship state from protected sources. 7. Reject or recompute if the Resolution Epoch changed, the Conflict Set is not equivalent, required source state is stale, or any current safety margin fails. 8. Atomically commit the finality record and release a trajectory- envelope capability bound to the current Resolution Epoch and motion-admission sink. 9. The sink reconstructs the actual trajectory envelope presented by the planner and admits it only when it matches the authorized envelope and the epoch is still current. 10. Any later conflict-set change, source-health failure, policy change, epoch advance, or expiry invalidates the outstanding motion capability and leaves the Safe-State Set available. 15.5. DAA Finality Pseudocode Das Expires 22 March 2027 [Page 49] Internet-Draft UAS/AV Act Finality September 2026 PROCEDURE FINALIZE_DAA_RESOLUTION(candidate_M, descriptor, sink): ASSERT sink.motion_expansion == DISABLED own_auth := READ_PROTECTED_OWNSHIP() C_auth := LOAD_CONFLICT_SET(descriptor.conflict_root) REQUIRE descriptor.resolution_epoch == CURRENT_RESOLUTION_EPOCH() REQUIRE FRESH(own_auth) REQUIRE REQUIRED_TRACKS_FRESH(C_auth) REQUIRE HASH(candidate_M) == descriptor.maneuver_digest REQUIRE sink.id == descriptor.sink_id FOR EACH intruder j IN C_auth: REQUIRE SAFETY_MARGIN(candidate_M, own_auth, j) >= 0 PREPARE_DAA_FINALITY(descriptor) BEGIN ATOMIC own_now := READ_PROTECTED_OWNSHIP() C_now := BUILD_CURRENT_RELEVANT_CONFLICT_SET() epoch := CURRENT_RESOLUTION_EPOCH() IF epoch != descriptor.resolution_epoch: ABORT RECOMPUTE("RESOLUTION_EPOCH_CHANGED") IF NOT CONFLICT_EQUIVALENT(C_auth, C_now): ABORT RECOMPUTE("CONFLICT_SET_CHANGED") FOR EACH intruder j IN C_now: IF SAFETY_MARGIN(candidate_M, own_now, j) < 0: ABORT RECOMPUTE("CURRENT_MARGIN_FAIL") R := COMMIT_DAA_RECEIPT( descriptor_digest = HASH(descriptor), current_conflict_root = ROOT(C_now), resolution_epoch = epoch) END ATOMIC actual_M := RECONSTRUCT_ACTUAL_TRAJECTORY(sink) IF NOT MATCHES_AUTHORIZED_MOTION(actual_M, candidate_M): RETURN SAFE_DENY("DAA_TRAJECTORY_SUBSTITUTION") RELEASE(sink, MOTION_CAPABILITY(HASH(actual_M), epoch, HASH(R))) RETURN ALLOW 16. Emergency-Scene Temporary Authority Finality Das Expires 22 March 2027 [Page 50] Internet-Draft UAS/AV Act Finality September 2026 16.1. Technical Problem This subsection is an informative cross-domain application to autonomous road vehicles. At an emergency scene, a police officer, firefighter, road worker, or other authorized responder may legitimately request a vehicle to perform a motion that ordinary road policy would reject: cross a lane marking, reverse, stop in an unusual position, enter a temporarily restricted lane, or follow a temporary path around an incident. Simply authenticating the responder does not establish that the instruction applies to this vehicle, this incident, this scene, this concrete motion, or the present time, and should not create unrestricted remote-driving authority. The profile therefore creates temporary authority that is incident- bound, scene-bound, vehicle-bound, act-bound, sink-bound, time- bounded, independently corroborated by local scene evidence, and automatically extinguished when the applicable scene condition ends. 16.2. Emergency Scene Authority Capsule +----------------------+ +----------------------+ | Responder / incident | | Vehicle-local scene | | authority service | | perception / sensors | +----------+-----------+ +----------+-----------+ | ESAC | corroboration v v +------------------------------------------+ | Protected Vehicle Finality Domain | | incident | scene | vehicle | exception | | nonce | epochs | expiry | scene digest | +-------------------+----------------------+ | temporary capability v +------------------------------------------+ | Motion-admission Finality Sink | | reconstruct actual path and exception | +-------------------+----------------------+ | v Vehicle motion completion / expiry / scene exit / revocation | +----> invalidate authority Figure 4: Scene-bound temporary motion authority Das Expires 22 March 2027 [Page 51] Internet-Draft UAS/AV Act Finality September 2026 An Emergency Scene Authority Capsule (ESAC) may bind the vehicle identifier, responder role and authority reference, incident identifier and incident epoch, emergency-scene identifier, scene polygon or scene commitment, instruction class, permitted path or trajectory digest, speed and acceleration envelope, explicit traffic- rule exception class, start time and expiry, scene-evidence commitment, policy and revocation epochs, motion sink identifier, and nonce. The responder identity is necessary but not sufficient. The protected vehicle domain independently derives local scene state from available protected or corroborated sources, for example emergency- vehicle presence, responder presence, temporary signs, lane closure, cone geometry, road blockage, fire or smoke scene, infrastructure state, or another profile-defined scene signal. Perception output alone is evidence and does not directly unlock steering, throttle, or braking authority. 16.3. Scene and Authority Mathematics The emergency-scene profile preserves separate mathematical treatment of scene commitment, corroboration, temporary-authority validity, geographic scope, motion admissibility, and automatic authority extinction. These predicates are conjunctive at the finality boundary; responder authentication alone is not sufficient. A representative scene commitment is: S_scene = H( IncidentID || ScenePolygon || LocalEvidenceDigest || TemporaryControlDigest || SceneEpoch ) Local physical corroboration may be represented by q-of-n protected validation results. Let v_i be 1 when independent evidence channel e_i satisfies its profile-defined validation rule and 0 otherwise: SceneCorroborated <=> sum_i v_i >= q A profile SHOULD prevent multiple messages or observations derived from the same physical source from being counted as independent evidence. Higher-consequence exception classes may require both valid responder authority and at least one independent local physical confirmation. Das Expires 22 March 2027 [Page 52] Internet-Draft UAS/AV Act Finality September 2026 Let E(t) denote whether the temporary emergency authority is effective at time t. One representative validity rule is: E(t) = CredentialValid AND IncidentCurrent AND SceneMatch(S_scene) AND VehicleMatch AND t <= t_exp AND NOT Revoked AND NOT Consumed For a location-bounded emergency scene, localization uncertainty may be incorporated by dilating the authorized scene polygon by a conservative margin delta_loc: position(t) IN Dilate(ScenePolygon, delta_loc) The Candidate Emergency Maneuver M may become effective only when temporary authority remains valid, the requested traffic-rule exception is explicit, the actual reconstructed motion lies within the emergency envelope, hard safety predicates remain satisfied, and finality-specific sink and epoch checks succeed: Allow(M) = E(t) AND ExplicitExceptionMatch(M) AND M IN EmergencyEnvelope AND HardSafety(M, state) AND ActualMotionMatch(M) AND SinkMatch AND PolicyEpochCurrent AND RevocationEpochCurrent AND Fresh ActualMotionMatch(M) is evaluated over the motion reconstructed at or adjacent to the motion-admission Finality Sink, rather than solely over an upstream responder instruction or planner description. SinkMatch requires that the temporary authority name the same governed motion-admission sink that would make the act effective. PolicyEpochCurrent and RevocationEpochCurrent are evaluated against protected current state. The temporary exception is narrowly scoped. It authorizes only the concrete exception and motion envelope expressed by the ESAC; it does not disable ordinary hard safety predicates or create a standing override. Das Expires 22 March 2027 [Page 53] Internet-Draft UAS/AV Act Finality September 2026 completion OR expiry OR scene_exit OR incident_change OR revocation OR corroboration_loss OR policy_epoch_change OR revocation_epoch_change OR sink_mismatch => TemporaryAuthority := INVALID Automatic extinction is load-bearing. A cryptographically valid ESAC that is replayed outside its incident, scene, vehicle, epoch, path, validity window, or named Finality Sink cannot authorize effectuation. Loss of required local corroboration also removes the temporary permission expansion while preserving the applicable Safe- State Set. 16.4. Emergency-Scene Workflow 1. Receive or resolve a responder or incident authority artifact and verify the responder role, authority reference, revocation state, incident identifier, and incident epoch. 2. Construct or receive an ESAC that states the vehicle, scene, permitted instruction class, concrete path or envelope, bounded traffic-rule exception, sink, expiry, epochs, and nonce. 3. Keep the requested exception non-effective while the vehicle derives protected local scene state independently of the responder message. 4. Verify that local scene evidence sufficiently corroborates the incident and scene commitment required by the ESAC. 5. Reconstruct the actual planned motion at the motion-admission sink rather than trusting an upstream path label. 6. Verify that the actual motion is within the emergency envelope, that every traffic-rule departure is expressly covered by the exception class, and that ordinary hard safety predicates still hold. 7. Atomically consume freshness, commit an emergency finality receipt, and release a single-use or short-lived motion capability bound to the incident, scene epoch, actual motion digest, exception class, and sink. 8. At the sink, re-check expiry, incident and scene epoch where applicable, and the actual motion before admission. Das Expires 22 March 2027 [Page 54] Internet-Draft UAS/AV Act Finality September 2026 9. On completion, expiry, scene exit, incident closure or change, revocation, required-corroboration loss, or policy change, invalidate all temporary scene capabilities and restore ordinary road authority. 16.5. Emergency-Scene Pseudocode Das Expires 22 March 2027 [Page 55] Internet-Draft UAS/AV Act Finality September 2026 PROCEDURE FINALIZE_EMERGENCY_SCENE_ACT(esac, planned_path, sink): BLOCK_TEMPORARY_EXCEPTION_EXPANSION() KEEP_SAFE_ACTIONS_AVAILABLE() REQUIRE VERIFY_RESPONDER_AUTHORITY(esac.authority_ref) REQUIRE INCIDENT_CURRENT(esac.incident_id, esac.incident_epoch) REQUIRE VEHICLE_MATCH(esac.vehicle_binding) REQUIRE NOT_REVOKED(esac) REQUIRE NOW() <= esac.expiry local_scene := BUILD_PROTECTED_LOCAL_SCENE_STATE() REQUIRE SCENE_MATCH(esac.scene_commitment, local_scene) actual_path := RECONSTRUCT_ACTUAL_MOTION(planned_path, sink) REQUIRE PATH_WITHIN_EMERGENCY_ENVELOPE(actual_path, esac) REQUIRE EXCEPTION_EXPLICITLY_COVERS(esac, actual_path) REQUIRE HARD_SAFETY_PREDICATES_PASS(actual_path, local_scene) BEGIN ATOMIC REQUIRE NONCE_UNUSED(esac.nonce) CONSUME(esac.nonce) R := COMMIT_EMERGENCY_RECEIPT( esac_digest = HASH(esac), scene_digest = HASH(local_scene), path_digest = HASH(actual_path), decision = ALLOW) END ATOMIC RELEASE(sink, TEMP_MOTION_CAPABILITY( incident_id = esac.incident_id, scene_epoch = esac.scene_epoch, path_digest = HASH(actual_path), exception_class = esac.exception_class, receipt_digest = HASH(R), expiry = esac.expiry)) RETURN ALLOW ON completion OR expiry OR incident_change OR scene_exit OR revocation OR corroboration_loss OR policy_epoch_change: INVALIDATE_SCENE_CAPABILITIES() RESTORE_ORDINARY_AUTHORITY() 17. Atomic Control-Authority Handover and Split-Brain Prevention Das Expires 22 March 2027 [Page 56] Internet-Draft UAS/AV Act Finality September 2026 17.1. Technical Problem An autonomous motion platform can have multiple controllers that are each individually legitimate: an autonomy stack, remote pilot, remote-assistance service, fleet controller, DAA safety controller, local human operator, emergency authority, or minimal-risk controller. The critical failure is therefore not only an unauthorized controller. Network delay, partial handover, retry, failover, duplicated sessions, stale credentials, or recovery can leave two authorized controllers believing that each controls the same steering, thrust, braking, trajectory-admission, or mode- transition boundary. This profile treats control transfer itself as a Candidate Act. Protected state records the Current Controller and Control Authority Epoch for each governed sink or sink class. PREPARE, COMMIT, and ENABLE semantics change this state transactionally, and every ordinary control command is accepted only when its controller identity and epoch match current protected authority state. 17.2. Protected Authority State +---------------+ +---------------+ | Controller A | | Controller B | | epoch e | | pending e+1 | +-------+-------+ +-------+-------+ \ / \ / v v +------------------------------+ | Protected Authority State | | current_controller_id | | authority_epoch | | envelope | handover_state | +--------------+---------------+ | current controller + epoch only v +------------------------------+ | Governed Finality Sink | | reject stale controller/epoch| +--------------+---------------+ v Actuator PREPARE(B) -> COMMIT(epoch e+1) -> ENABLE(B) partial failure -> Safe-Action Set Figure 5: Atomic controller handover Das Expires 22 March 2027 [Page 57] Internet-Draft UAS/AV Act Finality September 2026 AuthorityState[sink] = { current_controller_id, authority_epoch, permitted_act_classes, current_envelope_digest, handover_state, prepared_new_controller_id, prepared_envelope_digest, expiry, revocation_epoch, monotonic_counter, prior_receipt_digest } The state may be maintained per vehicle, actuator class, motion- admission sink, or another control domain. Independent non- conflicting sinks may have different Current Controllers, but sinks whose simultaneous control can conflict MUST enforce exclusivity through the same protected authority state. 17.3. Exclusivity and Acceptance Mathematics Let A(c,s,e,t) be 1 when controller c has ordinary effectuation authority over sink s in epoch e at time t and 0 otherwise. The exclusivity invariant is: for all s,e,t: sum_c A(c,s,e,t) <= 1 A separately defined Safe-State Set does not violate this invariant when it is restricted to stabilizing or risk-reducing actions and cannot expand ordinary authority. Accept(cmd) => cmd.controller_id == CurrentController[s] AND cmd.epoch == CurrentEpoch[s] AND cmd.sink_id == s AND cmd.act IN CurrentEnvelope[s] AND Fresh(cmd) A credential that remains cryptographically valid after a handover does not preserve actuation authority if its controller identifier or epoch is stale. Das Expires 22 March 2027 [Page 58] Internet-Draft UAS/AV Act Finality September 2026 17.4. Transactional Handover A preferred handover has three logical phases. PREPARE verifies the proposed new controller, its requested sink set, authority basis, freshness, revocation state, and requested control envelope while the old controller remains responsible for bounded continuity. COMMIT atomically increments the Control Authority Epoch, marks the old ordinary-control binding stale, records the new Current Controller and envelope, and commits a handover receipt. ENABLE permits the new controller to submit ordinary commands under the committed epoch. ACTIVE(A,e) | v PREPARE(B,e+1) --failure--> ACTIVE(A,e) or SAFE | v COMMIT(B,e+1) | +--> all A/e ordinary commands become stale v ENABLE(B,e+1) If the system fails after PREPARE but before COMMIT, the proposed new controller has no effectuation authority. If COMMIT occurred but readiness of the new controller cannot be established, the system enters a bounded Safe-State Set or requires a new handover; it does not resurrect the prior epoch merely because an old controller continues transmitting. 17.5. Control-Handover Workflow 1. Maintain protected per-sink state identifying the Current Controller and Control Authority Epoch. 2. Receive a handover request naming the proposed new controller, governed sink set, act classes, control envelope, duration, authority basis, and reason. 3. Authenticate or attest the proposed controller or remote session and check role, revocation, and freshness. 4. Validate the requested control envelope against current vehicle or aircraft state, operational domain, safety limits, and policy. 5. Enter PREPARE and persist the proposed controller and envelope without granting ordinary effectuation authority. Das Expires 22 March 2027 [Page 59] Internet-Draft UAS/AV Act Finality September 2026 6. Optionally freeze authority expansion by the old controller while preserving bounded continuity and the Safe-State Set. 7. Confirm readiness of the proposed controller and establish fresh proof-of-possession when required. 8. Atomically increment the Control Authority Epoch, invalidate the old ordinary-control binding, install the new Current Controller and envelope, and commit a handover receipt. 9. Only after COMMIT issue or enable the new controller capability. 10. Every governed sink rejects a command whose controller, epoch, sink, act class, envelope, expiry, or freshness state differs from protected authority state. 11. Queued or precomputed commands from prior epochs are rejected unless they are separately reclassified as Safe-State Set actions under current state. 17.6. Control-Handover Pseudocode PROCEDURE HANDOVER_CONTROL(sink_set, old_id, new_id, request): FOR EACH s IN sink_set: REQUIRE AuthorityState[s].current_controller_id == old_id REQUIRE VERIFY_CONTROLLER(new_id, request.authority) REQUIRE NOT_REVOKED(new_id) REQUIRE ENVELOPE_SAFE(request.envelope, CURRENT_CONTEXT()) BEGIN ATOMIC FOR EACH s IN sink_set: AuthorityState[s].handover_state := PREPARED AuthorityState[s].prepared_new_controller_id := new_id AuthorityState[s].prepared_envelope_digest := HASH(request.envelope) END ATOMIC REQUIRE CONTROLLER_READY(new_id, request.fresh_session_proof) BEGIN ATOMIC FOR EACH s IN sink_set: e_new := AuthorityState[s].authority_epoch + 1 AuthorityState[s].authority_epoch := e_new AuthorityState[s].current_controller_id := new_id AuthorityState[s].current_envelope_digest := HASH(request.envelope) AuthorityState[s].handover_state := COMMITTED Das Expires 22 March 2027 [Page 60] Internet-Draft UAS/AV Act Finality September 2026 R := COMMIT_HANDOVER_RECEIPT(sink_set, old_id, new_id, e_new) END ATOMIC ENABLE_CONTROLLER(new_id, sink_set, e_new, HASH(R)) RETURN COMMITTED PROCEDURE ADMIT_CONTROLLER_COMMAND(cmd, sink): S := READ_PROTECTED_AUTHORITY_STATE(sink) IF cmd.controller_id != S.current_controller_id: RETURN SAFE_DENY("STALE_OR_WRONG_CONTROLLER") IF cmd.authority_epoch != S.authority_epoch: RETURN SAFE_DENY("STALE_AUTHORITY_EPOCH") IF cmd.sink_id != sink.id: RETURN SAFE_DENY("SINK_MISMATCH") IF NOT WITHIN_ENVELOPE(cmd, S.current_envelope_digest): RETURN SAFE_DENY("ENVELOPE_MISMATCH") IF NOT FRESH_AND_UNUSED(cmd): RETURN SAFE_DENY("REPLAY_OR_STALE") RETURN ADMIT(cmd) 18. Compact Broadcast Act Evidence for DRIP 18.1. Technical Problem DRIP lets an Observer verify that Broadcast RID messages come from the registered owner of a DET, including when the Observer has no Internet access [RFC9575]. The Observer still cannot verify whether an act it can see was decided by the aircraft's enforcement domain before it became effective. Four constraints make a direct approach impractical: 1. Size. Broadcast RID messages are 25 octets. A per-act public- key signature (64 octets for Ed25519) plus identifiers and timestamps spans several Authentication Message pages. 2. Loss. Legacy transports lack forward error correction; paged Authentication Messages can lose pages, and DRIP FEC recovers only a single lost page [RFC9575]. 3. Rate and cost. Consequential acts and decisions (envelope renewals, sensor toggles, denials) can occur several times per second; public-key signing at that rate is a material computational and energy load for small onboard controllers. Das Expires 22 March 2027 [Page 61] Internet-Draft UAS/AV Act Finality September 2026 4. Origin. The DET key is often held by the RID module or the flight software. Evidence signed with that key shows that the aircraft's software sent it, not that the enforcement domain decided it. A compromised mission computer holding the RID key could broadcast "authorized" evidence for acts the PED never allowed. The mechanism below addresses all four: fixed 16-octet records, loss- tolerant delayed key disclosure, symmetric per-record authentication, and a protected master seed that never leaves the PED. 18.2. Design The design applies the TESLA delayed key disclosure principle [RFC4082] to act-decision records. The default profile uses a distinct PED evidence-signing key; the aircraft's DRIP/HI identity endorses that evidence key once for its validity interval. The mission computer and RID module do not hold the undisclosed evidence- chain keys. At the start of an evidence epoch the PED generates a random master seed K_seed that is never disclosed, derives the terminal chain value K_N from K_seed and epoch_id, and then derives the reverse one-way chain down to K_0. K_seed may be erased after K_N and the chain state are securely established. Time is divided into intervals of length Delta starting at T_0 (GNSS or UTC time). K_0 is a public chain commitment carried in the signed Anchor and is never used directly or through F' as an AER tag key. Records emitted in zero-based interval i are authenticated with K'_i = F'(K_(i+1)). K_(i+1) is broadcast d intervals later. An Observer accepts a record only if it arrived before the key for its interval could have been disclosed, and verifies it once the key arrives. A signed Anchor and Evidence Key Endorsement bind the chain to the PED evidence key and to the UA's DET. generation (inside PED, once per epoch): K_seed --derive with epoch_id--> K_N --F--> ... --F--> K_1 --F--> K_0 K_seed is never disclosed; K_0 is the public chain commitment. use (time runs left to right): interval: | 0 | 1 | 2 | 3 | 4 | 5 | ... records: AER AER AER AER AER AER tagged with: K'_0 K'_1 K'_2 K'_3 K'_4 K'_5 derived from: K_1 K_2 K_3 K_4 K_5 K_6 disclosed: K_1 K_2 K_3 (d = 3) Anchor (signed once, repeated): {DET, PED key id, T_0, Delta, d, N, K_0, ...} A lost disclosure for interval i is recovered from any later interval j: K_(i+1) = F^(j-i)(K_(j+1)) Das Expires 22 March 2027 [Page 62] Internet-Draft UAS/AV Act Finality September 2026 Figure 6: Evidence key chain and delayed disclosure 18.3. Default Endorsement Path The default, and the only path specified as interoperable in this version, is: 1. The PED generates and seals a distinct evidence-key pair. That key never leaves the PED. It is not the DET / Host Identity key. 2. The UA Host Identity key (the key corresponding to the DET) signs an Evidence Key Endorsement binding ua_det, ped_kid, and ped_pub for a validity window. That endorsement is a DRIP-compatible statement of "this PED evidence key speaks for this DET". 3. The PED signs each epoch Anchor with the evidence key. This document does _not_ use "PED holds the DET key" as a default. On typical airframes the DET key is in the RID module or flight software, which is the component whose compromise this mechanism exists to survive. An implementation in which the PED is also the DET key holder is a degenerate case of the same endorsement (self- endorsement) and adds no Observer-visible format. 18.4. Construction F(x) = Trunc_128( SHA-256( "UAS-AFE-chain" || x ) ) F'(x) = Trunc_128( SHA-256( "UAS-AFE-tag" || x ) ) K_seed <- random 128 bits (generated inside PED; never disclosed) K_N = Trunc_128(SHA-256( "UAS-AFE-seed" || K_seed || epoch_id)) K_i = F(K_(i+1)), i = N-1 ... 0 K_0 = public chain commitment in the signed Anchor I_i = [ T_0 + i*Delta , T_0 + (i+1)*Delta ), 0 <= i < N K'_i = F'(K_(i+1)) (tag key for interval i) K_(i+1) is disclosed during I_(i+d) hdr = first 8 octets of the AER (header, below) tag = Trunc_64( HMAC-SHA-256( K'_i, "UAS-AFE-rec" || ua_det || epoch_id || hdr ) ) AER = hdr || tag (16 octets) HMAC is as defined in [RFC2104], SHA-256 as in [RFC6234]. Domain- separation strings prevent the master-seed derivation, chain function, tag-key derivation, and record MAC from being confused with one another or with other protocols. K_seed is not a chain value and Das Expires 22 March 2027 [Page 63] Internet-Draft UAS/AV Act Finality September 2026 is never included in an Anchor, KDR, AER, receipt, or ordinary transmitter state. Chain values K_1 through K_N may become public only according to the disclosure schedule. K_0 is deliberately commitment-only. Because K_0 is public in the Anchor, using F'(K_0) as an interval tag key would make the corresponding interval forgeable by any Observer. The zero-based AER interval i therefore uses K_(i+1), while K_0 remains solely the authenticated chain root. 18.5. Record Formats 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Ver|Knd| Act Class |Dec| SinkC | Interval Index (16 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receipt Counter n (32 bits) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | + Tag (64 bits, truncated HMAC) + | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Ver (2) = 0 Knd (2) = 0 (AER) Act Class (6) = Table 2 code; 0x00 = UNSPECIFIED (privacy mode) Dec (2) = 00 DENY, 01 ALLOW, 10 SAFE_STATE_SELECTED, 11 reserved SinkC (4) = sink class (motor, latch, RF, sensor, mode, RID, ...) Figure 7: Act Evidence Record (AER), 16 octets Octet 0 Octets 1-2 Octets 3-18 +------------------------+--------------------------+------------------+ |Ver(2)|Knd(2)|Rsvd(4) | Interval Index (16 bits) | K_(i+1) (128 b) | +------------------------+--------------------------+------------------+ Header = 24 bits (3 octets); disclosed key = 128 bits (16 octets). Total = 19 octets. Knd = 1 (KDR). Figure 8: Key Disclosure Record (KDR), 19 octets Das Expires 22 March 2027 [Page 64] Internet-Draft UAS/AV Act Finality September 2026 ; Anchor: signed once per epoch by the PED evidence key (COSE_Sign1), ; repeated periodically so late-arriving Observers can verify. afe-anchor = { "ua_det" : bstr .size 16, "epoch_id" : bstr .size 4, "ped_kid" : bstr .size 8, "t0" : uint, ; seconds "delta_ms" : uint, ; interval length "d" : uint, ; disclosure lag in intervals "n_len" : uint, ; chain length N "k0" : bstr .size 16, ; chain commitment K_0 "n_start" : uint, ; first receipt counter in epoch ? "aao_hint": bstr .size 8 ; optional, privacy-dependent } ; Evidence Key Endorsement: binds the distinct PED evidence key to ; the UA DET and is signed by the UA Host Identity / DRIP identity key. afe-endorsement = { "ua_det": bstr .size 16, "ped_kid": bstr .size 8, "ped_pub": bstr, "valid_to": uint } A 16-octet AER and a 19-octet KDR each fit within the data area of a single 25-octet Broadcast RID message before transport framing. The first page of an F3411 Authentication Message carries additional header fields; exact page packing and carriage are left open in this version (see Section 18.10). The Interval Index is an unsigned 16-bit index within one evidence epoch, not a perpetually wrapping global counter. This profile deliberately avoids 16-bit wrap ambiguity rather than attempting to infer a wrapped index: an epoch MUST contain no more than 60000 intervals and a new Anchor and chain MUST begin before index reuse. An Observer MUST reject an AER or KDR whose index is greater than or equal to the Anchor's n_len. T_0, Delta, d, n_len, and the Observer's receive time provide the expected interval; if the received index is not consistent with that expected interval within the configured receive-delay and clock-error allowance, the record is not eligible for real-time verification. An implementation that permits index wrap requires an unambiguous lifting rule and is outside this profile. 18.6. Emission Rules Das Expires 22 March 2027 [Page 65] Internet-Draft UAS/AV Act Finality September 2026 PED ON RECEIPT_COMMITTED(R): # from PED_FINALIZE / DENY IF R.act_class NOT IN evidence_classes: RETURN i := INTERVAL_INDEX(now) # floor((now - T_0) / Delta) hdr := PACK(ver=0, kind=0, class=MAYBE_COARSE(R.act_class), dec=R.decision, sinkc=R.sink_class, idx=i, n=R.counter) K_tag_i := F'(K_(i+1)) # K'_i; derived AER key for interval i tag := TRUNC64(HMAC_SHA256(K_tag_i, "UAS-AFE-rec" || ua_det || epoch_id || hdr)) QUEUE_TO_RID_MODULE(hdr || tag, repeats = r_aer) RECORD_IN_RECEIPT(R, hdr) # receipt n carries same header PED EVERY INTERVAL j >= d: q := j - d # AER interval whose key becomes public QUEUE_TO_RID_MODULE(PACK_KDR(idx = q, key = K_(q+1)), repeats = r_kdr) PED EVERY T_anchor AND AT EPOCH START: QUEUE_TO_RID_MODULE(ANCHOR_SIGNED_ONCE) # same bytes, no re-sign The RID module forwards queued evidence without the ability to compute tags, because it never holds K_(i+1) before disclosure for interval i. Evidence traffic MUST NOT displace messages that regulation requires; it is sent in remaining capacity. Receipt n in the PED's signed receipt chain MUST contain the same 8-octet header, so that broadcast evidence and later-audited receipts can be matched one-to-one. 18.7. Observer Verification Let delta_max be an upper bound on the difference between the Observer clock and the time base used for T_0. An Observer with GNSS-derived time can generally use a tighter delta_max than an Observer relying only on network time. If only NTP, cellular time, or another network-derived clock is available, delta_max MUST conservatively bound that source and its uncertainty; otherwise the Observer MUST NOT claim the real-time pre-disclosure property and may retain the record for later audit only. Das Expires 22 March 2027 [Page 66] Internet-Draft UAS/AV Act Finality September 2026 OBSERVER ON ANCHOR(A, endorsement, drip_evidence): REQUIRE DRIP_VERIFY_DET(A.ua_det, drip_evidence) # RFC 9575 REQUIRE VERIFY(endorsement, HI(A.ua_det)) # PED evidence key <- DET REQUIRE VERIFY_COSE_SIGN1(A, endorsement.ped_pub) REQUIRE A.n_len <= 60000 STORE chain[A.ua_det, A.epoch_id] := { last_key_index: 0, last_K: A.k0, A } OBSERVER ON AER(rec, t_r): # t_r = trusted local receive time a := chain[det, epoch]; IF a IS NONE: BUFFER(rec); RETURN IF NOT CLOCK_ERROR_BOUNDED(delta_max): STORE_FOR_AUDIT_ONLY(rec); RETURN i := UINT16(rec.idx) IF i >= a.n_len: DISCARD(rec, "INDEX_OUT_OF_EPOCH"); RETURN expected := FLOOR((t_r - a.t0) / a.delta) IF NOT INDEX_PLAUSIBLE(i, expected, receive_delay_bound, delta_max): DISCARD(rec, "INDEX_TIME_INCONSISTENT"); RETURN x := FLOOR((t_r + delta_max - a.t0) / a.delta) IF x >= i + a.d: DISCARD(rec, "UNSAFE_LATE") # key may be public PENDING[i].add(rec) # safe; wait for K_(i+1) OBSERVER ON KDR(kd, t_r): a := chain[det, epoch]; IF a IS NONE: BUFFER(kd); RETURN IF NOT CLOCK_ERROR_BOUNDED(delta_max): STORE_FOR_AUDIT_ONLY(kd); RETURN q := UINT16(kd.idx) # AER interval index IF q >= a.n_len: RETURN key_index := q + 1 # disclosed chain key is K_(q+1) IF key_index <= a.last_key_index: RETURN expected_disclosure := FLOOR((t_r - a.t0) / a.delta) - a.d IF NOT INDEX_PLAUSIBLE(q, expected_disclosure, receive_delay_bound, delta_max): DISCARD(kd, "INDEX_TIME_INCONSISTENT"); RETURN IF ITERATE(F, kd.key, key_index - a.last_key_index) != a.last_K: DISCARD(kd); RETURN FOR i FROM a.last_key_index TO q: # recover any lost interval keys K_interval := ITERATE(F, kd.key, q - i) # equals K_(i+1) FOR rec IN PENDING[i]: K_tag_i := F'(K_interval) # equals K'_i IF TRUNC64(HMAC_SHA256(K_tag_i, "UAS-AFE-rec" || det || epoch || rec.hdr)) == rec.tag: MARK_VERIFIED(rec) # PED decided (class, dec, n) in I_i ELSE: MARK_INVALID(rec) a.last_key_index := key_index; a.last_K := kd.key With Delta = 1 s and d = 3, and an Observer clock whose error is bounded by delta_max = 1 s, a record becomes verifiable roughly 3 to 4 seconds after emission. These values are RECOMMENDED starting Das Expires 22 March 2027 [Page 67] Internet-Draft UAS/AV Act Finality September 2026 points, not requirements. If the Observer cannot establish a clock- error bound -- for example, it has only an unsynchronized or untrusted local clock -- it may retain records for later audit but MUST NOT claim the TESLA real-time property that the record arrived before key disclosure. Delayed disclosure authenticates PED origin and pre-disclosure reception; it does not, by itself, prove physical location. A still- safe AER can be relayed to another Observer before disclosure. Correlation with DRIP-authenticated Location/Vector messages from the same interval is therefore a mitigation against location confusion, not a cryptographic proof that the observed physical act occurred at the reported coordinates. The signed receipt chain remains the authoritative detailed audit record. 18.8. What a Verified Record Does and Does Not Establish A verified AER establishes that the holder of the anchored key chain -- the PED endorsed for that DET -- emitted, during interval I_i, decision record n with the stated act class, decision, and sink class. Combined with DRIP-authenticated Location/Vector messages from the same interval, an Observer can associate the decision with where the aircraft was. It does not establish that the physical effect occurred, that every decision was received (broadcast is lossy; counter gaps are visible but are not by themselves evidence of misconduct), or anything about the content of the authority object beyond the optional hint. Full detail is in the signed receipt chain, which an authorized auditor can later obtain and match to broadcast headers by counter n. Broadcast evidence is never authority. A sink, PED, or service MUST NOT accept an AER, KDR, or Anchor as a handle, and a receipt presented as a handle is refused (EF-008). 18.9. Size and Cost Comparison +============+=============+==============+===========+===========+ | Approach | Per-act | Per-act | Loss | Origin | | | octets on | onboard | behaviour | | | | air | operation | | | +============+=============+==============+===========+===========+ | DET-signed | >= 64-octet | One public- | Lost page | Key | | structure | signature | key | may lose | holder of | | per act | plus | signature | the | DET | | | identifiers | | record | (often | | | and | | | RID | | | timestamps; | | | module or | Das Expires 22 March 2027 [Page 68] Internet-Draft UAS/AV Act Finality September 2026 | | multi-page | | | flight | | | on legacy | | | software) | | | transport | | | | +------------+-------------+--------------+-----------+-----------+ | AER with | 16 (plus | One HMAC- | Lost KDR | PED only | | delayed | one | SHA-256 | recovered | | | disclosure | 19-octet | | from any | | | (this | KDR per | | later KDR | | | document) | interval, | | | | | | shared by | | | | | | all | | | | | | records) | | | | +------------+-------------+--------------+-----------+-----------+ Table 5: Per-act evidence cost (indicative) Forgery resistance per record is bounded by the 64-bit tag (success probability about 2^-64 per attempt) and by one-wayness of F. A 64-bit tag is chosen because the record is evidence rather than authority; deployments that need more MAY use a 24-octet AER variant with a 128-bit tag. 18.10. Carriage and Open Issues for DRIP * Carriage. This version intentionally does not request a DRIP Frame Type or Specific Authentication Method allocation. Candidate carriage approaches may require ASTM/ICAO coordination, an applicable future IETF standards effort, or use over Network RID. The byte-level AER/KDR construction is separable from the eventual carriage decision. * Manifest interaction. AERs and KDRs are ordinary payload and can also be covered by a DRIP Manifest; delayed-disclosure verification still adds PED-origin that a Manifest signed with the DET key cannot provide on its own. * Endorsement. The default profile uses a distinct PED evidence key endorsed by the aircraft's DRIP/HI identity. The RID module may relay the Anchor, endorsement, AERs, and KDRs but does not receive undisclosed chain keys. This document does not require the PED to hold the DET private key. * Network RID. The same records can be relayed through Network RID services, where size is less constrained but the PED-origin property is still useful. Das Expires 22 March 2027 [Page 69] Internet-Draft UAS/AV Act Finality September 2026 19. Onboard Bus Considerations Where the sink is reached over a bus, the enablement condition SHOULD be a physical line or gated rail controlled directly by the PED (for example ESC enable, latch solenoid supply, PA enable), because a gated condition is not bypassed by a forged bus frame. Where a sink can only be reached by bus messages (for example ESCs on CAN or DroneCAN, where classic CAN frames carry 8 data octets and CAN FD frames up to 64), the PED MAY establish a per-arming session key with the sink and send envelope releases carrying a freshness counter and a truncated MAC. That arrangement authenticates the release but places part of enforcement in the sink's firmware; it is a mitigation-class profile unless the sink's firmware is itself within the attested PED boundary. This profile does not assume that current off-the-shelf or consumer ESC firmware is a PED; such a sink qualifies for the stronger profile only when its relevant firmware, key state, and bypass resistance are within the attested enforcement boundary. 20. Relevance to IETF and IRTF Work This document crosses several existing protocol and security work areas, but it does not assert that any one Working Group or Research Group owns the complete execution-finality problem. The mappings below identify reusable IETF/IRTF mechanisms and review communities. They are not statements of adoption, charter expansion, or venue assignment. 20.1. Why This Is an Internet-Protocol Boundary Problem The mechanisms in this document do not standardize aircraft aerodynamics, steering geometry, braking control, ESC control laws, or collision-avoidance algorithms. Those remain functions of avionics, vehicle-control, autonomy, and safety systems. The Internet-facing problem arises because identity, authority, attestation, revocation, freshness, remote-assistance instructions, responder credentials, UTM/U-space state, V2X or air-to-air coordination, and audit evidence can originate across network and administrative boundaries, while the consequence occurs later at a local physical sink. The protocol question is how that network- originated state remains cryptographically and semantically bound to the exact act that is about to become effective. Das Expires 22 March 2027 [Page 70] Internet-Draft UAS/AV Act Finality September 2026 Internet / administrative side Physical system side +----------------------------+ +-----------------------+ | identity / DET / PKI | | perception / planner | | attestation / Evidence | | DAA / ADS / autopilot | | UTM, U-space, V2X state | +-----------+-----------+ | responder / operator auth | | | revocation / policy state | | Candidate Act +-------------+--------------+ v | +-----------------------+ | authenticated / | Protected Enforcement | | integrity-protected | Domain | | protocol objects | - current authority | +-------------------------------> | - epochs / freshness | | - exact-act binding | | - receipt state | +-----------+-----------+ | scoped release only v +-----------------------+ | Finality Sink | | motor / steering / | | brake / latch / RF / | | motion admission | +-----------------------+ | v physical effect Figure 9: Internet-originated authority carried to a physical finality boundary The architectural boundary is therefore between a network/control- plane assertion and local effectuation. Authentication of the upstream message is necessary but not sufficient: the sink must determine whether that assertion is still current, applies to this device and sink, and still describes the actual impending act. This is the same separation expressed throughout this document as computation or communication not being, by itself, release authority. 20.2. Mapping of the Three Extended Embodiments Conflict-Set-Bound DAA Finality (Section 15): The Internet-relevant state includes authenticated aircraft identity, cooperative traffic reports, remote or network DAA inputs, freshness, attestation of the protected DAA/finality component, and evidence of the resolution that was admitted. DRIP/tm-rid is relevant to Das Expires 22 March 2027 [Page 71] Internet-Draft UAS/AV Act Finality September 2026 aircraft identity and Observer association; RATS is relevant where a relying party needs Evidence or Attestation Results about the protected component and its reference state; COSE/CBOR is relevant to compact deterministic representation and authentication of Conflict-Set Commitments, Resolution Objects, and receipts; ACE patterns are relevant where constrained sinks consume narrowly scoped authorization; SCITT-style transparency may be useful for later registration or audit of resolution receipts; and T2TRG is relevant to constrained, multi-source, stateful enforcement. None of these mappings asks DRIP or another IETF group to standardize the collision-avoidance algorithm itself. Emergency-Scene Temporary Authority Finality (Section 16): The Internet-relevant problem is the transport and interpretation of a temporary responder authority across organizations while preventing a valid credential from becoming general remote-driving authority. COSE/CBOR is relevant to compact signed or MAC- protected Emergency Scene Authority Capsules; RATS is relevant where responder-side or vehicle-side protected state must be attested; ACE concepts are relevant to narrowly scoped, time- bounded authority for a constrained motion-admission sink; SCITT- style receipts can support post-event accountability without participating in the live driving decision; and T2TRG is relevant to constrained devices with multiple legitimate masters or stakeholders. Where UAS public-safety operations use the same construction, DRIP identity and tm-rid Observer mechanisms can associate temporary authority and later evidence with a particular aircraft. Atomic Control-Authority Handover (Section 17): The Internet- relevant problem is not controller scheduling but transfer of effect authority between independently authenticated controllers across delayed, duplicated, failed, or recovered sessions. ACE is relevant to constrained authorization and scope; RATS is relevant to attestation of Current Controller, Control Authority Epoch, and protected handover state; COSE/CBOR is relevant to Handover Objects, epoch-bound actuation objects, and receipts; SCITT-style transparency can record completed authority transfers; and T2TRG is directly relevant to constrained Things with multiple masters or stakeholders. For UAS, DRIP/tm-rid can provide the aircraft identity and Observer context but does not itself determine which controller currently owns an actuator sink. 20.3. Group-by-Group Relevance DRIP Working Group / tm-rid community: DRIP supplies a trustworthy Das Expires 22 March 2027 [Page 72] Internet-Draft UAS/AV Act Finality September 2026 aircraft identity and Broadcast/Network RID context. This document can bind Compact Broadcast Act Evidence, DAA-resolution evidence, selected temporary-authority evidence, and handover evidence to a DET without changing the principle that DRIP identifies and authenticates rather than decides physical actuation. Possible future work, if the community finds it useful, includes compact carriage, Observer verification, and correlation rules. RATS: RATS is relevant where an authority issuer or relying party needs confidence that the PED, Finality Sink path, safe-state implementation, DAA finality logic, scene-corroboration logic, or handover state is running in an expected protected configuration. Candidate attested state includes PED measurements, reference values, bypass-resistance claims, Current Controller, Control Authority Epoch, current policy/revocation generations, and the protected components that calculate or verify Conflict-Set Roots. This document does not define new RATS Evidence or Attestation Result claims; such claims would require separate profiling and review. COSE and CBOR: Deterministic CBOR and COSE are directly relevant to AAOs, Execution Handles, BPCs, Finality Receipts, evidence anchors, DAA Resolution Objects, Conflict-Set Commitments, Emergency Scene Authority Capsules, Control Handover Objects, and epoch-bound actuation objects. Compact canonical representation is important because semantic binding fails if producer and verifier hash different encodings of the same logical object. ACE: ACE is relevant to constrained authorization patterns where a protected resource server or actuator-side verifier must accept only narrowly scoped, time-bounded authority. The DAA, emergency- scene, and handover embodiments add a further local condition: authenticated authorization is not released to the physical sink until the exact impending act, current epoch, freshness, and local context also match. This document therefore treats ACE-style authorization as a potential input to finality rather than as proof that actuation has already been authorized at the physical boundary. SCITT: SCITT-style transparency services are relevant to publication or later audit of AAO issuance, Finality Receipts, DAA Resolution Receipts, Emergency Scene Authority issuance, and committed controller handovers. Transparency evidence is deliberately outside the live effectuation path: registration, receipt, or inclusion in a transparency service does not itself create execution authority. Das Expires 22 March 2027 [Page 73] Internet-Draft UAS/AV Act Finality September 2026 T2TRG (IRTF): T2TRG is relevant to constrained-device security, state/event semantics, intermittent connectivity, devices with multiple legitimate masters, bounded local enforcement, and reference/evaluation environments. The three extended embodiments provide concrete cross-domain cases: a UAS with multiple traffic information sources, a vehicle temporarily directed by an external responder, and a device transferring effect authority between autonomy, remote assistance, and safe-state controllers. 21. Security Considerations +===========+=============+===========================+=============+ |Threat |Effect |Mitigation |Residual | | |without this | | | | |profile | | | +===========+=============+===========================+=============+ |Compromised|Unauthorized |No path to enablement |eps_path if a| |mission |motion, |conditions except via PED |bypass exists| |computer |release, |(path completeness) |in hardware | |writes |sensing | |design | |actuators | | | | +-----------+-------------+---------------------------+-------------+ |Stolen or |Repeat of an |Non-bearer, act- and sink- |eps_store | |replayed |authorized |bound, atomic consume | | |handle |act | | | +-----------+-------------+---------------------------+-------------+ |Stale |Entry into |Generation read inside |T_off_max | |authority |restricted |consume; event-triggered |when offline | |after |volume |revalidation; offline bound| | |restriction| | | | +-----------+-------------+---------------------------+-------------+ |GNSS |False |Multi-source consistency; |eps_ctx if | |spoofing |containment |disagreement removes |all sources | | | |authority |falsified | | | | |consistently | +-----------+-------------+---------------------------+-------------+ |Coerced but|Unsafe act by|Command treated as |Colluding | |validly |authenticated|Candidate Act; quorum for |quorum | |signed |source |marked classes | | |command | | | | +-----------+-------------+---------------------------+-------------+ |Partial |Separation |Composite decision log; |Liveness when| |coordinated|loss |prepare never moves; HOLD |log | |act | | |unreachable | +-----------+-------------+---------------------------+-------------+ |Stale DAA |An avoidance |Conflict-Set Root, current-|Depends on | |conflict |maneuver can |set revalidation, multi- |integrity, | |basis or |become unsafe|intruder check, and |freshness, | Das Expires 22 March 2027 [Page 74] Internet-Draft UAS/AV Act Finality September 2026 |superseded |before motion|monotonic Resolution Epoch |and | |resolution |admission | |completeness | | | | |of the | | | | |protected | | | | |traffic | | | | |inputs | +-----------+-------------+---------------------------+-------------+ |Replayed or|A temporary |Incident/scene/vehicle/act/|Residual risk| |over-broad |traffic-rule |sink binding, independent |if all | |emergency- |exception can|local scene corroboration, |required | |scene |be reused for|explicit exception class, |local scene | |authority |another |nonce, expiry, and |evidence is | | |vehicle, |automatic authority |consistently | | |scene, |extinction |falsified | | |incident, | | | | |path, or time| | | +-----------+-------------+---------------------------+-------------+ |Split-brain|Two valid |Protected Current |Availability | |controller |controllers |Controller state, monotonic|can fall back| |handover |can issue |Control Authority Epoch, |to the Safe- | | |conflicting |transactional |State Set | | |ordinary |PREPARE/COMMIT/ENABLE, and |during | | |actuation |stale-epoch rejection at |incomplete | | |commands |the sink |handover or | | | | |recovery | +-----------+-------------+---------------------------+-------------+ |Truncated |Wrong act or |Keyed binding preferred; |Deployment- | |BPC |authority |explicit collision and |selected t | |commitment |could appear |attacker-work sizing; |and online- | |collides or|to match a |ambiguity causes deny or |attempt | |is searched|short value |longer proof |budget | |offline | | | | +-----------+-------------+---------------------------+-------------+ |Mixed, |Partial proof|Per-fragment |Availability | |missing, or|could be |authentication, common |loss under | |corrupted |mistaken for |SessionID and Root, ordered|packet loss | |BPC |authority |reconstruction, root |or jamming | |fragments | |verification; incomplete | | | | |evidence means no | | | | |effectuation | | +-----------+-------------+---------------------------+-------------+ |Unknown or |Reference |Protected keyed reference, |Resolver/ | |stale |substitution |authenticated cache/ |cache | |compact |or stale |resolver, current |availability | |Authority |cached |generation checks at | | |Reference |authority |finality; UNKNOWN never | | | | |means authorized | | +-----------+-------------+---------------------------+-------------+ Das Expires 22 March 2027 [Page 75] Internet-Draft UAS/AV Act Finality September 2026 |Forged |False |Key chain seed sealed in |2^-64 per | |broadcast |appearance of|PED; tag keys disclosed |record; | |evidence by|authorized |only after safety window |Observer | |RID module |conduct | |clock outside| |or third | | |delta_max | |transmitter| | | | +-----------+-------------+---------------------------+-------------+ |Late replay|Old or remote|Interval index bound in |A relay | |or relay of|decision |tag; pre-disclosure |inside the | |evidence |presented as |receive-time condition; |disclosure | | |locally |correlate with DRIP- |window | | |current |authenticated Location/ |remains | | | |Vector from the same |possible; if | | | |interval |location | | | | |evidence is | | | | |also forged | | | | |or | | | | |unavailable, | | | | |act-evidence | | | | |verification | | | | |alone does | | | | |not prove | | | | |local | | | | |physical | | | | |presence | +-----------+-------------+---------------------------+-------------+ |Receipt |Authority |Refused (EF-008) |None expected| |presented |laundering | | | |as handle | | | | +-----------+-------------+---------------------------+-------------+ |Denial of |Observer sees|None at the broadcast |Loss of real-| |evidence |nothing |layer; receipts remain for |time | |broadcast | |audit |observability| |(jamming) | | | | +-----------+-------------+---------------------------+-------------+ Table 6: Threats and mitigations A PED that is itself compromised defeats this profile; its isolation, non-extractable keys, and attested measurement are therefore load- bearing assumptions. Denial and safe-state selection are designed so that the failure mode of the enforcement layer is a controlled holding, descent, or landing manoeuvre, never uncontrolled flight. Das Expires 22 March 2027 [Page 76] Internet-Draft UAS/AV Act Finality September 2026 22. Privacy Considerations Broadcast act class values can reveal operational details (for example that a camera is active). Deployments MAY use the UNSPECIFIED act class (privacy mode), broadcasting only decision, sink class, counter, and tag, with full detail confined to receipts available to authorized auditors. The optional AAO hint SHOULD NOT be broadcast where it would link flights to customers. Receipts SHOULD omit imagery, customer identity, and raw sensor data, carrying digests instead. Whether and how act evidence is broadcast is subject to regional regulation; this document does not assume a mandate. The DAA profile can involve sensitive traffic tracks and the emergency-scene profile can involve responder, incident, and scene information. Implementations SHOULD keep raw track sets, responder identities, and detailed scene observations inside protected local state where possible, carrying commitments, pseudonymous references, coarse classes, or auditor-only receipt fields instead. Control- handover receipts SHOULD avoid exposing operator identity beyond what is necessary to prove the authority transition. 23. IANA Considerations This document has no IANA actions. It does not request a DRIP Frame Type, a Specific Authentication Method value, or an IANA act/sink registry. If the compact evidence mechanism progresses in a future standards effort, carriage and registry work would require the process appropriate to the selected transport, including coordination with ASTM/ICAO where applicable. 24. Reference Implementation, Red-Team Harness, and Reproducibility An accompanying non-normative reference repository, UAS-Autonomous- Vehicle-Execution-Finality-Reference, instantiates the principal state machines, cryptographic bindings, and negative-control cases in this document. The repository is intended to make the architectural claims falsifiable and reproducible rather than to serve as production flight, vehicle, or actuator software. It is not a normative dependency of this specification. Das Expires 22 March 2027 [Page 77] Internet-Draft UAS/AV Act Finality September 2026 The public repository is available at [GITHUB-EF-REF]. Related public background records by the author are [DAS-ZENODO], which describes the broader execution-finality authority problem; [DAS-ZENODO-HW], which provides hardware-enforcement context; and [DAS-ZENODO-PURPOSE], which discusses purpose-bound execution finality in another application domain. These resources are informative only and are not normative dependencies of this UAS/AV profile. The current packaged snapshot contains 68 files. Its principal contents are: * reference Python modules for Candidate-Act/finality processing, BPC binding and authentication, replay and receipt state, authenticated fragmentation, corrected AER/KDR delayed-disclosure processing, DAA conflict-set finality, emergency-scene temporary authority, control-authority handover, and spatial revalidation; * explicit configuration files for cryptographic field sizes, collision and attacker-work budgets, AER disclosure timing and packet loss, UAS and road-vehicle parameters, DAA variables, and constrained-compute profiles; * positive and adversarial tests covering act substitution, sink substitution, replay, policy/revocation races, receipt-store failure, concurrent single-use consumption, fragment deletion/corruption/cross-session mixing, delayed-disclosure forgery and late-record cases, stale DAA conflict sets, superseded Resolution Epochs, correlated emergency-scene evidence, and control-handover crash states; * deterministic BPC, AER/KDR, and fragmentation test vectors, together with a seeded randomized red-team campaign so a failing schedule can be replayed; * threat-model, architecture, system-variable, test-matrix, fault- injection, benchmark, security, and IPR documentation; and * a CI configuration and a local benchmark harness that report the execution environment together with measured software-path latency. Das Expires 22 March 2027 [Page 78] Internet-Draft UAS/AV Act Finality September 2026 24.1. How the Reference Harness Was Produced The reference harness was produced by translating the equations, state transitions, object bindings, and pseudocode in this document into a small, deterministic software model. The implementation uses Python and, for the packaged cryptographic paths, standard-library SHA-256, HMAC-SHA-256, and a minimal HKDF construction. Test cases were then derived from the stated invariants and from explicit adversarial mutations: each load-bearing field or state transition is changed, replayed, reordered, made stale, made unavailable, or subjected to a modeled crash point, and the expected outcome is checked before any simulated capability release. The red-team methodology therefore follows the traceability pattern architectural invariant -> adversarial mutation -> expected protected failure -> automated test. For control-authority handover, the packaged campaign additionally executes seeded randomized crash schedules and checks the invariant that no modeled state gives two ordinary controllers simultaneous effectuation authority over the same governed sink. The code was written as a clean-room reference model of the mechanisms described in this document. It was not extracted from, reverse engineered from, or validated against any proprietary OEM flight controller, autonomous-driving stack, vehicle ECU, secure element, actuator controller, or named industrial platform. 24.2. Current Packaged Test Status In the packaged snapshot used while preparing this revision, the automated suite reports 66 passing tests. A seeded control-handover red-team campaign using seed 20260918 executed 5,000 modeled schedules and reported zero dual-authority violations. These numbers describe that particular repository snapshot and software model; they are not conformance certification and may change as the harness and test set evolve. The repository also records local Python benchmark measurements for BPC generation, finality verification/consume/receipt/capability processing, AER generation, and fragmentation/reassembly. Those measurements are environment specific and are reported together with the machine and interpreter details. They exclude network delay, secure-element or HSM access, durable storage fsync, certified real- time scheduling, bus arbitration, and physical actuator I/O. Das Expires 22 March 2027 [Page 79] Internet-Draft UAS/AV Act Finality September 2026 24.3. Interpretation and Limitations Passing the reference harness demonstrates only that the included software state machine and cryptographic bindings satisfy the tested properties under the modeled inputs and adversary. It supports reproducibility and engineering plausibility of those software-level mechanisms; it does not establish physical non-bypassability, airworthiness, automotive functional safety, real-time deadline compliance, RF interoperability, secure-element extraction resistance, resistance to all correlated sensor failures, or production readiness. In particular, a real platform must separately demonstrate that no actuator, DMA, debug, maintenance, alternate bus-master, emergency, firmware-rollback, or failover path can create the protected effect without traversing the applicable Finality Sink. Hardware testing should additionally inject reset, brownout, torn-write, persistent- state rollback, HSM/secure-element timeout, bus and DMA bypass attempts, clock rollback, packet burst loss, controller partition, and actuator-acknowledgement failures at each protected transition. The repository does not substitute for system hazard analysis, flight testing, airworthiness approval, automotive safety engineering, cybersecurity certification, standards conformance, or regulatory approval. It also does not demonstrate that any named industrial platform implements this architecture. Results from the pure- software harness should therefore be described as reference- implementation evidence, not as production-platform validation. 25. Assumptions, Limitations, and Invitation for Review * The numerical example in Section 9.2 is illustrative and is not an airworthiness or certification formula. Real stopping behavior depends on airframe, wind, mass, rotor/propulsion lag, control law, and actuator delay; a_brk and tau must therefore be conservative guaranteed values from protected or attested safety configuration, or a more conservative deployment-specific model must be substituted. * The compact BPC sizing expressions are engineering security-budget inputs, not a complete cyber-physical safety probability. Deployments must choose q, W, A_online, epsilon_c, epsilon_s, epsilon_f, commitment length t, and tag length m for the relevant act rate, session lifetime, fleet scale, and risk class; high- consequence acts should use longer values or a full-proof profile where the budget cannot be justified. Das Expires 22 March 2027 [Page 80] Internet-Draft UAS/AV Act Finality September 2026 * The evidence mechanism assumes a bounded Observer clock offset. An Observer that cannot establish delta_max, including one relying only on an untrusted or unsynchronized local clock, may retain records for later audit but cannot assert the delayed-disclosure real-time safety property. * No flight-test, actuator, secure-element, or production-hardware results are claimed. Any measurements reported by the accompanying reference repository are local software-harness measurements on the stated environment and exclude network, durable-storage, certified real-time scheduling, secure-element/ HSM, bus, and physical-actuator latency. * F3411 page layouts and DRIP carriage details are to be confirmed against the editions in use; this version intentionally leaves carriage open. * Known unsolved items: guaranteed delivery of generations to aircraft in radio-shadowed areas; standardized derivation of sensor footprints for P_sensor; and evidence semantics for acts decided by the flight controller's internal safety logic without PED involvement. The author's understanding of DRIP, F3411, and airframe practice may contain inaccuracies. Critical technical review, especially from DRIP participants and autopilot developers, is invited. 26. References 26.1. Normative References [RFC2104] Krawczyk, H., Bellare, M., and R. Canetti, "HMAC: Keyed- Hashing for Message Authentication", RFC 2104, February 1997, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, . [RFC6234] Eastlake 3rd, D. and T. Hansen, "US Secure Hash Algorithms (SHA and SHA-based HMAC and HKDF)", RFC 6234, May 2011, . [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, May 2017, . Das Expires 22 March 2027 [Page 81] Internet-Draft UAS/AV Act Finality September 2026 [RFC8949] Bormann, C. and P. Hoffman, "Concise Binary Object Representation (CBOR)", STD 94, RFC 8949, December 2020, . [RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, August 2022, . [RFC9153] Card, S., Ed., Wiethuechter, A., Moskowitz, R., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Requirements and Terminology", RFC 9153, February 2022, . [RFC9374] Moskowitz, R., Card, S., Wiethuechter, A., and A. Gurtov, "DRIP Entity Tag (DET) for Unmanned Aircraft System Remote ID (UAS RID)", RFC 9374, March 2023, . [RFC9575] Wiethuechter, A., Ed., Card, S., and R. Moskowitz, "DRIP Entity Tag (DET) Authentication Formats and Protocols for Broadcast Remote Identification (RID)", RFC 9575, June 2024, . 26.2. Informative References [BOEING-AUTONOMY] Boeing, "Autonomous and Unmanned Systems", 2026, . [BYD-DIPILOT] BYD, "BYD Reveals DiPilot Advanced Intelligent Driving Assistance System", February 2025, . [DAS-ACTUATION] Das, S., "Command Accepted Is Not Actuation Authorized: Execution Finality for Cyber-Physical and Industrial Control Systems", Work in Progress, Internet-Draft, draft- das-actuation-bound-execution-finality, 2026, . Das Expires 22 March 2027 [Page 82] Internet-Draft UAS/AV Act Finality September 2026 [DAS-COMPOSITE] Das, S., "Partial Commit Is Not Finality: Composite Execution Finality", Work in Progress, Internet-Draft, draft-das-composite-execution-finality, 2026, . [DAS-HANDLE] Das, S., "Possession Is Not Authority: Execution Handles", Work in Progress, Internet-Draft, draft-das-execution- handle, 2026, . [DAS-JURISDICTION] Das, S., "Authorized Here, Not Authorized There: Jurisdiction-Bound Execution Finality for Cross-Border and Sovereign Systems", Work in Progress, Internet-Draft, draft-das-jurisdiction-bound-execution-finality, 2026, . [DAS-PATH] Das, S., "When the Gate Can Be Bypassed: Consequence-Path Completeness for Execution Finality", Work in Progress, Internet-Draft, draft-das-consequence-path-completeness, 2026, . [DAS-PROTOCOL] Das, S., "Execution Finality Protocol Layer", Work in Progress, Internet-Draft, draft-das-execution-finality- protocol-layer, 2026, . [DAS-REG] Das, S., "Illustrative Codes Are Not a Namespace: Execution-Finality Registries", Work in Progress, Internet-Draft, draft-das-ef-registries, 2026, . [DAS-REVOCATION] Das, S., "Revoked but Still Executable: Closing the Authorization-to-Effect Gap with Finality-Bound Revocation", Work in Progress, Internet-Draft, draft-das- finality-bound-revocation, 2026, . Das Expires 22 March 2027 [Page 83] Internet-Draft UAS/AV Act Finality September 2026 [DAS-STATE] Das, S., "When Valid Authorization Becomes Stale: State and Policy Continuity at the Execution-Finality Boundary", Work in Progress, Internet-Draft, draft-das-state-policy- continuity-finality, 2026, . [DAS-ZENODO] Das, S., "The Internet Solved Communication. It Never Solved Authority", DOI 10.5281/zenodo.22082995, 2026, . [DAS-ZENODO-HW] Das, S., "Hardware-Enforced Execution Finality", Zenodo Record 22308384, 2026, . [DAS-ZENODO-PURPOSE] Das, S., "Declared Purpose Is Not Authorization: Purpose Execution Finality", Zenodo Record 22719527, 2026, . [DJI-AUTOMATION] DJI Enterprise, "Drone Flight Control for DJI - Enterprise Ecosystem Solution Catalogue", 2026, . [F3411] ASTM International, "Standard Specification for Remote ID and Tracking (F3411-22a)", 2022, . [F3548] ASTM International, "Standard Specification for UAS Traffic Management (UTM) UAS Service Supplier (USS) Interoperability (F3548-21)", 2021, . [GITHUB-EF-REF] Das, S., "UAS-Autonomous-Vehicle-Execution-Finality: Reference Implementation and Red-Team Harness", September 2026, . [LOCKHEED-AUTONOMY] Lockheed Martin, "Autonomous and Uncrewed Systems", 2026, . Das Expires 22 March 2027 [Page 84] Internet-Draft UAS/AV Act Finality September 2026 [RFC4082] Perrig, A., Song, D., Canetti, R., Tygar, J. D., and B. Briscoe, "Timed Efficient Stream Loss-Tolerant Authentication (TESLA): Multicast Source Authentication Transform Introduction", RFC 4082, June 2005, . [RFC8610] Birkholz, H., Vigano, C., and C. Bormann, "Concise Data Definition Language (CDDL): A Notational Convention to Express Concise Binary Object Representation (CBOR) and JSON Data Structures", RFC 8610, June 2019, . [RFC8785] Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, June 2020, . [RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and W. Pan, "Remote ATtestation procedureS (RATS) Architecture", RFC 9334, January 2023, . [RFC9434] Card, S., Wiethuechter, A., Moskowitz, R., Zhao, S., Ed., and A. Gurtov, "Drone Remote Identification Protocol (DRIP) Architecture", RFC 9434, July 2023, . [RFC9886] Wiethuechter, A., Ed. and J. Reid, "DRIP Entity Tags (DETs) in the Domain Name System", RFC 9886, December 2025, . [TESLA-AUTOPILOT] Tesla, "Autopilot and Full Self-Driving Capability", 2026, . Appendix A. Appendix: Industrial Deployment Context and Complementarity This non-normative appendix gives industrial deployment context only. The descriptions are based on publicly available material and are intended to explain where an execution-finality boundary could sit relative to existing products and architectures. No implementation from any named organization was used, simulated, reverse engineered, or tested in preparing this document, and no affiliation, endorsement, adoption, infringement conclusion, or claim of technical deficiency is stated or implied. Corrections from the organizations concerned are welcome. Das Expires 22 March 2027 [Page 85] Internet-Draft UAS/AV Act Finality September 2026 The complementarity rule is deliberately narrow: existing perception, planning, localization, DAA, ADAS, geofencing, flight-control, braking, steering, remote assistance, authenticated messaging, and fail-safe logic continue to perform their present functions. This profile does not replace them. Instead, those components produce or support a Candidate Act. A protected execution-finality component then verifies the concrete act actually pending at the motion- admission or actuator boundary against current authority, freshness, policy, revocation, context, conflict set, scene, or control- authority state before releasing only the bounded enablement required for that act. Existing product / autonomy stack Added finality boundary +-------------------------------------+ +-----------------------+ | perception | planning | DAA / ADAS | Candidate | protected current | | geofence | remote assistance | C2 |---- Act ---->| state + act binding | | stabilization / minimal-risk logic | | + receipt + consume | +-------------------+-----------------+ +-----------+-----------+ | | | existing safe-state path | bounded release v v +-------------+ +-------------+ | safe control| | motion / | | remains | | actuator sink| +-------------+ +-------------+ The finality layer does not replace perception, planning, stabilization, braking, steering, DAA, ADAS, or vendor safety logic. Figure 10: Complementary placement relative to an existing autonomy stack +=====================+=====================+=======================+ | Ecosystem | Publicly described | Complementary role | | | role | of this profile | +=====================+=====================+=======================+ | Tesla | Camera- and AI- | The existing | | [TESLA-AUTOPILOT] | based driver | perception and | | | assistance, | driving-assistance | | | including Autopilot | stack can continue | | | and Full Self- | to compute a | | | Driving | trajectory or | | | (Supervised); Tesla | manoeuvre. A | | | states that | protected motion- | | | currently enabled | admission sink can, | | | features require | as an additional | | | active driver | layer, bind the | | | supervision and do | concrete pending | Das Expires 22 March 2027 [Page 86] Internet-Draft UAS/AV Act Finality September 2026 | | not make the | manoeuvre to | | | vehicle autonomous. | current authority, | | | | scene, control- | | | | authority epoch, | | | | freshness, and | | | | safety state before | | | | admitting a bounded | | | | steering, braking, | | | | propulsion, or mode | | | | transition. This | | | | profile does not | | | | replace Tesla's | | | | driver-monitoring, | | | | planning, braking, | | | | steering, or safety | | | | logic. | +---------------------+---------------------+-----------------------+ | BYD [BYD-DIPILOT] | DiPilot | The vehicle's | | | intelligent-driving | existing sensor | | | assistance and | fusion, | | | vehicle-domain | intelligent-driving | | | architectures | planner, AEB, lane- | | | integrating | control, and | | | sensing, decision, | motion-control | | | and control | functions remain | | | functions. | unchanged. | | | | Execution finality | | | | can be placed after | | | | planning and before | | | | motion admission so | | | | that a remotely | | | | approved path, | | | | emergency-scene | | | | exception, | | | | cooperative | | | | manoeuvre, or | | | | controller handover | | | | is effective only | | | | when its act, | | | | scene, vehicle, | | | | epoch, and sink | | | | bindings still | | | | match current | | | | protected state. | +---------------------+---------------------+-----------------------+ | DJI Enterprise | Enterprise drone | Mission automation | | [DJI-AUTOMATION] | mission planning | can continue to | | | and flight | generate waypoints, | Das Expires 22 March 2027 [Page 87] Internet-Draft UAS/AV Act Finality September 2026 | | automation across | camera requests, | | | waypoints, | payload operations, | | | inspection | and flight plans. | | | missions, cameras, | The PED can sit | | | and multiple | below the mission- | | | aircraft. | planning layer and | | | | gate only the final | | | | arming, envelope | | | | expansion, payload, | | | | sensor, RF, or | | | | other consequential | | | | enablement after | | | | reconstructing the | | | | actual impending | | | | act. Existing | | | | flight-controller | | | | stabilization and | | | | failsafes remain | | | | available as the | | | | Safe-State Set. | +---------------------+---------------------+-----------------------+ | Boeing autonomous | Publicly described | For civil or dual- | | and uncrewed | autonomous and | use architectural | | systems | uncrewed aircraft, | discussion only, | | [BOEING-AUTONOMY] | collaborative | conflict-set-bound | | | systems, secure | DAA finality can | | | communications, and | sit downstream of a | | | human-operated AI/ | DAA or autonomy | | | autonomy | planner so that an | | | architectures. | accepted avoidance | | | | resolution remains | | | | bound to the | | | | conflict-set basis | | | | on which it was | | | | computed. Control- | | | | authority handover | | | | finality can | | | | additionally ensure | | | | that only the | | | | controller named by | | | | the current | | | | protected authority | | | | epoch can admit | | | | motion. Existing | | | | flight-control, | | | | safety, and mission | | | | systems remain | | | | primary. | Das Expires 22 March 2027 [Page 88] Internet-Draft UAS/AV Act Finality September 2026 +---------------------+---------------------+-----------------------+ | Lockheed Martin / | Publicly described | The profile can | | Sikorsky autonomy | autonomous and | complement such | | [LOCKHEED-AUTONOMY] | uncrewed systems, | autonomy patterns | | | human-machine | by treating planner | | | teaming, autonomous | or operator output | | | mission execution, | as a Candidate Act | | | and Sikorsky MATRIX | rather than final | | | autonomy. | authority. DAA | | | | conflict-set | | | | revalidation, | | | | monotonic control- | | | | authority epochs, | | | | and sink-local | | | | verification can be | | | | added at the final | | | | motion or actuator | | | | boundary while | | | | leaving perception, | | | | mission planning, | | | | vehicle | | | | stabilization, and | | | | certified safety | | | | functions intact. | | | | This document's | | | | scope remains civil | | | | and excludes | | | | weapon, targeting, | | | | and counter-UAS | | | | effectuation. | +---------------------+---------------------+-----------------------+ | PX4 and ArduPilot | Flight control, | PED gates arming, | | (open-source | geofence, mission, | envelope, payload, | | autopilots) | and failsafe logic. | sensor, and RF | | | | enablement beneath | | | | the autopilot; | | | | autopilot failsafes | | | | remain a Safe-State | | | | implementation | | | | rather than being | | | | displaced by the | | | | finality layer. | +---------------------+---------------------+-----------------------+ | Wing, Amazon Prime | Automated delivery | Payload release can | | Air, Zipline | operations using | be represented as a | | | route planning, | single-use, drop- | | | fleet operations, | zone-bound | | | airspace services, | Candidate Act whose | Das Expires 22 March 2027 [Page 89] Internet-Draft UAS/AV Act Finality September 2026 | | and payload | concrete latch or | | | delivery | winch operation is | | | mechanisms. | reconstructed and | | | | verified at the | | | | payload sink before | | | | release, with | | | | optional receipt | | | | and observer | | | | evidence. | +---------------------+---------------------+-----------------------+ | NVIDIA Jetson-class | High-performance | Accelerator output | | and Qualcomm | onboard AI, | remains | | robotics/vehicle | perception, | computational input | | compute | connectivity, and | to a Candidate Act. | | | planning compute | A smaller protected | | | used in robotics, | controller or | | | vehicles, and edge | safety domain can | | | systems. | hold final | | | | authority state and | | | | release the | | | | actuator or motion- | | | | admission | | | | capability only | | | | after independent | | | | verification. | +---------------------+---------------------+-----------------------+ | USS/USSP providers | Flight | These services can | | under ASTM F3548 | authorization, | remain upstream | | and U-space | conformance | issuers of | | | monitoring, geo- | authority and | | | awareness, and | current-generation | | | operational | information. The | | | information | aircraft PED | | | exchange. | consumes that | | | | information at | | | | effectuation time, | | | | and optional | | | | receipts or | | | | evidence can be | | | | returned to | | | | authorized | | | | operators or | | | | auditors. | +---------------------+---------------------+-----------------------+ Table 7: Illustrative industrial ecosystems and complementary role Das Expires 22 March 2027 [Page 90] Internet-Draft UAS/AV Act Finality September 2026 The same complementarity principle applies to the three narrower embodiments in this document. For DAA finality, the DAA engine continues to detect and resolve conflicts; the new step is revalidation that the accepted manoeuvre is still bound to the current conflict set at motion admission. For emergency-scene authority, the vehicle's normal ADAS/autonomy and minimal-risk functions remain active; the new step is a temporary, scene- corroborated, vehicle- and act-bound exception that extinguishes automatically. For control-authority handover, existing controllers continue to compute commands; the new step is protected exclusive- controller state and a monotonic epoch that rejects commands from superseded controllers at the finality sink. Appendix B. End-to-End Example: Parcel Delivery with a Mid-Flight Restriction 1. Before take-off, the operator's USS issues an AAO for corridor segments 1-4, drop zone D7, v_max 15 m/s, offline T_off_max 60 s, act classes ARM, KINETIC_ENVELOPE, VOLUME_ENTRY, PAYLOAD_RELEASE, RF_EMIT, at g_air 412. 2. The PED verifies the AAO, anchors a new evidence epoch, and the RID module broadcasts the Anchor and the Evidence Key Endorsement alongside DRIP authentication. 3. ARM handle consumed; receipt n=1 committed; ESC enable released; AER (ARM, ALLOW, n=1) broadcast. 4. Envelope handle for segment 1 consumed; the comparator admits setpoints inside E. Revalidation interval shrinks near the segment boundary per Section 9.2. 5. At 14:07 a restriction arrives as g_air 413 intersecting segment 3. The PED invalidates the segment-3 handle before it is used. On reaching the end of segment 2 the VOLUME_ENTRY request for segment 3 is denied (EF-061); the aircraft holds and requests a reroute; AER (VOLUME_ENTRY, DENY, n=9) broadcast. 6. A new AAO at g_air 413 authorizes segments 3a-3b. Flight continues. 7. Over D7, P_payload holds (inside zone, h below limit, speed and tilt within bounds, positions consistent). PAYLOAD_RELEASE handle consumed, receipt committed, latch solenoid powered for its window. A police officer nearby sees the parcel lowered and, about three seconds later, the Observer app shows a verified record (PAYLOAD_RELEASE, ALLOW) from the enforcement domain of the identified aircraft. Das Expires 22 March 2027 [Page 91] Internet-Draft UAS/AV Act Finality September 2026 Appendix C. Test Vector Classes The accompanying reference repository includes deterministic byte- level vectors for selected BPC, AER/KDR, and authenticated- fragmentation cases. Future revisions of this document are expected to include or normatively reference a broader set of vectors for the following classes: (1) U-CAD canonical encoding and digest using both the readable text-key representation and the compact integer-key profile; (2) handle bound to wrong sink; (3) SINGLE_USE replay; (4) envelope exit by position, speed, altitude, window, and aggregate ceiling; (5) generation advance affecting and not affecting the corridor; (6) revocation read inside consume; (7) GNSS/VIO disagreement; (8) offline window expiry; (9) composite COMMIT, CAS ABORT, and HOLD on unreachable log; (10) keyed BPC Binding Commitment computation; (11) compact Authority Reference resolution, including UNKNOWN and stale-reference denial; (12) BPC truncation at selected collision and attacker-work budgets; (13) collision guard ambiguity causing deny or escalation; (14) authenticated fragment generation, cross-session mixing rejection, missing-fragment denial, ordered reconstruction, and Root verification; (15) BPC capsule-authenticator computation and forgery-budget sizing; (16) sink-side reconstruction of the actual pending act and compact-binding comparison; (17) master-seed derivation of K_N and reverse-chain derivation through K_0; (18) AER tag computation; (19) Observer safety condition at the boundary x = i + d; (20) lost KDR recovery across several intervals; (21) evidence-epoch renewal before 16-bit index reuse; (22) Observer using network time with insufficient delta_max; (23) receipt presented as handle; and (24) AER, KDR, Anchor, or BPC evidence presented as execution authority. Author's Address Sangam Das Independent Inventor Balasore Odisha India Email: info@sangamdas.com Das Expires 22 March 2027 [Page 92]