Composing Application-Layer Action Evidence with Remote Attestation Procedures

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 29 December 2026.¶

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

Records of automated decision-making are increasingly produced for accountability purposes: an action identifier, an authorising principal, inputs and tool calls, and an outcome, chained so that tampering is detectable. Such an action evidence package (AEP) is useful but has the standard self-report limitation: every field is asserted by the same software stack whose integrity is in question. The signature proves the record was produced by a key the runtime holds; it does not prove what the runtime was.¶

The RATS Architecture [RFC9334] separates the party that produces Evidence (Attester), the party that appraises it (Verifier), and the party that acts on the verdict (Relying Party). Binding an AEP to platform Evidence appraised under RATS supplies the independence the self-report lacks. This document describes the composition and asks whether it is novel enough to specify.¶

2. Conventions and Definitions

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.¶

This document uses RATS terminology as defined in [RFC9334]: the roles Attester, Verifier, Relying Party, Endorser, and Reference Value Provider, and the conceptual messages Evidence, Endorsements, Reference Values, and Attestation Results.¶

3. The Action Evidence Package

An AEP is an application-layer, signed, append-only record. For the purposes of this document its salient properties are: (a) it records an action, an authorising principal, and an outcome; (b) it is chained for tamper-evidence; and (c) it is produced by the same software stack that performs the action. Property (c) is precisely why it benefits from composition with platform Evidence.¶

4. Composition with RATS

The composition treats the AEP as application-layer Evidence conveyed alongside platform Evidence:¶

1. The platform produces hardware-rooted Evidence (for example, a TPM quote over measured-boot registers, or a TEE attestation token), appraised against Reference Values (for example, conveyed as a Concise Reference Integrity Manifest [I-D.ietf-rats-corim]) and Endorsements by a Verifier.¶

2. The AEP is conveyed as a further Evidence item. Candidate conveyances are an EAT [RFC9711] carrying the AEP (or a digest of it) as a claim or submodule (the EAT submodule / Detached-Submodule-Digest mechanism is the standard nesting facility here), or a CMW collection -- the RATS Conceptual Messages Wrapper [I-D.ietf-rats-msg-wrap] -- that groups the platform Evidence and the AEP into one message.¶

3. A Verifier -- or, following the layered Platform-Verifier / Workload-Verifier pattern of [I-D.ietf-rats-multi-verifier], a platform Verifier and an application Verifier in composition -- appraises both and emits an Attestation Result.¶

The binding between the two is load-bearing: the AEP, at record time, SHOULD incorporate a reference to a fresh platform appraisal (or to the platform Evidence and the nonce that scoped it), so that a later Relying Party can ask not only "what did the automated system do, and under what authority?" but "and was it done on a platform whose state was independently attested within the same freshness window?". The [RFC9334] Section 10 freshness mechanisms -- nonces, synchronised-clock timestamps, and Epoch IDs/handles -- apply unchanged.¶

5. A Result Vocabulary

For a non-specialist Relying Party, this work resolves an appraisal to a small two-axis vocabulary: an authorisation axis computed from the AEP and policy (Authorised / Unauthorised / Indeterminate) and a platform axis (Attested / Contested / Expired). AR4SI [I-D.ietf-rats-ar4si] defines four trustworthiness tiers -- none, affirming, warning, contraindicated -- serialised in an EAR [I-D.ietf-rats-ear]. Two of the platform terms map directly onto those tiers: an affirming appraisal to Attested; a warning or contraindicated appraisal that runs but contradicts Reference Values to Contested; while the none tier, in which the Verifier asserts nothing, denotes an inconclusive appraisal rather than a pass or fail. Expired is deliberately NOT an AR4SI trustworthiness tier: it captures a separate, token-level condition -- evidence stale relative to the freshness policy, or supporting material that has lapsed -- surfaced by the EAT exp claim and by nonce-based evidence freshness, not by the trustworthiness vocabulary. This correspondence is provisional and SHOULD be validated against a Verifier's actual EAR output; the working group's view on whether such a mapping belongs in a document, or purely in deployment guidance, is solicited.¶

