]> Aqta Technologies Limited

Dublin Ireland hello@aqta.ai

Security attestation AI receipts audit Ed25519 This document specifies a compact JSON attestation receipt for an AI inference decision. A receipt binds an outcome to a request hash under a published Ed25519 public key, so a party that does not trust the issuer's infrastructure can still verify offline what the issuer's signing key attested was decided. The format is intentionally small and version-selected, so independent verifiers stay easy to implement and audit. It is intended for settings where an operator-controlled log is not, on its own, sufficient evidence of the decision.

Introduction AI systems that take or influence consequential actions are increasingly deployed in regulated settings. When such a decision is later questioned, the party being questioned is frequently also the party that produced the record of the decision. A log an operator controls does not, on its own, let an independent reviewer confirm what was asked or what was decided. This document defines a compact receipt that an issuer signs for an LLM inference decision. The receipt is verifiable offline by any holder of the issuer's public key. The verifier need not contact the issuer at verification time.

The figure is informative. The normative processing rules are in and . Note that the verifier obtains the public key out of band; the key carried in the receipt establishes integrity, not the identity of the issuer.

Relationship to Other Work Related Internet-Drafts address neighbouring problems. profiles signed action receipts for AI agents. defines signed decision receipts for machine-to-machine access control, using RFC 8785 for canonicalisation. profiles COSE and CWT to bind model identity, input and output hashes and platform attestation evidence into one signed artefact for inference inside a trusted execution environment. It answers a question this document explicitly does not, namely what a TEE-resident workload can assert about the environment that executed a particular inference. These documents address adjacent or overlapping receipt problems, and AIR in particular solves a different one: it binds a receipt to a confidential workload and requires a verifier to appraise platform attestation before execution provenance is established. This document instead specifies one deliberately smaller application-layer receipt shape for the LLM inference decision case, with an explicit verification algorithm, a version-selected signature suite, and published conformance vectors. Implementations MAY also implement the related drafts; this document does not redefine them. The wider literature has moved quickly and this document does not claim the mechanism. records agent actions as canonically serialised, hash-chained events with Merkle batching and periodic external anchoring, and reports detection of edit, delete, reorder and fork tampering under its stated system model. inverts the trust boundary, having the receiving service sign what it observed rather than relying on the caller's account of it. sets out pre-effect authorisation and authorisation-bound execution for agent tool calls, including a receiver-signed effect receipt and replay blocking, and is directly adjacent to . specifies agent audit records with pre-execution recording, recording independence from the acting component, deny reasons, replay protection and external anchoring. draws the distinction between a broad permission and whether one exact act against one exact destination is authorised to take effect, and binds a receipt to the candidate act at the last control point before physical consequence. Taken together, these works establish substantial prior art for agent audit trails, tamper-evident action histories, act-scoped authority and execution-bound evidence. This document therefore claims no novelty for signed records, audit trails, transparency mechanisms or pre-execution authorisation in isolation. Its subject is the specific record semantics and verification model set out here, and nothing wider. What this document contributes is narrower than the category and is stated as such: one small payload format for the inference-decision case, with an explicit verification algorithm, a version-selected signature suite, published conformance vectors, and two separately written reference implementations that are required to return the same verdict on the same bytes. The value claimed is reproducibility by a third party, not novelty of construction.

Sibling Record Type for Agent Actions The deployment this document describes has since grown a second record type, ACTION-v1, for the authorisation of an agent tool action before it runs, as distinct from a model inference decision. It is a sibling of this format rather than a successor: it is signed by the same key, verified by the same implementations, and reuses the canonicalisation of and unchanged. The receipt described in this document is untouched by its existence, and every receipt that verified before it was defined verifies identically now. Two points about that pairing matter to any implementer of this document. First, the two record types both carry signature and public_key in the same shape, so they cannot be told apart by inspecting field names. A verifier that guesses which type it holds from the shape of the object will misclassify one as the other and skip checks specific to the type it actually received. Selection of the record type MUST therefore be explicit, supplied by the caller, and a verifier MUST reject a record whose type tag does not match the type it was asked to verify. Second, a conformant verifier for this document MUST reject an ACTION-v1 record, and the reverse. ACTION-v1 is specified outside this document. It is described here only so that an implementer of this format knows the discrimination rule, which is a property of this format's own verification and not of the other one.

