Composing Application-Layer Action Evidence with Remote Attestation Procedures
draft-sokolov-rats-aep-composition-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
The information below is for an old version of the document.
| Document | Type |
This is an older version of an Internet-Draft whose latest revision state is "Active".
|
|
|---|---|---|---|
| Author | Anton Sokolov | ||
| Last updated | 2026-06-27 (Latest revision 2026-06-24) | ||
| RFC stream | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-sokolov-rats-aep-composition-01
Remote ATtestation ProcedureS (RATS) A. Sokolov
Internet-Draft Tyche Institute
Intended status: Informational 27 June 2026
Expires: 29 December 2026
Composing Application-Layer Action Evidence with Remote Attestation
Procedures
draft-sokolov-rats-aep-composition-01
Abstract
This document sketches a composition pattern in which an application-
layer "action evidence package" (AEP) -- a signed, append-only record
of an action taken by an automated (for example, AI-agent) system,
the authority under which it was taken, and its outcome -- is treated
as Evidence in the sense of the RATS Architecture (RFC 9334) and
bound to platform Evidence produced by a hardware root of trust. The
intent is that a single Verifier, or a composition of Verifiers, can
appraise both the platform state and the application-layer action
together, and emit an Attestation Result that a Relying Party can use
to reason about _what an automated system did_ and _on what platform
it did so_ without trusting the operator's self-report for either.
This is an individual sketch intended to ask the working group
whether the pattern is already covered by existing mechanisms or
warrants a short document.
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.
Sokolov Expires 29 December 2026 [Page 1]
Internet-Draft AEP over RATS June 2026
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 . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Conventions and Definitions . . . . . . . . . . . . . . . . . 3
3. The Action Evidence Package . . . . . . . . . . . . . . . . . 3
4. Composition with RATS . . . . . . . . . . . . . . . . . . . . 3
5. A Result Vocabulary . . . . . . . . . . . . . . . . . . . . . 4
6. Feasibility Note . . . . . . . . . . . . . . . . . . . . . . 4
7. Relationship to Other Work . . . . . . . . . . . . . . . . . 5
8. Security Considerations . . . . . . . . . . . . . . . . . . . 5
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 6
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 6
11.1. Normative References . . . . . . . . . . . . . . . . . . 6
11.2. Informative References . . . . . . . . . . . . . . . . . 7
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 8
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 8
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.
Sokolov Expires 29 December 2026 [Page 2]
Internet-Draft AEP over RATS June 2026
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.
Sokolov Expires 29 December 2026 [Page 3]
Internet-Draft AEP over RATS June 2026
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].
Sokolov Expires 29 December 2026 [Page 4]
Internet-Draft AEP over RATS June 2026
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.
Sokolov Expires 29 December 2026 [Page 5]
Internet-Draft AEP over RATS June 2026
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
11.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/info/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/info/rfc8174>.
[RFC9334] Birkholz, H., Thaler, D., Richardson, M., Smith, N., and
W. Pan, "Remote ATtestation procedureS (RATS)
Architecture", RFC 9334, DOI 10.17487/RFC9334, January
2023, <https://www.rfc-editor.org/info/rfc9334>.
Sokolov Expires 29 December 2026 [Page 6]
Internet-Draft AEP over RATS June 2026
[RFC9711] Lundblade, L., Mandyam, G., O'Donoghue, J., and C.
Wallace, "The Entity Attestation Token (EAT)", RFC 9711,
DOI 10.17487/RFC9711, April 2025,
<https://www.rfc-editor.org/info/rfc9711>.
11.2. Informative References
[I-D.ietf-rats-ar4si]
Voit, E., Birkholz, H., Hardjono, T., Fossati, T., and V.
Scarlata, "Attestation Results for Secure Interactions",
Work in Progress, Internet-Draft, draft-ietf-rats-ar4si-
10, 18 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-ar4si-10>.
[I-D.ietf-rats-ear]
Fossati, T., Voit, E., Trofimov, S., and H. Birkholz, "EAT
Attestation Results", Work in Progress, Internet-Draft,
draft-ietf-rats-ear-04, 26 May 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-rats-
ear-04>.
[I-D.ietf-rats-msg-wrap]
Birkholz, H., Smith, N., Fossati, T., Tschofenig, H., and
D. Glaze, "RATS Conceptual Messages Wrapper (CMW)", Work
in Progress, Internet-Draft, draft-ietf-rats-msg-wrap-23,
11 December 2025, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-msg-wrap-23>.
[I-D.ietf-rats-corim]
Birkholz, H., Fossati, T., Deshpande, Y., Smith, N., and
W. Pan, "Concise Reference Integrity Manifest", Work in
Progress, Internet-Draft, draft-ietf-rats-corim-10, 2
March 2026, <https://datatracker.ietf.org/doc/html/draft-
ietf-rats-corim-10>.
[I-D.ietf-rats-multi-verifier]
Deshpande, Y., jun, Z., Labiod, H., and H. Birkholz,
"Remote Attestation with Multiple Verifiers", Work in
Progress, Internet-Draft, draft-ietf-rats-multi-verifier-
00, 5 May 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-rats-multi-verifier-00>.
[I-D.birkholz-verifiable-agent-conversations]
Birkholz, H., Heldt, T., and O. Steele, "Verifiable Agent
Conversation Records", Work in Progress, Internet-Draft,
draft-birkholz-verifiable-agent-conversations-00, 25
February 2026, <https://datatracker.ietf.org/doc/html/
draft-birkholz-verifiable-agent-conversations-00>.
Sokolov Expires 29 December 2026 [Page 7]
Internet-Draft AEP over RATS June 2026
[I-D.sato-soos-aep]
Sato, "The Agent Execution Protocol (AEP) for Agentic AI
Systems", Work in Progress, Internet-Draft, draft-sato-
soos-aep-01, 10 June 2026,
<https://datatracker.ietf.org/doc/html/draft-sato-soos-
aep-01>.
[I-D.novak-rats-twi-attestation]
Novak, M., Deshpande, Y., and H. Birkholz, "Remote
Attestation for Trustworthy Workload Identity", Work in
Progress, Internet-Draft, draft-novak-rats-twi-
attestation-00, 5 November 2025,
<https://datatracker.ietf.org/doc/html/draft-novak-rats-
twi-attestation-00>.
[I-D.ounsworth-rats-privacy-framework]
Ounsworth, M., Tschofenig, H., and G. Lehmann, "Privacy
Framework for Remote ATtestation procedureS", Work in
Progress, Internet-Draft, draft-ounsworth-rats-privacy-
framework-00, 18 June 2026,
<https://datatracker.ietf.org/doc/html/draft-ounsworth-
rats-privacy-framework-00>.
[ZENODO-AEP]
Sokolov, A., "Hardware-rooted attestation for AI-agent
evidence: composing IETF RATS with action evidence
packages", 2026,
<https://doi.org/10.5281/zenodo.20818672>.
Acknowledgements
Thanks to the Veraison community for the discussion that prompted
this sketch.
Author's Address
Anton Sokolov
Tyche Institute
Tallinn
Estonia
Email: anton.sokolov@tyche.institute
Sokolov Expires 29 December 2026 [Page 8]