6. Feasibility Note

A small emulated feasibility check (software TPM via swtpm, with a minimal Verifier stand-in) folds the hash of an AEP outcome and a fresh nonce into an attestation-key-signed quote, with a model-artefact measurement in a platform register, and resolves the three platform-axis cases and rejects a forged outcome bound to a valid quote. It is emulated and minimal; it demonstrates the binding, not a hardware-rooted guarantee. Details are in [ZENODO-AEP].¶

7. Relationship to Other Work

The closest related effort is Verifiable Agent Conversation Records [I-D.birkholz-verifiable-agent-conversations], which defines a CDDL data format, with COSE signing, for cryptographically verifiable records of an automated agent's conversations, and likewise draws on the RATS Architecture and on transparency logging. That work standardises the record at conversation granularity; the present document is agnostic to the record's internal format and instead concerns composing a single action record with platform Evidence so that one appraisal covers both axes. The two are complementary: such a verifiable conversation record could itself be the application-layer record carried in this composition.¶

A naming note: the three-letter string "AEP" is used by more than one independent effort. In this document AEP denotes an Action Evidence Package, the application-layer record defined in Section 3. It is distinct from the Agent Execution Protocol of [I-D.sato-soos-aep], which specifies an agent execution loop within a broader agentic-governance suite; that is a different concept at a different layer, and this document neither depends on it nor competes with it.¶

Workload-identity attestation -- for example Remote Attestation for Trustworthy Workload Identity [I-D.novak-rats-twi-attestation], which lets an isolated workload acquire credentials with a stable identifier by attesting its environment -- is orthogonal: it establishes which workload is running, whereas this sketch concerns what action a workload took. The two could be composed, but the present document does not require it.¶

8. Security Considerations

Composition does not dissolve trust assumptions; it relocates them. The platform axis depends on the hardware vendor's Endorsements and the Verifier's independence; the AEP axis depends on the integrity of the key the runtime holds, which is exactly what the platform Evidence is meant to ground. Binding an AEP to a platform appraisal is only as fresh as the weaker of the two freshness mechanisms. Attesting a specific model or workload version requires that artefact be measured into the attested state, which is a deployment commitment. A forged AEP outcome presented under an otherwise-valid platform quote MUST be detectable through the output-binding: the outcome digest is covered by the quote's signed data, so an implementation that binds the AEP reference outside the signed data does not achieve this property. The feasibility note above demonstrates this binding in emulation only (a software TPM); on real hardware the guarantee holds to the extent the outcome digest is genuinely inside the signed and quoted data.¶

9. Privacy Considerations

An action evidence package can carry privacy-sensitive material: the authorising principal's identity, the inputs and tool calls of an action, and its outcome may constitute personal data or business-confidential information. Conveying an AEP as Evidence to a Verifier widens its exposure beyond the original relying context, so the privacy considerations for attestation Evidence in [I-D.ounsworth-rats-privacy-framework] apply to the application-layer axis as well as the platform axis. Implementations SHOULD apply data-minimisation: where the appraisal permits, convey a digest of the AEP rather than its contents, and disclose individual fields selectively to the parties that need them. The binding to platform Evidence SHOULD NOT require disclosing AEP contents to a platform Verifier that is appraising only the platform axis; the layered Platform-Verifier / Application-Verifier arrangement of [I-D.ietf-rats-multi-verifier] lets a deployment keep AEP contents away from the platform Verifier entirely. Where a single Verifier appraises both axes, that Verifier is inside the privacy boundary and the same minimisation and authorisation constraints apply to it.¶

10. IANA Considerations

This document has no IANA actions. (If a future revision defines an EAT claim or a CMW type for an AEP, the corresponding registrations would appear here.)¶

11. References

Acknowledgements

Thanks to the Veraison community for the discussion that prompted this sketch.¶

Author's Address