Key Lifecycle This document assumes the verifier already holds a public key it has reason to trust, and does not define how that key is distributed, rotated, revoked, or evaluated for validity at a past point in time. For evidence retained over years these are load-bearing: a key compromised in a later year casts doubt on receipts nominally issued before it, and this format alone provides no way to distinguish them. Addressing that requires mechanisms outside this document, such as key transparency, an append-only log of issuance, or third-party witnesses. A later version may profile one.

Non-Goals This document does not: Claim that a decision was correct, safe, lawful, or free of model error. Define policy language, agent tool protocols, or model evaluation methods. Require a Trusted Execution Environment, hardware root of trust, or qualified timestamp authority. Define deployment topology, commercial packaging, or product features beyond the receipt bytes. Replace platform attestation documents (for example TEE quotes). A receipt is application-layer evidence of a decision, not hardware evidence of the runtime. A receipt that verifies proves only what states.

Requirements Language 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 when, and only when, they appear in all capitals, as shown here.

Terminology

Issuer:

The system that produces and signs a receipt.

Subject:

The organisation, identified by org_id, for which the decision was made.

Verifier:

Any party that checks a receipt's signature against a public key it trusts for the issuer.

Trusted public key:

The Ed25519 public key the verifier has obtained out of band for the issuer. It is not sufficient to trust only the public_key field embedded in a receipt.

Receipt Structure A receipt is a single JSON object . Version 1 defines the required fields in and the optional fields in . Unless a field is listed in this document for version 1, it MUST NOT appear at the top level. Verifiers MUST reject receipts that contain unknown top-level fields. This closed set keeps independent verifiers simple and prevents silent semantic drift.

Required Fields Field Type Description v integer Format and suite version. MUST be 1 for this document. attestation_id string UUID string, unique per receipt. Production issuers SHOULD use UUID version 4. trace_id string Issuer-assigned identifier for the LLM call. org_id string Identifier of the subject organisation. request_hash string SHA-256 digest of the canonicalised request body, 64 lowercase hex characters. model string Provider-qualified model identifier. outcome string One of the values in . policy_applied array Array of UTF-8 string policy identifiers, sorted lexicographically by UTF-16 code unit (). MAY be empty. cost_prevented_eur number Non-negative number. MUST be 0 when not computed. See . timestamp string RFC 3339 datetime with an explicit timezone offset. public_key string base64url-encoded raw 32-byte Ed25519 public key, no padding. signature string base64url-encoded 64-byte Ed25519 signature, no padding. Omitted from the canonical payload.

Optional Fields The following fields MAY appear. If present, they MUST match the types below. They are ignored by signature verification except that they participate in the canonical payload when present (see ). Field Type Description prev_attestation_id string attestation_id of a prior receipt in an issuer-defined chain. prev_attestation_hash string SHA-256 hex digest binding this receipt to prior receipt bytes, as defined by the issuer. spec_version string If present, MUST be the ASCII string "ATTESTATION-v1". If prev_attestation_id is present, prev_attestation_hash MUST also be present. Verifiers that do not implement chaining MUST still accept well-formed receipts that include these fields, and MUST still enforce the signature and required field checks. Because these fields are optional and issuer-populated, they make a sequence tamper-evident to a party that follows the whole sequence. They do not make an individual receipt tamper-proof, and they do not constrain an issuer that emits unchained receipts or that omits a decision from the chain entirely. Detecting omission requires evidence outside this format.

cost_prevented_eur cost_prevented_eur is retained for wire compatibility with existing version-1 issuers. It is an issuer estimate only. It is not part of the security claim of the receipt. New issuers SHOULD emit 0. Verifiers MUST NOT treat a non-zero value as proof of savings, risk reduction, or policy quality.

Outcome Values The outcome field MUST be one of:

ALLOWED:

The request was permitted to proceed to the model provider.

BLOCKED:

The request was not sent to the model provider.

SUPPRESSED:

The request was not sent because the issuer detected a runaway or loop condition.

PASSED:

A synonym of ALLOWED retained for backward compatibility. New issuers SHOULD emit ALLOWED.

What a Verified Receipt Proves A receipt that verifies under a trusted public key proves that the holder of the corresponding private key attested to the included fields, including outcome, request_hash and the stated timestamp value. It does not prove that the underlying model output was correct, that the policy identifiers were appropriate, or that the issuer's process was fair. The request_hash is a commitment, not a disclosure. It does not reveal the request, and it does not on its own establish that any particular request was the one presented to the issuer. It lets a verifier that already holds a candidate request test whether that candidate matches the commitment. What was decided is established by the signed outcome field, not by the hash. See for the case where the request is low-entropy enough to be recovered by hashing candidates. The receipt does not independently establish when the attestation was made. The timestamp is a field chosen by the issuer and covered by the signature, so a verifying receipt shows that the issuer signed that value, not that signing occurred at that time. Establishing when a receipt existed requires evidence outside this format, such as inclusion in an append-only log observed by a third party, or a timestamp from an authority this document does not define.

Canonical Payload and Signing The canonical payload is produced by: Rejecting the receipt if the JSON object contains duplicate member names at any level, or if any input byte sequence is not well-formed UTF-8. A verifier MUST decode strictly: it MUST NOT substitute U+FFFD REPLACEMENT CHARACTER for an ill-formed sequence, because a lossy decode turns bytes that were never signed into a payload that verifies. notes that implementations disagree over which value wins when names repeat, so a receipt containing them has no single canonical payload and MUST NOT be treated as verifiable. Removing the signature field, if present. Serialising the remaining fields to JSON with all object keys sorted lexicographically by UTF-16 code unit as specified in Section 3.2.3, and no whitespace between tokens. See : "lexicographic" without a named encoding is not sufficient to make two implementations agree. Encoding the result as UTF-8, with non-ASCII characters emitted literally as UTF-8 and never as \uXXXX escapes (see ). Serialising every integer-valued number, including a float such as 1.0, as an integer with no decimal point or trailing zero, and every other number as the shortest decimal representation that round-trips to the same IEEE 754 binary64 value. A number whose shortest representation requires exponential notation, meaning a magnitude below 1e-4 or at or above 1e21, is outside the range that common implementations serialise identically. An issuer MUST NOT sign such a value directly; where one would arise it MUST first be rounded into the safe range (for cost_prevented_eur, to two decimal places). Within that permitted range the rule above is the rule of Section 3.2.2.3, which is the ECMA-262 Number::toString algorithm: both produce the shortest decimal that round-trips to the same binary64 value. This format differs from RFC 8785 only in forbidding the values RFC 8785 would serialise in exponential notation, rather than in how any permitted value is written. Earlier revisions of this document said that the format "does not adopt" RFC 8785 number serialisation, which overstated the difference and disagreed with the implementation specification; that wording is corrected here.

Signature Suite and Algorithm Agility The version field v identifies the complete cryptographic suite, not only the field layout. In version 1 the suite is Ed25519 over the canonical payload. The issuer signs the canonical payload bytes and places the base64url-encoded signature, without padding, in the signature field. A verifier MUST select the signature algorithm from v and MUST NOT infer it from the length or contents of the signature field. A future version MAY define a post-quantum suite. A verifier that does not implement the suite named by v MUST reject the receipt rather than guess.

Request Hash The request_hash field is the SHA-256 digest , encoded as 64 lowercase hexadecimal characters, of the request body serialised by applying the same canonicalisation algorithm defined in to the request JSON, including its number rule. The algorithm is identical; only the input differs. Request bodies often carry non-integer sampling parameters such as temperature or top_p, so an issuer whose requests can contain numbers in the exponential range SHOULD round them before hashing. The digest is computed over the request body as received from the caller, before any redaction, so that a verifier holding the original request can reproduce it. A verifier that does not hold the original request treats request_hash as an opaque commitment.

String Canonicalisation Strings MUST be serialised as literal UTF-8. Escaping non-ASCII characters as \uXXXX produces different canonical bytes and MUST NOT be done; only the escapes required by are permitted. Mainstream JSON serialisers disagree by default on this point. Issuers and verifiers MUST both emit literal UTF-8.

Ordering Wherever this document requires strings to be in lexicographic order, whether object keys under or the members of policy_applied, the comparison MUST be by UTF-16 code unit, as Section 3.2.3 specifies for object keys. Implementations MUST NOT compare by Unicode code point or by locale. The two orderings agree across the whole Basic Multilingual Plane and diverge only when a character outside it is present, because such a character is represented in UTF-16 by a surrogate pair whose leading unit is numerically lower than U+E000. U+E000 therefore sorts after U+1F600 by code unit and before it by code point. This is stated normatively because the ambiguity has already produced a real divergence. Two independently written reference verifiers for this format, one in TypeScript and one in Python, disagreed on signed receipts carrying a non-Basic-Multilingual-Plane policy identifier: the first used its language's native string comparison, which is by UTF-16 code unit, and the second used its language's native comparison, which is by code point. Both implementations were faithful to the text of earlier revisions, which said only "lexicographically". A conformance suite containing only ASCII policy identifiers could not distinguish them.

Verification A verifier that holds a trusted public key for the issuer: Confirms all required fields are present and well-typed for , including: request_hash is 64 lowercase hex characters; public_key and signature decode as unpadded base64url to 32 and 64 bytes respectively; cost_prevented_eur is a non-negative number; timestamp is an RFC 3339 datetime with an explicit timezone offset; and policy_applied is an array of strings in lexicographic order by UTF-16 code unit (). Confirms no unknown top-level fields exist. Confirms optional fields, if present, satisfy . Confirms outcome is one of the values in . Confirms the embedded public_key equals the trusted public key. Reconstructs the canonical payload per . Verifies the signature over the canonical bytes using the suite named by v and the trusted public key. Verifying only against the embedded public_key, without an out-of-band trust decision, proves integrity of the object but not issuer identity.

Conformance An implementation claiming conformance to this document MUST: Produce or accept receipts matching . Implement canonicalisation and verification as specified in and . Reject the invalid cases described by the published conformance vectors referenced in . Informative interoperability artefacts, including valid and invalid receipts and a fixed test public key, are published with the ATTESTATION-v1 specification repository. Those vectors are not normative text of this document; if a vector and this document disagree, this document prevails, and the vector set SHOULD be corrected.

Security Considerations The trust boundary this format establishes, and the questions it leaves open, are summarised below. The figure is informative; the normative rules are in and .

| creates the receipt | | chooses the timestamp | | holds the signing key | +------------+------------+ | signed receipt | v +-------------------------+ | Verifier | | holds a trusted key | | recomputes the payload | | checks the signature | +------------+------------+ | v the signed fields are authentic and have not been altered NOT ESTABLISHED BY THIS FORMAT ALONE +-------------------------------------------------------+ | when the receipt existed -> append-only log, | | witness, or a | | timestamp authority | | that the claimed model ran -> platform attestation| | that no decision was omitted -> reconciliation | | against a record | | the issuer does not | | produce | | that the decision was correct -> outside any | | evidence format | | that a later key compromise -> key transparency, | | does not undermine old -> revocation, or | | receipts -> historical status | +-------------------------------------------------------+ ]]>

Note that the issuer controls both the signing key and the timestamp, so a verifier that trusts the key learns what the issuer asserted and that nobody altered it afterwards. Every item in the lower box requires a mechanism this document does not define.

Issuer Identity A receipt proves that the holder of a private key signed the stated fields. It does not, on its own, prove which organisation that key represents. Verifiers MUST pin the issuer's public key out of band (for example via a published key URL, an enterprise configuration, or a trust list).

Confidentiality of Requests Receipts contain no plaintext prompt or response, only a request hash. For a high-entropy request body the hash reveals nothing useful by inversion. Where the request body is low-entropy or guessable, an attacker can hash candidates and match. Deployments MUST treat request_hash as potentially personal data and apply their own data-protection controls. Issuers that require pseudonymity SHOULD hash with a key kept secret from verifiers, at the cost of offline reproducibility by third parties.

Integrity Versus Correctness Signature verification establishes integrity and issuer attribution under a pinned key. It does not establish that the decision was the right decision.

Post-Quantum Considerations Ed25519 is not post-quantum secure. An adversary with a cryptographically relevant quantum computer could forge signatures under an issuer key that was active before migration, which matters where long audit retention intersects that horizon. SHA-256 request binding remains useful as a tamper-detection commitment for detecting alteration of past receipt bytes under known attacks on hashes. Because v selects the whole suite (), a later version can introduce a post-quantum signature suite without changing the field names. This document does not define such a suite.

IANA Considerations This document has no IANA actions. A future revision may request registration of a media type for the receipt object.

This document describes elliptic curve signature scheme Edwards-curve Digital Signature Algorithm (EdDSA). The algorithm is instantiated with recommended parameters for the edwards25519 and edwards448 curves. An example implementation and test vectors are provided. JavaScript Object Notation (JSON) is a lightweight, text-based, language-independent data interchange format. It was derived from the ECMAScript Programming Language Standard. JSON defines a small set of formatting rules for the portable representation of structured data. This document removes inconsistencies with other specifications of JSON, repairs specification errors, and offers experience-based interoperability guidance. Federal Information Processing Standard, FIPS Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. Asqav This document defines a multi-jurisdiction compliance profile of the signed action receipt format used by AI agents to record machine- readable evidence of access-control decisions. The profile binds receipt fields to two regulatory surfaces: on the European Union side, Articles 12 and 26 of the EU AI Act (Regulation (EU) 2024/1689) and Article 17 of DORA (Regulation (EU) 2022/2554); on the United States side, the NIST AI Risk Management Framework, the Colorado AI Act, the Texas Responsible AI Governance Act, the New York Department of Financial Services Cybersecurity Regulation (23 NYCRR Part 500), the HIPAA Security Rule, SEC Rule 17a-4, and the Cyber Incident Reporting for Critical Infrastructure Act of 2022 (CIRCIA). Working entirely within the existing wire format, canonicalization transformation, and signing algorithms of the underlying receipt format, the profile tightens a subset of the OPTIONAL fields to REQUIRED, imposes a retention floor, and requires at least one timestamping anchor (RFC 3161 or OpenTimestamps). It registers OPTIONAL extension fields for risk and incident classification, cross-agent envelope binding, per-action validity-window and integrity, build provenance, threat-framework taxonomy, server-built enforcement-control records, producer-asserted risk acceptance, and producer-asserted code authorship, each subject to false-attestation guards where applicable, and registers receipt type namespaces for passive-telemetry, result-bound observation, risk-acceptance, and code-authorship receipts. Revision -08 additionally defines an attestation statement envelope (a Dead Simple Signing Envelope (DSSE) Pre-Authentication Encoding wrapping an in-toto Statement v1 under an asqav predicate namespace) with two tiers: a voluntary observation attestation that signs a caller-supplied digest and is explicitly not a capture, and an authoritative attestation whose subject digest the issuing platform re-derives from independent evidence (for code, the SHA-256 of the raw unified diff re-fetched from the source host); revision -08 further defines the capture-layer integrity, independent verification protocol, honest-tiering, and service-identity and revocation rules that govern those attestation statements, and documents the shipped keyed-digest wire tokens and the verifier verdict vocabulary (verified, verified_keyed, unverified). The full field set and its normative requirements are defined in the body of this document. ScopeBlind (Veritas Acta) This document defines a portable, cryptographically signed receipt format for recording machine-to-machine access control decisions. Each receipt captures the identity of the decision maker, the tool or resource being accessed, the policy evaluation result, and a timestamp. All of these are signed with Ed25519 [RFC8032] and serialized using deterministic JSON canonicalization [RFC8785]. The format is designed for environments where AI agents invoke tools on behalf of human operators, particularly the Model Context Protocol (MCP) ecosystem. Receipts are independently verifiable without contacting the issuer, enabling offline audit, regulatory compliance, and cross-organizational trust federation. Cyntrisec This document defines the Attested Inference Receipt (AIR), an application-layer COSE_Sign1 envelope carrying CWT claims profiled per the Entity Attestation Token (EAT) framework. An AIR receipt binds model identity, input/output hashes, attestation-linked metadata, and operational telemetry into a single signed artifact suitable for independent third-party verification of a confidential AI inference. An AIR receipt is Attester-signed Evidence, not an appraisal verdict: a RATS Verifier must appraise the referenced platform attestation before the receipt establishes TEE provenance. AIR v1 targets single-inference receipts emitted by workloads running inside hardware-isolated Trusted Execution Environments (TEEs). AIR is attestation-linked: it carries measurements and a hash reference to the platform attestation evidence associated with the inference, but it does not replace platform-specific attestation verification. This version defines AWS Nitro Enclaves and Intel TDX measurement profiles only, and assumes a single platform attestation document per receipt. Pipeline chaining, multi-inference receipts, composite attesters, multi-verifier orchestration, accelerator / GPU confidential-compute attestation integration, and extensibility mechanisms for additional claim or platform profiles are out of scope. CyberSecAI Ltd This document specifies a standard logging format for autonomous AI agent systems. The Agent Audit Trail (AAT) defines a JSON-based record structure with mandatory fields for agent identity, action classification, outcome tracking, and trust level reporting. Records are linked via tamper-evident hash chaining using SHA-256 per RFC 8785, with optional ECDSA signatures for non-repudiation. The format addresses requirements from the EU AI Act (Regulation 2024/1689), which mandates automatic recording of events for high-risk AI systems, whose application dates were staged into 2027-2028 by Regulation (EU) 2026/1744. It also maps informatively to SOC 2 Trust Services Criteria, ISO/IEC 42001, the draft ISO/IEC 24970 and prEN 18229-1 logging standards, and PCI DSS v4.0.1 logging requirements. The design is transport-agnostic and supports export to JSONL, Syslog (RFC 5424), and CSV while preserving chain integrity. Privacy is addressed through input/output hashing, content fingerprinting, and tombstone-based deletion compatible with GDPR Article 17. The -01 revision added pre-execution recording requirements, recording independence, deny reason codes, replay protection, external timestamp anchoring, and content fingerprinting based on feedback from independent implementers. The -02 revision added a Decision Reproducibility section (Section 13) that distinguishes record reproducibility, available for any model, from decision reproducibility, available only for open-weight models executed at temperature zero in an attested environment, and defines the associated record fields. The -03 revision added the Attestation Closure requirement (Section 13.6): the digests recorded for decision reproducibility MUST cover the complete computational closure of the inference function -- model weights, tokenizer, chat template, inference engine build, decoding configuration, and numeric environment -- together with new record fields (tokenizer_digest, chat_template_digest, engine_build_digest) and a minimal-change threat analysis (Section 13.7) showing that any component left outside the attested set is a forgery channel. This revision (-04) adds algorithm agility for post-quantum signatures (ML-DSA-65, FIPS 204) alongside ECDSA P-256; a key identifier (signer_kid, RFC 7638) that resolves which principal signed an independently recorded record; a trust-level assignment integrity requirement (Section 5.3) so that downgrading a consequential action is an attributable event rather than silent suppression; and OPTIONAL Merkle batch anchoring (Section 6.4) using the RFC 6962 construction for compact inclusion proofs at high throughput. All -04 additions are OPTIONAL to produce, and -04 verifiers stay backward compatible with -03: a -04 verifier accepts -03 records, and the new signing metadata is required only in records that carry a signature. Independent Inventor 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- 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 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.

Example Receipt The following informative example is vector valid/001-allowed.json from the conformance set in . A verifier that pins the test public key in MUST accept it. The author regenerated and re-checked this object against that key before publishing this revision; if verification fails, the vector set or this figure is wrong and MUST be corrected before relying on either. Field order in this figure is for readability; canonical signing order is defined in . The signature value is shown on two lines for document formatting only; in the vector file it is a single base64url string with no whitespace.

Pinned test public key for this example and the vector set:

Conformance Vectors Informative conformance vectors (valid receipts, invalid receipts, and the fixed test public key) are published at: https://github.com/Aqta-ai/attestation-spec/tree/main/test-vectors A conformant verifier that pins that test public key MUST accept every receipt in the valid set and MUST reject every receipt in the invalid set. Those vectors are generated from a fixed seed documented in that repository so third parties can reproduce the signatures.

Reference Implementations Open-source reference verifiers implementing this format are published as aqta-verify-receipt on the Python Package Index and on the npm package registry. Those packages are informative aids. Conformance is defined by this document and the vector set in , not by any single implementation.

Changes From draft-chueayen-attestation-receipts-02 Every change in this revision corrects a place where the published text was weaker than the implementation it describes. No wire format change: a receipt that verified under -02 verifies identically under -03, and no v value changes. Lexicographic order is now defined normatively as UTF-16 code unit, in a new Ordering section, and both places that require it point at that section. Earlier revisions said only "lexicographically", which is not sufficient to make two implementations agree; the new section records the divergence that proved it. Strict UTF-8 decoding is now required. A verifier MUST NOT substitute U+FFFD for an ill-formed sequence, because a lossy decode admits bytes that were never signed. The number serialisation paragraph no longer says the format "does not adopt" RFC 8785 number serialisation. Within the range this format permits, the rule is RFC 8785 Section 3.2.2.3; the difference is only that values requiring exponential notation are forbidden here. The old wording overstated the difference and disagreed with the implementation specification. RFC 8785 moves from informative to normative, since ordering and number serialisation are now defined by reference to it. A new section records the sibling record type for agent actions, ACTION-v1, and states the discrimination rule a verifier of this format must follow: record type selection is explicit and never inferred from field shape.

Changes From draft-chueayen-attestation-receipts-00 Added explicit non-goals and a "what a verified receipt proves" section. Clarified relationship to related Internet-Drafts without requiring them. Documented optional chain fields and spec_version for wire clarity. Clarified that cost_prevented_eur is non-security and SHOULD be 0 for new issuers. Added conformance language, an example receipt, and a pointer to published test vectors. Normative reference to SHA-256 via RFC 6234. Tightened verification steps for issuer identity pinning. Softened attestation_id to UUID string with version-4 SHOULD, matching the published conformance vectors. Clarified policy_applied as UTF-8 strings (matches the non-ASCII valid vector) and tightened verification type checks.

Acknowledgements The ordering divergence described in was not found by the author. It, and further defects in the reference implementations, were reported by people outside the author's organisation during a public review of those implementations between August and September 2026. Each was fixed, and each was added to the published conformance vectors as a regression case, which is why the vector set contains non-Basic-Multilingual-Plane identifiers at all.