2293 lines
84 KiB
Markdown
2293 lines
84 KiB
Markdown
---
|
|
title: "Cross-Domain Execution Audit Tokens"
|
|
abbrev: "Execution Audit Tokens"
|
|
category: std
|
|
docname: draft-nennemann-exec-audit-00
|
|
submissiontype: IETF
|
|
number:
|
|
date:
|
|
v: 3
|
|
area: "SEC"
|
|
workgroup: "Individual"
|
|
keyword:
|
|
- execution context
|
|
- audit trail
|
|
- agentic workflows
|
|
- cross-domain
|
|
- regulatory compliance
|
|
- assurance levels
|
|
|
|
author:
|
|
-
|
|
fullname: Christian Nennemann
|
|
organization: Independent Researcher
|
|
email: ietf@nennemann.de
|
|
|
|
normative:
|
|
RFC7515:
|
|
RFC7517:
|
|
RFC7518:
|
|
RFC7519:
|
|
RFC9449:
|
|
RFC9562:
|
|
RFC9110:
|
|
|
|
informative:
|
|
RFC6838:
|
|
RFC8693:
|
|
RFC8725:
|
|
RFC9334:
|
|
I-D.ietf-scitt-architecture:
|
|
I-D.ietf-oauth-transaction-tokens:
|
|
I-D.ietf-wimse-arch:
|
|
I-D.ietf-wimse-s2s-protocol:
|
|
OPENTELEMETRY:
|
|
title: "OpenTelemetry Specification"
|
|
target: https://opentelemetry.io/docs/specs/otel/
|
|
date: false
|
|
author:
|
|
- org: Cloud Native Computing Foundation
|
|
SPIFFE:
|
|
title: "SPIFFE ID"
|
|
target: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
|
|
date: false
|
|
SD-JWT:
|
|
title: "Selective Disclosure for JWTs (SD-JWT)"
|
|
target: https://datatracker.ietf.org/doc/draft-ietf-oauth-selective-disclosure-jwt/
|
|
seriesinfo:
|
|
Internet-Draft: draft-ietf-oauth-selective-disclosure-jwt
|
|
date: 2024
|
|
CERTIFICATE-TRANSPARENCY:
|
|
title: "Certificate Transparency"
|
|
target: https://datatracker.ietf.org/doc/html/rfc9162
|
|
seriesinfo:
|
|
RFC: 9162
|
|
date: 2021
|
|
EU-AI-ACT:
|
|
title: "Regulation (EU) 2024/1689 (AI Act)"
|
|
target: https://eur-lex.europa.eu/eli/reg/2024/1689/oj
|
|
date: 2024
|
|
author:
|
|
- org: European Parliament and Council
|
|
EU-DORA:
|
|
title: "Regulation (EU) 2022/2554 (DORA)"
|
|
target: https://eur-lex.europa.eu/eli/reg/2022/2554/oj
|
|
date: 2022
|
|
author:
|
|
- org: European Parliament and Council
|
|
|
|
--- abstract
|
|
|
|
This document defines Execution Audit Tokens (EATs), a JWT-based
|
|
mechanism for recording task execution across distributed agent
|
|
workflows that span multiple administrative domains, identity
|
|
frameworks, and regulatory jurisdictions. Each EAT captures a
|
|
single task, linked to predecessor tasks through a directed acyclic
|
|
graph (DAG).
|
|
|
|
EATs are identity-framework agnostic and operate with any asymmetric
|
|
key infrastructure including X.509 certificates, OAuth-based
|
|
credentials, SPIFFE/WIMSE identities, DID-based systems, or plain
|
|
JWK sets.
|
|
|
|
EATs support three assurance levels — Level 1 (unsigned JSON),
|
|
Level 2 (JOSE asymmetric signing), and Level 3 (JOSE signing with
|
|
audit ledger) — allowing deployments to choose the appropriate
|
|
trade-off between simplicity and regulatory compliance.
|
|
|
|
For cross-domain workflows, EATs introduce regulatory profile
|
|
metadata, federated audit ledger anchoring, selective disclosure
|
|
at domain boundaries, and machine-readable audit evidence profiles
|
|
to satisfy divergent compliance requirements across jurisdictions
|
|
simultaneously.
|
|
|
|
--- middle
|
|
|
|
# Introduction
|
|
|
|
Distributed agent workflows increasingly span multiple
|
|
administrative domains, identity ecosystems, and regulatory
|
|
jurisdictions. An investment bank's agent in Frankfurt may
|
|
coordinate with a credit rating agency's agent in New York; a
|
|
healthcare agent processing patient data under HIPAA may hand off
|
|
results to a research agent operating under GDPR. In each case,
|
|
the agents must maintain auditable execution records that satisfy
|
|
the compliance requirements of every jurisdiction through which the
|
|
workflow passes.
|
|
|
|
Existing identity frameworks authenticate agents and propagate
|
|
authorization context, but they do not record what those agents
|
|
actually did. Distributed tracing systems (e.g., OpenTelemetry)
|
|
provide observability but lack cryptographic integrity, are
|
|
controlled by the platform operator, and do not satisfy regulatory
|
|
audit requirements. Authorization tokens (e.g., OAuth Transaction
|
|
Tokens) propagate delegation chains but cannot represent the
|
|
branching and convergence patterns of real workflows.
|
|
|
|
This document defines Execution Audit Tokens (EATs), a JWT-based
|
|
mechanism that fills the gap between agent identity and execution
|
|
accountability. Each EAT captures a single task, linked to
|
|
predecessor tasks through a directed acyclic graph (DAG). EATs
|
|
are designed to operate with any identity framework that provides
|
|
asymmetric key pairs with verifiable binding to agent identity.
|
|
|
|
The key design goals are:
|
|
|
|
- Identity-framework independence: EATs work with X.509, OAuth,
|
|
SPIFFE/WIMSE, DID, or plain JWK sets
|
|
- Cross-domain interoperability: A single DAG can span agents
|
|
using different identity frameworks
|
|
- Regulatory flexibility: Machine-readable regulatory profiles
|
|
allow different segments of a workflow to satisfy different
|
|
compliance requirements
|
|
- Federated audit: Each domain operates its own audit ledger;
|
|
cross-ledger anchoring enables end-to-end verification
|
|
- Privacy at boundaries: Selective disclosure allows verification
|
|
of DAG structure without exposing regulated data across
|
|
jurisdictions
|
|
|
|
## Scope and Applicability
|
|
|
|
This document defines:
|
|
|
|
- The Execution Audit Token (EAT) format ({{eat-format}})
|
|
- Three assurance levels for EAT production and verification
|
|
({{level-1}}, {{level-2}}, {{level-3}})
|
|
- DAG structure for task dependency ordering ({{dag-validation}})
|
|
- An HTTP header for EAT transport ({{http-header}})
|
|
- Cross-domain audit model including regulatory profiles,
|
|
federated ledger anchoring, and selective disclosure
|
|
({{cross-domain}})
|
|
- Audit ledger interface requirements ({{ledger-interface}})
|
|
|
|
The following are out of scope and are handled by the deployment's
|
|
identity framework:
|
|
|
|
- Agent authentication and identity provisioning
|
|
- Key distribution and management
|
|
- Trust domain establishment and management
|
|
- Credential lifecycle management
|
|
|
|
## Assurance Levels and Applicability {#assurance-levels}
|
|
|
|
EATs support three assurance levels that govern how tokens are
|
|
produced, transported, and verified. Each level builds on the
|
|
payload structure defined in {{eat-payload}}.
|
|
|
|
Level 1 (L1) — Unsigned JSON:
|
|
: EATs are plain JSON objects with no cryptographic signature.
|
|
Integrity depends on transport security (TLS). L1 is intended
|
|
for internal deployments within a single trust domain where
|
|
non-repudiation is not required, such as development
|
|
environments or internal microservice meshes.
|
|
|
|
Level 2 (L2) — JOSE Asymmetric Signing:
|
|
: EATs are signed as JWS Compact Serialization tokens using
|
|
asymmetric keys bound to the agent's identity credential.
|
|
L2 provides non-repudiation and tamper detection. This is
|
|
the baseline assurance level for cross-organization and
|
|
peer-to-peer deployments.
|
|
|
|
Level 3 (L3) — JOSE Signing with Audit Ledger:
|
|
: L3 extends L2 by requiring that every EAT be recorded in an
|
|
audit ledger with cryptographic commitment (hash chain, Merkle
|
|
tree, or equivalent). L3 is intended for regulated environments
|
|
that require hash-committed audit trails with tamper-evident
|
|
history.
|
|
|
|
Assurance level selection is orthogonal to human-in-the-loop
|
|
(HITL) policy: any level may be combined with HITL requirements.
|
|
Level selection guidance is provided in {{level-selection}}.
|
|
|
|
# Conventions and Definitions
|
|
|
|
{::boilerplate bcp14-tagged}
|
|
|
|
The following terms are used in this document:
|
|
|
|
Agent:
|
|
: An autonomous workload that executes tasks within a workflow.
|
|
|
|
Task:
|
|
: A discrete unit of agent work that consumes inputs and produces
|
|
outputs.
|
|
|
|
Directed Acyclic Graph (DAG):
|
|
: A graph structure representing task dependency ordering where
|
|
edges are directed and no cycles exist.
|
|
|
|
Execution Audit Token (EAT):
|
|
: A token defined by this specification that records task execution
|
|
details. At Level 2 and Level 3, an EAT is a signed JSON Web
|
|
Token {{RFC7519}}. At Level 1, an EAT is an unsigned JSON
|
|
object with the same payload structure.
|
|
|
|
Identity Credential:
|
|
: A credential that proves an agent's identity, such as an X.509
|
|
certificate, an OAuth client credential, a SPIFFE Workload
|
|
Identity Token, a DID document, or a JWK with out-of-band
|
|
binding. See {{identity-binding}}.
|
|
|
|
Assurance Level:
|
|
: One of three tiers (L1, L2, L3) governing how an EAT is
|
|
produced, transported, and verified. See {{assurance-levels}}.
|
|
|
|
Audit Ledger:
|
|
: An append-only, immutable log of all EATs within a workflow or
|
|
set of workflows, used for audit and verification.
|
|
|
|
Trust Domain:
|
|
: An administrative boundary within which agents share a common
|
|
identity authority.
|
|
|
|
Domain Boundary:
|
|
: The point at which a workflow crosses from one trust domain to
|
|
another, potentially involving different identity frameworks,
|
|
regulatory regimes, or audit requirements.
|
|
|
|
Regulatory Profile:
|
|
: A machine-readable identifier specifying the regulatory
|
|
framework governing an EAT, determining required claims,
|
|
retention periods, and audit properties. See
|
|
{{regulatory-profiles}}.
|
|
|
|
Ledger Anchor:
|
|
: A signed receipt from one domain's audit ledger that can be
|
|
verified by another domain's ledger, enabling cross-domain
|
|
audit chain verification. See {{federated-ledger}}.
|
|
|
|
Actor Type:
|
|
: A classification of the entity that performed the task:
|
|
"agent" (autonomous workload), "human" (human operator), or
|
|
"system" (infrastructure component). See {{actor-type-claim}}.
|
|
|
|
# Execution Audit Token Format {#eat-format}
|
|
|
|
An Execution Audit Token records a single task in a distributed
|
|
workflow. The EAT payload structure is common across all assurance
|
|
levels; only the envelope and verification requirements differ.
|
|
|
|
## EAT Payload Structure {#eat-payload}
|
|
|
|
The EAT payload is a JSON object containing the claims defined in
|
|
this section.
|
|
|
|
### Standard Claims
|
|
|
|
The following standard JWT claims {{RFC7519}} are defined for EATs:
|
|
|
|
iss:
|
|
: OPTIONAL at L1; REQUIRED at L2 and L3. StringOrURI. A URI
|
|
identifying the issuer of the EAT. The value MUST correspond
|
|
to the agent's identity as asserted by its identity credential
|
|
(see {{identity-binding}}). Deployments MAY use HTTPS URLs,
|
|
URN:UUID identifiers, SPIFFE IDs, DID URIs, or other URI schemes
|
|
appropriate to the identity framework in use. L1 deployments
|
|
are encouraged to include "iss" for consistency but it is not
|
|
required. See {{l2-verification}} and {{l3-verification}} for
|
|
the L2/L3 verification requirements.
|
|
|
|
aud:
|
|
: RECOMMENDED. StringOrURI or array of StringOrURI. The intended
|
|
recipient(s) of the EAT. The "aud" claim SHOULD contain the
|
|
identifiers of all entities that will verify the EAT. When
|
|
an EAT is to be verified by both the next agent and the audit
|
|
ledger independently, "aud" MUST be an array containing both
|
|
identifiers. Each verifier checks that its own identity
|
|
appears in "aud". The "aud" claim is REQUIRED for L2 and L3
|
|
deployments (see {{l2-verification}} and {{l3-verification}}).
|
|
|
|
iat:
|
|
: REQUIRED. NumericDate. The time at which the EAT was issued.
|
|
|
|
exp:
|
|
: REQUIRED. NumericDate. The expiration time of the EAT.
|
|
Implementations SHOULD set this to 5 to 15 minutes after "iat".
|
|
|
|
jti:
|
|
: REQUIRED. String. A unique identifier for both the EAT and
|
|
the task it records, in UUID format {{RFC9562}}. The "jti"
|
|
serves as both the token identifier (for replay detection) and
|
|
the task identifier (for DAG parent references in "pred").
|
|
Receivers MUST reject EATs whose "jti" has already been seen
|
|
within the expiration window. When "wid" is present,
|
|
uniqueness is scoped to the workflow; when "wid" is absent,
|
|
uniqueness MUST be enforced globally across the EAT store.
|
|
|
|
### Execution Context Claims {#exec-claims}
|
|
|
|
The following claims are defined by this specification:
|
|
|
|
wid:
|
|
: OPTIONAL. String. A workflow identifier that groups related
|
|
EATs into a single workflow. When present, MUST be a UUID
|
|
{{RFC9562}}.
|
|
|
|
exec_act:
|
|
: REQUIRED. String. The action or task type identifier describing
|
|
what the agent performed (e.g., "process_payment",
|
|
"validate_safety"). This claim name avoids collision with the
|
|
"act" (Actor) claim registered by {{RFC8693}}.
|
|
|
|
pred:
|
|
: REQUIRED. Array of strings. Predecessor task identifiers
|
|
representing DAG dependencies. Each element MUST be the "jti"
|
|
value of a previously verified EAT. An empty array indicates
|
|
a root task with no dependencies. A workflow MAY contain
|
|
multiple root tasks. The "pred" claim is always required
|
|
(rather than optional with absence meaning "root task") to
|
|
simplify validation logic and eliminate ambiguity between a
|
|
root task and a claim accidentally omitted.
|
|
|
|
### Actor Type Claim {#actor-type-claim}
|
|
|
|
actor_type:
|
|
: OPTIONAL. String. Identifies the type of entity that
|
|
performed the task. Values are drawn from a controlled
|
|
vocabulary:
|
|
|
|
- "agent": An autonomous software workload (default if omitted)
|
|
- "human": A human operator who performed a manual step,
|
|
such as an approval or review
|
|
- "system": An infrastructure component acting automatically,
|
|
such as a load balancer, gateway, or scheduler
|
|
|
|
When "actor_type" is "human", the "iss" claim SHOULD identify
|
|
the human's organizational identity (e.g., an email-based URI
|
|
or employee identifier URI) rather than a workload identity.
|
|
Human-performed tasks are typically approval or review steps
|
|
in human-in-the-loop (HITL) workflows.
|
|
|
|
At L2 and L3, EATs with "actor_type" of "human" MUST still be
|
|
signed with an asymmetric key. The signing key MAY belong to
|
|
the human's personal credential or to the system through which
|
|
the human performed the action (e.g., an approval gateway),
|
|
with the "iss" claim identifying the human and the signing
|
|
system documented in "eat_ext".
|
|
|
|
### Data Integrity Claims {#data-integrity-claims}
|
|
|
|
The following claims provide integrity verification for task
|
|
inputs and outputs without revealing the data itself:
|
|
|
|
inp_hash:
|
|
: OPTIONAL. String. The base64url encoding (without padding) of
|
|
the SHA-256 hash of the input data, computed over the raw octets
|
|
of the input. SHA-256 is the mandatory algorithm with no
|
|
algorithm prefix in the value, consistent with {{RFC9449}}.
|
|
|
|
out_hash:
|
|
: OPTIONAL. String. The base64url encoding (without padding) of
|
|
the SHA-256 hash of the output data, using the same format as
|
|
"inp_hash".
|
|
|
|
### Domain Metadata Claims {#domain-claims}
|
|
|
|
The following claims support cross-domain workflows:
|
|
|
|
domain:
|
|
: OPTIONAL. String. The trust domain in which the agent
|
|
operates. This is a DNS-compatible identifier (e.g.,
|
|
"bank.example.com", "hospital.example.org"). When present,
|
|
enables auditors to determine which regulatory regime governs
|
|
this segment of the DAG.
|
|
|
|
eat_reg:
|
|
: OPTIONAL. Object. Regulatory profile metadata for this EAT.
|
|
See {{regulatory-profiles}} for the structure and semantics.
|
|
|
|
ledger_receipt:
|
|
: OPTIONAL. Object. A signed receipt from the domain's audit
|
|
ledger, enabling cross-domain verification. See
|
|
{{federated-ledger}} for the structure and semantics. This
|
|
claim is populated by the ledger upon recording, not by the
|
|
producing agent.
|
|
|
|
### Extension Claims {#extension-claims}
|
|
|
|
eat_ext:
|
|
: OPTIONAL. Object. A general-purpose extension object for
|
|
domain-specific claims not defined by this specification.
|
|
Implementations that do not understand extension claims MUST
|
|
ignore them. Extension key names SHOULD use reverse domain
|
|
notation (e.g., "com.example.custom_field") to avoid
|
|
collisions. The serialized "eat_ext" object MUST NOT exceed
|
|
4096 bytes and MUST NOT exceed a nesting depth of 5 levels.
|
|
Receivers MUST reject EATs whose "eat_ext" object exceeds these
|
|
limits.
|
|
|
|
## Complete EAT Payload Example
|
|
|
|
The following is a complete EAT payload example showing a
|
|
cross-domain task with regulatory metadata. This payload
|
|
structure is the same at all assurance levels; only the transport
|
|
envelope differs.
|
|
|
|
~~~json
|
|
{
|
|
"iss": "https://agents.bank.example.com/compliance-agent",
|
|
"aud": ["https://agents.partner.example.com/rating-agent",
|
|
"https://ledger.bank.example.com"],
|
|
"iat": 1772064150,
|
|
"exp": 1772064750,
|
|
"jti": "550e8400-e29b-41d4-a716-446655440001",
|
|
|
|
"wid": "a0b1c2d3-e4f5-6789-abcd-ef0123456789",
|
|
"exec_act": "verify_trade_compliance",
|
|
"pred": ["550e8400-e29b-41d4-a716-446655440000"],
|
|
"actor_type": "agent",
|
|
|
|
"domain": "bank.example.com",
|
|
"eat_reg": {
|
|
"profiles": ["urn:ietf:eat:reg:eu-dora",
|
|
"urn:ietf:eat:reg:eu-ai-act"],
|
|
"retention_days": 2555,
|
|
"jurisdiction": "EU"
|
|
},
|
|
|
|
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
|
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
|
|
|
"eat_ext": {
|
|
"com.example.trace_id": "abc123"
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-full-eat title="Complete EAT Payload Example"}
|
|
|
|
## Level 1: Unsigned JSON {#level-1}
|
|
|
|
At Level 1, an EAT is a plain JSON object carrying the payload
|
|
defined in {{eat-payload}}. No cryptographic signature is applied.
|
|
|
|
### L1 Transport {#l1-transport}
|
|
|
|
L1 EATs are transported as base64url-encoded JSON (without
|
|
padding). Two mechanisms are defined:
|
|
|
|
HTTP Header:
|
|
: The Execution-Context header field ({{http-header}}) carries
|
|
the base64url-encoded JSON payload (without padding). The
|
|
header value is NOT raw JSON; the receiver MUST base64url-decode
|
|
the value before parsing.
|
|
|
|
HTTP Body:
|
|
: When the EAT is the primary request payload, the EAT MAY be
|
|
carried in the HTTP request body with Content-Type
|
|
`application/json`.
|
|
|
|
L1 EATs MUST be transmitted over TLS or mTLS connections.
|
|
Transport security is the sole integrity mechanism at this level.
|
|
|
|
### L1 Verification {#l1-verification}
|
|
|
|
When an agent receives an L1 EAT, it MUST perform the following
|
|
verification steps:
|
|
|
|
1. Parse the JSON object.
|
|
|
|
2. Verify that all required claims ("jti", "iat", "exp",
|
|
"exec_act", "pred") are present and well-formed.
|
|
|
|
3. Verify that the "jti" has not been previously seen within the
|
|
expiration window, consistent with the replay detection
|
|
requirement in {{exec-claims}}.
|
|
|
|
4. Verify the "exp" claim indicates the EAT has not expired.
|
|
|
|
5. Verify the "iat" claim is not unreasonably far in the past
|
|
(RECOMMENDED maximum: 15 minutes) and is not unreasonably
|
|
far in the future (RECOMMENDED: no more than 30 seconds
|
|
ahead of the verifier's current time).
|
|
|
|
6. Perform DAG validation per {{dag-validation}}.
|
|
|
|
If any verification step fails, the EAT MUST be rejected and the
|
|
failure MUST be logged.
|
|
|
|
### L1 Security Properties and Applicability {#l1-security}
|
|
|
|
L1 provides the following security properties:
|
|
|
|
- Structural integrity via JSON schema validation
|
|
- Temporal ordering via "iat" and "exp" claims
|
|
- DAG integrity via parent reference validation
|
|
- Transport integrity via TLS
|
|
|
|
L1 does NOT provide:
|
|
|
|
- Non-repudiation (no signature binds the EAT to its issuer)
|
|
- Tamper detection after delivery (the recipient cannot prove
|
|
the EAT was not modified after receipt)
|
|
- Issuer authentication at the EAT layer (identity depends
|
|
entirely on the transport layer)
|
|
|
|
Note: At L1, without a deployed audit ledger, DAG parent
|
|
existence validation ({{dag-validation}} step 2) is limited to
|
|
parent EATs received inline with the current request. Parents
|
|
from prior requests that were not forwarded inline cannot be
|
|
verified.
|
|
|
|
L1 MUST NOT be used across trust domain boundaries.
|
|
Deployments using L1 SHOULD restrict it to internal environments
|
|
where all agents are operated by the same organization and
|
|
transport security is considered sufficient.
|
|
|
|
## Level 2: JOSE Asymmetric Signing {#level-2}
|
|
|
|
At Level 2, an EAT is a JSON Web Token (JWT) {{RFC7519}} signed
|
|
as a JSON Web Signature (JWS) {{RFC7515}}.
|
|
|
|
EATs MUST use JWS Compact Serialization (the base64url-encoded
|
|
`header.payload.signature` format) so that they can be carried in
|
|
a single HTTP header value.
|
|
|
|
The EAT MUST be signed with a private key that is verifiably
|
|
bound to the agent's identity credential (see
|
|
{{identity-binding}}). The JOSE header "kid" parameter MUST
|
|
reference the public key identifier from the agent's identity
|
|
credential, and the "alg" parameter MUST match the algorithm
|
|
associated with that credential.
|
|
|
|
### L2 JOSE Header {#jose-header}
|
|
|
|
The EAT JOSE header MUST contain the following parameters:
|
|
|
|
~~~json
|
|
{
|
|
"alg": "ES256",
|
|
"typ": "eat+jwt",
|
|
"kid": "agent-a-key-id-123"
|
|
}
|
|
~~~
|
|
{: #fig-header title="EAT JOSE Header Example"}
|
|
|
|
alg:
|
|
: REQUIRED. The digital signature algorithm used to sign the EAT.
|
|
MUST match the algorithm associated with the agent's identity
|
|
credential. Implementations MUST support ES256 {{RFC7518}}.
|
|
The "alg" value MUST NOT be "none". Symmetric algorithms
|
|
(e.g., HS256, HS384, HS512) MUST NOT be used, as EATs require
|
|
asymmetric signatures for non-repudiation. To support algorithm
|
|
agility, deployments SHOULD maintain an allowlist of accepted
|
|
signing algorithms and SHOULD plan for migration to stronger
|
|
algorithms as cryptographic requirements evolve.
|
|
|
|
typ:
|
|
: REQUIRED. MUST be set to "eat+jwt" to distinguish EATs from
|
|
other JWT types.
|
|
|
|
kid:
|
|
: REQUIRED. The key identifier referencing the public key from
|
|
the agent's identity credential {{RFC7517}}. Used by verifiers
|
|
to look up the correct public key for signature verification.
|
|
|
|
### L2 Transport {#l2-transport}
|
|
|
|
L2 EATs are transported in the Execution-Context HTTP header
|
|
field ({{http-header}}) as JWS Compact Serialization. The header
|
|
field value consists of three Base64url-encoded parts separated by
|
|
period (".") characters.
|
|
|
|
L2 EATs MUST be transmitted over TLS or mTLS connections.
|
|
|
|
### L2 Verification {#l2-verification}
|
|
|
|
When an agent receives an L2 EAT, it MUST perform the following
|
|
verification steps in order:
|
|
|
|
1. Parse the JWS Compact Serialization to extract the JOSE header,
|
|
payload, and signature components per {{RFC7515}}.
|
|
|
|
2. Verify that the "typ" header parameter is "eat+jwt".
|
|
|
|
3. Verify that the "alg" header parameter appears in the
|
|
verifier's configured allowlist of accepted signing algorithms.
|
|
The allowlist MUST NOT include "none" or any symmetric
|
|
algorithm (e.g., HS256, HS384, HS512). Implementations MUST
|
|
include ES256 in the allowlist; additional asymmetric algorithms
|
|
MAY be included per deployment policy.
|
|
|
|
4. Verify the "kid" header parameter references a known, valid
|
|
public key from an identity credential within the trust domain
|
|
or a federated trust domain (see {{identity-binding}}).
|
|
|
|
5. Retrieve the public key identified by "kid" and verify the JWS
|
|
signature per {{RFC7515}} Section 5.2.
|
|
|
|
6. Verify that the signing key identified by "kid" has not been
|
|
revoked within the trust domain. Implementations MUST check
|
|
the key's revocation status using the identity framework's key
|
|
lifecycle mechanism (e.g., certificate revocation list, OCSP,
|
|
SPIFFE trust bundle updates, JWK set rotation, or DID document
|
|
deactivation).
|
|
|
|
7. Verify the "alg" header parameter matches the algorithm
|
|
associated with the agent's identity credential.
|
|
|
|
8. Verify the "iss" claim is present and matches the agent
|
|
identity asserted by the identity credential associated with
|
|
the "kid" public key (see {{identity-binding}}).
|
|
|
|
9. Verify the "aud" claim is present and contains the verifier's
|
|
own identity. When "aud" is an array, it is sufficient that
|
|
the verifier's identity appears as one element; the presence
|
|
of other audience values does not cause verification failure.
|
|
When the verifier is the audit ledger, the ledger's own
|
|
identity MUST appear in "aud".
|
|
|
|
10. Verify the "exp" claim indicates the EAT has not expired.
|
|
|
|
11. Verify the "iat" claim is not unreasonably far in the past
|
|
(implementation-specific threshold, RECOMMENDED maximum of
|
|
15 minutes) and is not unreasonably far in the future
|
|
(RECOMMENDED: no more than 30 seconds ahead of the
|
|
verifier's current time, to account for clock skew).
|
|
|
|
12. Verify all required claims ("jti", "exec_act", "pred") are
|
|
present and well-formed.
|
|
|
|
13. If "actor_type" is present, verify it contains a recognized
|
|
value ("agent", "human", or "system").
|
|
|
|
14. If "eat_reg" is present, verify the regulatory profile
|
|
structure per {{regulatory-profiles}}.
|
|
|
|
15. Perform DAG validation per {{dag-validation}}.
|
|
|
|
16. If all checks pass and an audit ledger is deployed, the EAT
|
|
SHOULD be appended to the ledger.
|
|
|
|
If any verification step fails, the EAT MUST be rejected and the
|
|
failure MUST be logged for audit purposes. Error messages
|
|
SHOULD NOT reveal whether specific parent task IDs exist in the
|
|
EAT store, to prevent information disclosure.
|
|
|
|
### L2 Security Properties and Applicability {#l2-security}
|
|
|
|
L2 provides the following security properties:
|
|
|
|
- Non-repudiation (the EAT is cryptographically bound to the
|
|
issuing agent via asymmetric signature)
|
|
- Tamper detection (any modification invalidates the signature)
|
|
- Issuer authentication (the "kid" links to the agent's identity
|
|
credential)
|
|
- Audience restriction (the "aud" claim limits valid verifiers)
|
|
- All L1 properties (structural, temporal, DAG, transport
|
|
integrity)
|
|
|
|
L2 is suitable for cross-organization deployments, peer-to-peer
|
|
agent communication, and any deployment requiring cryptographic
|
|
non-repudiation. L2 is the RECOMMENDED default for production
|
|
deployments.
|
|
|
|
## Level 3: JOSE Signing with Audit Ledger {#level-3}
|
|
|
|
Level 3 extends Level 2 by requiring that every EAT be recorded
|
|
in an audit ledger that provides cryptographic commitment. L3
|
|
transport and JWS signing are identical to L2; the additional
|
|
requirements apply to ledger recording and verification.
|
|
|
|
### L3 Transport {#l3-transport}
|
|
|
|
L3 EATs use the same JWS Compact Serialization transport as L2
|
|
(see {{l2-transport}}).
|
|
|
|
### L3 Audit Ledger Requirements {#l3-ledger}
|
|
|
|
At Level 3, the audit ledger MUST satisfy the baseline
|
|
requirements defined in {{ledger-interface}} and the following
|
|
additional requirements:
|
|
|
|
1. Hash Chain: Each ledger entry MUST include a cryptographic
|
|
hash of the previous entry, forming a hash chain. The hash
|
|
algorithm MUST be SHA-256 or stronger.
|
|
|
|
2. Cryptographic Commitment: The ledger MUST provide a
|
|
mechanism for verifiable cryptographic commitment over its
|
|
entries, such as Merkle tree proofs, hash chains with signed
|
|
roots, or equivalent constructions. The commitment MUST
|
|
allow a verifier to confirm that a specific EAT is included
|
|
in the ledger at a specific position without trusting the
|
|
ledger operator.
|
|
|
|
3. Receipts: Upon successful append, the ledger MUST return a
|
|
receipt to the submitting agent. The receipt MUST contain
|
|
the ledger sequence number, the hash of the appended EAT
|
|
entry, and the cryptographic commitment proof (e.g., Merkle
|
|
inclusion proof) at the time of recording.
|
|
|
|
4. Availability: The ledger MUST be accessible for verification
|
|
queries by authorized entities within the trust domain.
|
|
|
|
### L3 Recording Semantics {#l3-recording}
|
|
|
|
An agent producing an L3 EAT MUST attempt to record the EAT in
|
|
the audit ledger. Two recording modes are defined:
|
|
|
|
Synchronous Recording:
|
|
: The agent submits the EAT to the ledger and waits for a receipt
|
|
before transmitting the EAT to the next agent. Synchronous
|
|
recording provides the strongest guarantee: the EAT is
|
|
committed to the ledger before any downstream processing
|
|
occurs.
|
|
|
|
Asynchronous Recording:
|
|
: The agent submits the EAT to the ledger and transmits the EAT
|
|
to the next agent without waiting for a receipt. The agent
|
|
MUST subsequently verify that the ledger accepted the EAT and
|
|
MUST retain the receipt. If the ledger rejects the EAT, the
|
|
agent MUST alert the workflow coordinator or log a critical
|
|
error. If asynchronous ledger recording fails, the producing
|
|
agent MUST notify downstream agents that the EAT's L3 status
|
|
is unconfirmed. Downstream agents SHOULD treat such an EAT as
|
|
L2-verified (not L3-verified) until ledger confirmation is
|
|
independently obtainable.
|
|
|
|
Deployments SHOULD use synchronous recording unless latency
|
|
constraints make it impractical. The recording mode SHOULD be
|
|
documented in the deployment's security policy.
|
|
|
|
### L3 Verification {#l3-verification}
|
|
|
|
L3 verification consists of L2 verification ({{l2-verification}})
|
|
followed by ledger verification:
|
|
|
|
Note: The "iss" and "aud" claims, which are RECOMMENDED at L1
|
|
and verified at L2 (steps 8-9 of {{l2-verification}}), are
|
|
REQUIRED at L3.
|
|
|
|
1. Perform all L2 verification steps (steps 1 through 16 of
|
|
{{l2-verification}}).
|
|
|
|
2. Verify that the EAT has been recorded in the audit ledger by
|
|
querying the ledger for the EAT's "jti". If the EAT is
|
|
found, verify that the ledger entry's receipt contains a
|
|
valid sequence number, EAT hash, and cryptographic commitment
|
|
proof. Note: the producing agent is responsible for recording
|
|
the EAT per {{l3-recording}}; the verifier checks that
|
|
recording has occurred.
|
|
|
|
3. If the EAT is not yet present in the ledger (e.g., due to
|
|
asynchronous recording), the verifier MAY retry after a
|
|
short delay. If the ledger does not contain the EAT within
|
|
the configured timeout, the verifier MUST either reject the
|
|
EAT or downgrade to L2 verification per deployment policy.
|
|
|
|
4. If the ledger is unavailable, the verifier SHOULD retry with
|
|
exponential backoff. If the ledger remains unavailable after
|
|
a deployment-configured number of retries, the verifier MUST
|
|
either reject the EAT or downgrade to L2 verification per
|
|
deployment policy.
|
|
|
|
If any L3-specific verification step fails, the EAT MUST be
|
|
rejected even if L2 verification succeeded.
|
|
|
|
### L3 Security Properties and Applicability {#l3-security}
|
|
|
|
L3 provides the following security properties beyond L2:
|
|
|
|
- Tamper-evident history (the hash chain detects any
|
|
modification, insertion, or deletion of ledger entries)
|
|
- Cryptographic commitment (Merkle proofs or equivalent allow
|
|
independent verification of ledger inclusion)
|
|
- Non-repudiation of recording (the receipt proves the EAT was
|
|
committed at a specific time and position)
|
|
- All L2 properties
|
|
|
|
L3 is intended for regulated environments requiring auditable,
|
|
tamper-evident execution records, such as healthcare (FDA 21 CFR
|
|
Part 11), financial services (MiFID II, DORA {{EU-DORA}}), and
|
|
environments subject to the EU AI Act {{EU-AI-ACT}}.
|
|
|
|
## Level Selection {#level-selection}
|
|
|
|
Deployments SHOULD select the assurance level based on the
|
|
following criteria:
|
|
|
|
- Use L1 when all agents operate within a single trust domain,
|
|
non-repudiation is not required, and transport security (TLS)
|
|
is considered sufficient. Typical environments: development,
|
|
testing, internal microservice meshes.
|
|
|
|
- Use L2 when agents cross trust domain boundaries, when
|
|
non-repudiation is required, or when agents communicate
|
|
peer-to-peer across organizations. L2 is the RECOMMENDED
|
|
default for production deployments.
|
|
|
|
- Use L3 when regulatory requirements mandate tamper-evident
|
|
audit trails with cryptographic commitment, or when the
|
|
deployment needs to demonstrate compliance with regulatory
|
|
frameworks.
|
|
|
|
A deployment MAY use different assurance levels for different
|
|
workflows within the same infrastructure. When agents at
|
|
different levels interact, the higher level's verification
|
|
requirements apply to the receiving agent. Specifically, an
|
|
EAT at a higher assurance level MAY reference parent EATs at a
|
|
lower assurance level in its "pred" claim. In this case, the
|
|
receiving agent applies its own level's verification to the
|
|
current EAT and the parent's level verification to each parent
|
|
EAT. Whether cross-level parent references are permitted is a
|
|
deployment policy decision; deployments MAY reject EATs whose
|
|
parents are below a minimum assurance level.
|
|
|
|
This specification does not define a level negotiation mechanism.
|
|
Deployments configure the required assurance level out of band.
|
|
A future extension MAY define in-band level signaling.
|
|
|
|
### Assurance Level Transitions at Domain Boundaries {#level-transitions}
|
|
|
|
When a workflow crosses a domain boundary, the required assurance
|
|
level may change. For example, an internal workflow segment may
|
|
use L1 within an organization, but L2 is required when crossing
|
|
to an external partner, and L3 is required when entering a
|
|
regulated jurisdiction.
|
|
|
|
Deployments SHOULD document their assurance level policy for
|
|
cross-domain interactions. When an EAT crosses a domain boundary
|
|
and the receiving domain requires a higher assurance level than
|
|
the sending domain:
|
|
|
|
- The receiving agent MUST produce its own EAT at the required
|
|
level, referencing the sender's EAT in "pred".
|
|
|
|
- The receiving agent MAY verify the sender's EAT at the
|
|
sender's assurance level, provided that level meets the
|
|
receiver's minimum acceptable level for parent EATs.
|
|
|
|
- If the sender's assurance level is below the receiver's
|
|
minimum for parent EATs, the receiver MUST reject the EAT.
|
|
|
|
## Backward Compatibility and Level Detection {#level-detection}
|
|
|
|
A verifier determines the assurance level of a received EAT as
|
|
follows:
|
|
|
|
1. If the raw Execution-Context header value (or body content)
|
|
contains exactly two period (".") characters separating three
|
|
non-empty segments, attempt to parse the value as JWS Compact
|
|
Serialization. If the first segment base64url-decodes to a
|
|
JSON object containing an "alg" field, the EAT is L2 or L3.
|
|
|
|
2. Otherwise, base64url-decode the header value (without padding)
|
|
and attempt to parse the result as JSON. If successful, the
|
|
EAT is L1.
|
|
|
|
3. If neither parse succeeds, the EAT MUST be rejected.
|
|
|
|
L2 and L3 use the same JWS format. Differentiation between
|
|
L2 and L3 is a matter of deployment policy: L3 deployments
|
|
require ledger recording ({{l3-ledger}}), while L2
|
|
deployments treat ledger recording as optional.
|
|
|
|
## Identity Binding {#identity-binding}
|
|
|
|
At L2 and L3, the EAT signing key MUST be verifiably bound to the
|
|
agent's identity. This specification defines the abstract
|
|
requirements for identity binding; concrete bindings are
|
|
defined for specific identity frameworks.
|
|
|
|
An identity binding MUST satisfy the following requirements:
|
|
|
|
1. Key Association: The "kid" value in the EAT JOSE header MUST
|
|
resolve to a public key through the identity framework's key
|
|
discovery mechanism.
|
|
|
|
2. Issuer Correspondence: The "iss" claim in the EAT payload
|
|
MUST correspond to the agent identity asserted by the identity
|
|
credential containing the "kid" public key.
|
|
|
|
3. Algorithm Consistency: The "alg" value in the EAT JOSE header
|
|
MUST match the algorithm associated with the identity
|
|
credential.
|
|
|
|
4. Revocation Checking: The verifier MUST be able to determine
|
|
whether the signing key has been revoked using the identity
|
|
framework's revocation mechanism.
|
|
|
|
### Cross-Domain Identity Resolution {#cross-domain-identity}
|
|
|
|
When an EAT crosses a domain boundary, the receiving domain may
|
|
use a different identity framework than the sending domain. For
|
|
cross-domain verification:
|
|
|
|
1. The receiving domain MUST be able to obtain the sender's
|
|
public key through a pre-established federation mechanism
|
|
(e.g., shared JWK set endpoint, cross-certified X.509
|
|
hierarchy, bilateral trust bundle exchange).
|
|
|
|
2. The "iss" claim's URI scheme indicates the identity framework
|
|
in use. The receiving domain MUST support verification of
|
|
the identity framework indicated by the "iss" URI scheme, or
|
|
MUST reject the EAT.
|
|
|
|
3. Deployments SHOULD document which identity frameworks are
|
|
accepted at each domain boundary and how cross-domain key
|
|
discovery is configured.
|
|
|
|
### X.509 Binding {#x509-binding}
|
|
|
|
When the deployment uses X.509 certificates:
|
|
|
|
- The EAT "kid" MAY be the certificate thumbprint (x5t) or
|
|
subject key identifier.
|
|
- The EAT "iss" SHOULD be a URI derived from the certificate
|
|
subject or subject alternative name.
|
|
- Revocation is checked via CRL or OCSP.
|
|
|
|
### OAuth Binding {#oauth-binding}
|
|
|
|
When the deployment uses OAuth 2.0 credentials:
|
|
|
|
- The EAT "kid" MUST match the "kid" parameter in the
|
|
authorization server's published JWK set.
|
|
- The EAT "iss" SHOULD be the OAuth client identifier as a URI.
|
|
- Revocation is checked via token introspection or JWK set
|
|
rotation.
|
|
|
|
### JWK Set Binding {#jwk-binding}
|
|
|
|
When the deployment uses plain JWK sets {{RFC7517}} with
|
|
out-of-band trust establishment:
|
|
|
|
- The EAT "kid" MUST match the "kid" parameter in a JWK from
|
|
the trusted JWK set.
|
|
- The EAT "iss" MUST match a value associated with the JWK
|
|
through the deployment's configuration.
|
|
- Revocation is handled by removing the key from the published
|
|
JWK set.
|
|
|
|
### DID Binding {#did-binding}
|
|
|
|
When the deployment uses Decentralized Identifiers (DIDs):
|
|
|
|
- The EAT "kid" MUST reference a verification method in the
|
|
DID document.
|
|
- The EAT "iss" MUST be the DID URI.
|
|
- Revocation is checked via DID document deactivation or
|
|
verification method removal.
|
|
|
|
# Cross-Domain Audit Model {#cross-domain}
|
|
|
|
This section defines mechanisms for maintaining verifiable audit
|
|
trails across multiple administrative domains with potentially
|
|
different regulatory requirements.
|
|
|
|
## Regulatory Profiles {#regulatory-profiles}
|
|
|
|
The "eat_reg" claim carries machine-readable metadata about the
|
|
regulatory regime governing an EAT. This enables automated
|
|
compliance checking: an auditor or receiving domain can determine
|
|
what rules apply to a given segment of the DAG without out-of-band
|
|
knowledge.
|
|
|
|
### Regulatory Profile Structure
|
|
|
|
The "eat_reg" claim is a JSON object with the following fields:
|
|
|
|
profiles:
|
|
: REQUIRED (within "eat_reg"). Array of strings. Each string
|
|
is a URI identifying a regulatory profile. This specification
|
|
defines an initial set of profile URIs in {{profile-registry}};
|
|
additional profiles may be registered per {{iana-profiles}}.
|
|
|
|
retention_days:
|
|
: OPTIONAL. Integer. The minimum number of days this EAT and
|
|
its associated audit records MUST be retained. When multiple
|
|
regulatory profiles apply, the value SHOULD be the maximum
|
|
retention period across all applicable profiles.
|
|
|
|
jurisdiction:
|
|
: OPTIONAL. String. An ISO 3166-1 alpha-2 country code or
|
|
regional identifier (e.g., "EU", "US") indicating the
|
|
jurisdiction under which this EAT was produced.
|
|
|
|
redact_policy:
|
|
: OPTIONAL. String. A URI identifying the data minimization
|
|
or redaction policy applicable to this EAT when it crosses
|
|
domain boundaries. See {{selective-disclosure}}.
|
|
|
|
### Regulatory Profile Semantics
|
|
|
|
Each regulatory profile URI defines:
|
|
|
|
- Which EAT claims are REQUIRED vs OPTIONAL under that profile
|
|
- Whether "inp_hash" and "out_hash" are mandatory
|
|
- Whether L3 ledger recording is mandatory
|
|
- Minimum retention periods
|
|
- Whether selective disclosure is permitted or required at
|
|
domain boundaries
|
|
|
|
Deployments MUST ensure that all EATs comply with every profile
|
|
listed in their "eat_reg.profiles" array. When profiles conflict
|
|
(e.g., one requires data retention while another requires data
|
|
deletion), the deployment MUST resolve the conflict per its legal
|
|
counsel and document the resolution.
|
|
|
|
### Example Regulatory Profile Usage
|
|
|
|
An EAT produced in the EU financial sector:
|
|
|
|
~~~json
|
|
{
|
|
"eat_reg": {
|
|
"profiles": [
|
|
"urn:ietf:eat:reg:eu-dora",
|
|
"urn:ietf:eat:reg:eu-ai-act"
|
|
],
|
|
"retention_days": 2555,
|
|
"jurisdiction": "EU"
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-reg-eu title="EU Financial Regulatory Profile"}
|
|
|
|
An EAT produced in the US healthcare sector:
|
|
|
|
~~~json
|
|
{
|
|
"eat_reg": {
|
|
"profiles": [
|
|
"urn:ietf:eat:reg:us-hipaa"
|
|
],
|
|
"retention_days": 2190,
|
|
"jurisdiction": "US",
|
|
"redact_policy": "urn:ietf:eat:redact:hipaa-minimum"
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-reg-us title="US Healthcare Regulatory Profile"}
|
|
|
|
## Federated Audit Ledger Model {#federated-ledger}
|
|
|
|
In cross-domain workflows, each domain operates its own audit
|
|
ledger. The federated ledger model enables end-to-end audit
|
|
verification across domain boundaries without requiring a single
|
|
shared ledger.
|
|
|
|
### Cross-Ledger Anchoring
|
|
|
|
When an EAT crosses a domain boundary, the sending domain's
|
|
ledger produces a signed anchor receipt that the receiving
|
|
domain's ledger can reference. This creates a chain of
|
|
cryptographic commitments across ledgers, analogous to how
|
|
Certificate Transparency logs {{CERTIFICATE-TRANSPARENCY}}
|
|
cross-reference through signed timestamps.
|
|
|
|
The anchor receipt is carried in the "ledger_receipt" claim
|
|
of the EAT:
|
|
|
|
~~~json
|
|
{
|
|
"ledger_receipt": {
|
|
"ledger_id": "https://ledger.bank.example.com",
|
|
"seq": 42,
|
|
"eat_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
|
"commitment": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
|
"timestamp": 1772064200,
|
|
"sig": "MEUCIQDx...signed-by-ledger-key..."
|
|
}
|
|
}
|
|
~~~
|
|
{: #fig-anchor title="Cross-Ledger Anchor Receipt"}
|
|
|
|
ledger_id:
|
|
: REQUIRED (within "ledger_receipt"). String. A URI identifying
|
|
the audit ledger that recorded the EAT.
|
|
|
|
seq:
|
|
: REQUIRED (within "ledger_receipt"). Integer. The sequence
|
|
number of the EAT in the ledger.
|
|
|
|
eat_hash:
|
|
: REQUIRED (within "ledger_receipt"). String. The base64url
|
|
encoding (without padding) of the SHA-256 hash of the recorded
|
|
EAT.
|
|
|
|
commitment:
|
|
: REQUIRED (within "ledger_receipt"). String. The cryptographic
|
|
commitment proof (e.g., Merkle root hash) at the time of
|
|
recording.
|
|
|
|
timestamp:
|
|
: REQUIRED (within "ledger_receipt"). NumericDate. The time at
|
|
which the ledger recorded the EAT.
|
|
|
|
sig:
|
|
: REQUIRED (within "ledger_receipt"). String. The base64url
|
|
encoding of the ledger's signature over the concatenation of
|
|
ledger_id, seq, eat_hash, commitment, and timestamp, using the
|
|
ledger's signing key.
|
|
|
|
### Cross-Ledger Verification
|
|
|
|
When a receiving domain encounters an EAT with a "ledger_receipt"
|
|
from a foreign ledger, it MUST:
|
|
|
|
1. Verify the "sig" field using the foreign ledger's public key,
|
|
obtained through a pre-established trust relationship.
|
|
|
|
2. Verify that the "eat_hash" matches the SHA-256 hash of the
|
|
received EAT.
|
|
|
|
3. Optionally query the foreign ledger to verify the commitment
|
|
proof.
|
|
|
|
4. Record the foreign EAT and its receipt in the local ledger,
|
|
creating a cross-ledger reference.
|
|
|
|
### Ledger Federation Requirements
|
|
|
|
For federated ledger operation:
|
|
|
|
1. Each domain's ledger MUST publish its signing public key at
|
|
a well-known endpoint or through a pre-established key
|
|
exchange mechanism.
|
|
|
|
2. Domains MUST establish bilateral or multilateral trust
|
|
relationships specifying which foreign ledgers are accepted.
|
|
|
|
3. Ledger receipts MUST be verifiable without requiring real-time
|
|
access to the foreign ledger (the receipt is self-contained
|
|
for basic verification).
|
|
|
|
## Selective Disclosure at Domain Boundaries {#selective-disclosure}
|
|
|
|
When an EAT crosses a domain boundary, the receiving domain may
|
|
need to verify the DAG structure without seeing all details from
|
|
the originating domain. This is critical for regulatory
|
|
compliance: a HIPAA-governed EAT should not expose protected
|
|
health information (PHI) to a receiving domain that operates
|
|
under different regulations.
|
|
|
|
### SD-JWT Integration
|
|
|
|
At L2 and L3, deployments MAY use Selective Disclosure JWT
|
|
(SD-JWT) {{SD-JWT}} to enable selective disclosure of EAT claims
|
|
at domain boundaries. When SD-JWT is used:
|
|
|
|
1. The producing agent creates an SD-JWT-based EAT where
|
|
sensitive claims (e.g., "eat_ext", "inp_hash", "out_hash",
|
|
"exec_act" details) are selectively disclosable.
|
|
|
|
2. At the domain boundary, the agent creates a presentation
|
|
that discloses only the claims needed by the receiving
|
|
domain:
|
|
- DAG structure claims ("jti", "pred", "wid") are always
|
|
disclosed
|
|
- "iss" and "aud" are always disclosed for verification
|
|
- "domain" and "eat_reg" are always disclosed for regulatory
|
|
routing
|
|
- Other claims are disclosed only as required by the
|
|
receiving domain's policy
|
|
|
|
3. The receiving domain can verify the EAT's signature and DAG
|
|
position without accessing redacted claims.
|
|
|
|
### Minimum Disclosure Set
|
|
|
|
When selective disclosure is used, the following claims MUST
|
|
always be disclosed (the "minimum disclosure set"):
|
|
|
|
- "jti" (task identity and DAG reference)
|
|
- "iat" and "exp" (temporal validation)
|
|
- "pred" (DAG structure)
|
|
- "iss" (issuer verification)
|
|
- "domain" (regulatory routing, when present)
|
|
- "eat_reg" (regulatory profile, when present)
|
|
- "actor_type" (when present)
|
|
|
|
## Audit Evidence Profiles {#evidence-profiles}
|
|
|
|
An Audit Evidence Profile is a machine-readable specification
|
|
of the EAT claims and verification properties required by a
|
|
particular regulatory framework. Evidence profiles allow
|
|
automated compliance checking: given an EAT, a compliance tool
|
|
can determine whether it satisfies a specific regulatory
|
|
requirement.
|
|
|
|
### Evidence Profile Structure
|
|
|
|
An Audit Evidence Profile specifies:
|
|
|
|
- Profile URI (unique identifier)
|
|
- Required claims (which EAT claims must be present)
|
|
- Required assurance level (minimum L1, L2, or L3)
|
|
- Retention period (minimum days)
|
|
- Ledger requirements (whether L3 ledger is mandatory)
|
|
- Selective disclosure policy (whether disclosure is permitted
|
|
at boundaries, and minimum disclosure set)
|
|
- Hash requirements (whether "inp_hash" and "out_hash" are
|
|
mandatory)
|
|
|
|
### Initial Evidence Profiles {#profile-registry}
|
|
|
|
This specification defines the following initial regulatory
|
|
profile URIs. These profiles are informational and are intended
|
|
to illustrate the framework; deployments MUST verify that these
|
|
profiles meet their actual regulatory obligations.
|
|
|
|
urn:ietf:eat:reg:eu-dora:
|
|
: EU Digital Operational Resilience Act. Minimum assurance
|
|
level: L3. Retention: 2555 days (7 years). "inp_hash" and
|
|
"out_hash": REQUIRED. Ledger: REQUIRED.
|
|
|
|
urn:ietf:eat:reg:eu-ai-act:
|
|
: EU Artificial Intelligence Act. Minimum assurance level: L2.
|
|
Retention: 3650 days (10 years) for high-risk AI systems.
|
|
"inp_hash" and "out_hash": REQUIRED. Ledger: RECOMMENDED.
|
|
"actor_type": REQUIRED.
|
|
|
|
urn:ietf:eat:reg:us-hipaa:
|
|
: US Health Insurance Portability and Accountability Act.
|
|
Minimum assurance level: L2. Retention: 2190 days (6 years).
|
|
Selective disclosure at domain boundaries: REQUIRED for
|
|
PHI-containing extensions.
|
|
|
|
urn:ietf:eat:reg:us-soc2:
|
|
: SOC 2 Type II. Minimum assurance level: L2.
|
|
Retention: 365 days (1 year).
|
|
|
|
urn:ietf:eat:reg:financial-mifid2:
|
|
: MiFID II. Minimum assurance level: L3.
|
|
Retention: 2555 days (7 years). Ledger: REQUIRED.
|
|
|
|
# HTTP Header Transport {#http-header}
|
|
|
|
## Execution-Context Header Field
|
|
|
|
This specification defines the Execution-Context HTTP header field
|
|
{{RFC9110}} for transporting EATs between agents.
|
|
|
|
The format of the header field value depends on the assurance
|
|
level:
|
|
|
|
- At Level 1, the header field value is the base64url-encoded
|
|
JSON payload (without padding).
|
|
|
|
- At Level 2 and Level 3, the header field value is the EAT in
|
|
JWS Compact Serialization format {{RFC7515}}. The value
|
|
consists of three Base64url-encoded parts separated by period
|
|
(".") characters.
|
|
|
|
An agent sending a request to another agent includes the
|
|
Execution-Context header alongside any identity headers required
|
|
by the deployment's identity framework.
|
|
|
|
~~~
|
|
GET /api/safety-check HTTP/1.1
|
|
Host: safety-agent.example.com
|
|
Authorization: Bearer <identity-token>
|
|
Execution-Context: eyJhbGci...EAT...
|
|
~~~
|
|
{: #fig-http-example title="HTTP Request with EAT Header"}
|
|
|
|
When multiple parent tasks contribute context to a single request,
|
|
multiple Execution-Context header field lines MAY be included, each
|
|
carrying a separate EAT. This applies to all assurance levels.
|
|
|
|
When a receiver processes multiple Execution-Context headers, it
|
|
MUST individually verify each EAT per the applicable verification
|
|
procedure ({{l1-verification}}, {{l2-verification}}, or
|
|
{{l3-verification}}). If any single EAT fails verification, the
|
|
receiver MUST reject the entire request. The set of verified
|
|
parent task IDs across all received EATs represents the complete
|
|
set of parent dependencies available for the receiving agent's
|
|
subsequent EAT.
|
|
|
|
## HTTP Error Handling
|
|
|
|
When EAT verification fails during HTTP request processing, the
|
|
receiving agent SHOULD respond with HTTP 403 (Forbidden). This
|
|
applies regardless of whether the failure is due to an invalid
|
|
EAT payload, a signature verification failure, or a missing EAT
|
|
when one is required by deployment policy. HTTP 401
|
|
(Unauthorized) SHOULD NOT be used for EAT failures, as 401
|
|
conventionally indicates that authentication credentials are
|
|
missing or invalid and requires a WWW-Authenticate header per
|
|
{{RFC9110}}. The response body SHOULD include a generic error
|
|
indicator without revealing which specific verification step
|
|
failed. The receiving agent MUST NOT process the requested
|
|
action when EAT verification fails.
|
|
|
|
# DAG Validation {#dag-validation}
|
|
|
|
EATs form a Directed Acyclic Graph (DAG) where each task
|
|
references its parent tasks via the "pred" claim. DAG validation
|
|
is performed against the EAT store — either an audit ledger or
|
|
the set of parent EATs received inline.
|
|
|
|
DAG validation applies regardless of assurance level.
|
|
|
|
When receiving and verifying an EAT, implementations MUST perform
|
|
the following DAG validation steps:
|
|
|
|
1. Task ID Uniqueness: The "jti" claim MUST be unique within the
|
|
applicable scope (the workflow identified by "wid", or the
|
|
entire EAT store if "wid" is absent). If an EAT with the same
|
|
"jti" already exists, the EAT MUST be rejected.
|
|
|
|
2. Parent Existence: Every task identifier listed in the "pred"
|
|
array MUST correspond to a task that is available in the EAT
|
|
store (either previously recorded in the ledger or received
|
|
inline as a verified parent EAT). If any parent task is not
|
|
found, the EAT MUST be rejected.
|
|
|
|
3. Temporal Ordering: The "iat" value of every parent task MUST
|
|
NOT be greater than the "iat" value of the current task plus a
|
|
configurable clock skew tolerance (RECOMMENDED: 30 seconds).
|
|
That is, for each parent: `parent.iat < child.iat +
|
|
clock_skew_tolerance`. The tolerance accounts for clock skew
|
|
between agents; it does not guarantee strict causal ordering
|
|
from timestamps alone. Causal ordering is primarily enforced
|
|
by the DAG structure (parent existence in the EAT store), not by
|
|
timestamps. If any parent task violates this constraint, the
|
|
EAT MUST be rejected.
|
|
|
|
4. Acyclicity: Following the chain of parent references MUST NOT
|
|
lead back to the current EAT's "jti". If a cycle is detected,
|
|
the EAT MUST be rejected. Note: because the Parent Existence
|
|
check (step 2) requires that all parents already exist in the
|
|
EAT store, and an EAT cannot reference itself or a future EAT,
|
|
cycles are prevented by construction. This explicit check
|
|
serves as defense in depth against implementation errors or
|
|
store corruption.
|
|
|
|
5. Domain Consistency: When "domain" is present, parent tasks
|
|
SHOULD belong to the same domain or to a domain with which a
|
|
federation relationship has been established. Cross-domain
|
|
parent references are valid when the domains have a
|
|
pre-established trust relationship.
|
|
|
|
6. Workflow Consistency: When "wid" is present, verifiers SHOULD
|
|
validate that the "wid" of each parent EAT matches the "wid"
|
|
of the current EAT. Cross-workflow parent references (where
|
|
a parent's "wid" differs from the child's "wid") MUST be
|
|
rejected unless explicitly permitted by deployment policy.
|
|
|
|
7. Cross-Workflow Composition: When a task in one workflow depends
|
|
on the output of a task in a different workflow, the dependency
|
|
MAY be expressed as a cross-workflow reference using a composite
|
|
identifier in the "pred" array: `<wid>:<jti>`. Cross-workflow
|
|
references MUST be explicitly enabled by deployment policy and
|
|
are subject to all verification requirements of both the source
|
|
and target workflows.
|
|
|
|
To prevent denial-of-service via extremely deep or wide DAGs,
|
|
implementations SHOULD enforce a maximum ancestor traversal limit
|
|
(RECOMMENDED: 10000 nodes). If the limit is reached before cycle
|
|
detection completes, the EAT SHOULD be rejected.
|
|
|
|
In distributed deployments, a parent EAT may not yet be available
|
|
locally due to replication lag. Implementations MAY defer
|
|
validation to allow parent EATs to arrive, but MUST NOT treat
|
|
the EAT as verified until all parent references are resolved.
|
|
|
|
# Audit Ledger Interface {#ledger-interface}
|
|
|
|
EATs MAY be recorded in an immutable audit ledger for compliance
|
|
verification and post-hoc analysis. A ledger is OPTIONAL for L1
|
|
and L2 deployments but is REQUIRED for L3 deployments. This
|
|
specification does not mandate a specific storage technology.
|
|
Implementations MAY use append-only logs, databases with
|
|
cryptographic commitment schemes, distributed ledgers, or any
|
|
storage mechanism that provides the required properties.
|
|
|
|
## Baseline Ledger Requirements
|
|
|
|
When an audit ledger is deployed, the implementation MUST provide:
|
|
|
|
1. Append-only semantics: Once an EAT is recorded, it MUST NOT be
|
|
modified or deleted.
|
|
|
|
2. Ordering: The ledger MUST maintain a total ordering of EAT
|
|
entries via a monotonically increasing sequence number.
|
|
|
|
3. Lookup by EAT ID: The ledger MUST support efficient retrieval
|
|
of EAT entries by "jti" value.
|
|
|
|
4. Lookup by Workflow ID: The ledger SHOULD support retrieval of
|
|
all EAT entries matching a given "wid" value.
|
|
|
|
5. Integrity verification: The ledger SHOULD provide a mechanism
|
|
to verify that no entries have been tampered with (e.g.,
|
|
hash chains or Merkle trees).
|
|
|
|
The ledger SHOULD be maintained by an entity independent of the
|
|
workflow agents to reduce the risk of collusion.
|
|
|
|
## L3 Ledger Requirements
|
|
|
|
At Level 3, the audit ledger MUST satisfy the baseline
|
|
requirements above and the additional requirements defined in
|
|
{{l3-ledger}}. In particular:
|
|
|
|
- Each entry MUST include a cryptographic hash of the previous
|
|
entry, forming a verifiable hash chain.
|
|
|
|
- The ledger MUST provide cryptographic commitment proofs
|
|
(Merkle tree proofs, signed hash chain roots, or equivalent).
|
|
|
|
- The ledger MUST return a receipt upon successful append,
|
|
containing the sequence number, entry hash, and commitment
|
|
proof.
|
|
|
|
## Ledger Independence
|
|
|
|
The audit ledger SHOULD be operated by an entity that is
|
|
independent of the workflow agents. When the ledger operator and
|
|
the workflow agents are controlled by the same organization,
|
|
additional safeguards SHOULD be implemented, such as separation
|
|
of duties between ledger administrators and agent operators, or
|
|
independent ledger replicas maintained by third parties.
|
|
|
|
## EAT Discovery API {#discovery-api}
|
|
|
|
Deployments SHOULD provide a standardized API for EAT discovery
|
|
and verification. The following endpoints are RECOMMENDED:
|
|
|
|
Lookup by Task ID:
|
|
: `GET /eat/{jti}` — Returns the EAT and its ledger receipt
|
|
(if recorded) for the specified task identifier.
|
|
|
|
Lookup by Workflow ID:
|
|
: `GET /eat?wid={wid}` — Returns all EATs in the specified
|
|
workflow, ordered by ledger sequence number.
|
|
|
|
DAG Retrieval:
|
|
: `GET /eat/{jti}/dag` — Returns the complete DAG rooted at
|
|
the specified task, including all ancestor EATs.
|
|
|
|
Ledger Verification:
|
|
: `GET /ledger/verify?seq={seq}` — Returns the commitment
|
|
proof for the specified ledger sequence number.
|
|
|
|
These endpoints MUST require authentication and MUST enforce
|
|
access control per the deployment's authorization policy.
|
|
|
|
## L3 Ledger Verification
|
|
|
|
Auditors verifying L3 ledger integrity SHOULD perform the
|
|
following checks:
|
|
|
|
1. Verify the hash chain: for each entry, recompute the hash of
|
|
the previous entry and confirm it matches the recorded value.
|
|
|
|
2. Verify the cryptographic commitment: validate Merkle inclusion
|
|
proofs (or equivalent) for a sample or all entries.
|
|
|
|
3. Verify EAT signatures: for each EAT in the ledger, perform
|
|
the L2 verification procedure ({{l2-verification}}) using
|
|
the public keys valid at the time of recording.
|
|
|
|
4. Verify DAG consistency: confirm that all parent references in
|
|
all EATs resolve to valid entries in the ledger.
|
|
|
|
# Security Considerations
|
|
|
|
## Threat Model
|
|
|
|
The threat model considers: (1) a malicious agent that creates
|
|
false EAT claims, (2) an agent whose private key has been
|
|
compromised, (3) a ledger tamperer attempting to modify recorded
|
|
entries, (4) a time manipulator altering timestamps to affect
|
|
perceived ordering, (5) a domain boundary attacker attempting to
|
|
inject, modify, or drop EATs at domain transitions, and (6) a
|
|
regulatory arbitrage attacker claiming false regulatory profiles
|
|
to avoid compliance requirements.
|
|
|
|
## Level-Specific Security Properties {#level-security}
|
|
|
|
### Level 1 {#sec-level-1}
|
|
|
|
L1 provides no cryptographic binding between the EAT and its
|
|
issuer. A compromised or malicious intermediary with access to
|
|
the transport channel can modify L1 EATs without detection after
|
|
delivery. L1 does not provide non-repudiation: the issuer can
|
|
deny having produced an EAT, and the receiver cannot prove
|
|
otherwise.
|
|
|
|
L1 MUST NOT be used across trust domain boundaries. L1 is
|
|
appropriate only when all agents are operated by the same
|
|
organization, the transport channel is fully trusted (e.g.,
|
|
service mesh with mTLS), and the deployment does not require
|
|
non-repudiation or tamper evidence beyond transport security.
|
|
|
|
### Level 2 {#sec-level-2}
|
|
|
|
L2 inherits all security properties of the JWS-based EAT
|
|
mechanism defined in this document. The existing security
|
|
analysis (signature verification, replay prevention, key
|
|
compromise, collusion) applies directly to L2.
|
|
|
|
### Level 3 {#sec-level-3}
|
|
|
|
L3 provides all L2 security properties plus tamper-evident
|
|
history via the audit ledger's hash chain and cryptographic
|
|
commitment. Modifications to ledger entries are detectable
|
|
through hash chain verification. Deletions or insertions are
|
|
detectable through Merkle proof validation.
|
|
|
|
L3 does not prevent a compromised ledger operator from refusing
|
|
to record entries (censorship), but the submitting agent's receipt
|
|
mechanism ({{l3-ledger}}) provides evidence of submission.
|
|
Deployments concerned about ledger censorship SHOULD use multiple
|
|
independent ledger replicas.
|
|
|
|
## Assurance Level Downgrade Attacks
|
|
|
|
The assurance level of an EAT is determined by its format: unsigned
|
|
JSON indicates L1, while a JWS compact serialization indicates L2
|
|
or L3. This format-based detection determines what was sent, not
|
|
what was expected by the verifier.
|
|
|
|
A man-in-the-middle or compromised proxy could strip the JWS
|
|
signature from an L2 or L3 EAT and re-encode the payload as an
|
|
unsigned L1 JSON object. Because the resulting EAT is
|
|
syntactically valid at L1, a verifier that accepts any assurance
|
|
level would process it without detecting the downgrade.
|
|
|
|
Verifiers MUST be configured with a minimum acceptable assurance
|
|
level and MUST reject EATs whose detected level falls below that
|
|
minimum. Format-based level detection alone is insufficient
|
|
without a policy-enforced minimum level requirement.
|
|
|
|
## Cross-Domain Security Considerations {#cross-domain-security}
|
|
|
|
### Domain Boundary Attacks
|
|
|
|
At domain boundaries, additional attack vectors exist:
|
|
|
|
- EAT injection: An attacker at the boundary inserts a fabricated
|
|
EAT into the workflow. Mitigation: L2/L3 signature verification
|
|
prevents injection of unsigned or incorrectly signed EATs.
|
|
|
|
- EAT dropping: An attacker removes an EAT at the boundary,
|
|
breaking the DAG chain. Mitigation: the receiving agent's DAG
|
|
validation (parent existence check) detects missing parents.
|
|
|
|
- Regulatory profile falsification: An agent claims a regulatory
|
|
profile that does not actually apply, to avoid stricter
|
|
compliance requirements. Mitigation: receiving domains SHOULD
|
|
independently verify that the claimed jurisdiction and regulatory
|
|
profiles are consistent with the sending domain's known
|
|
regulatory environment.
|
|
|
|
### Mixed Identity Framework Security
|
|
|
|
When a DAG spans agents using different identity frameworks
|
|
(e.g., X.509 in one domain, OAuth in another), the verifier
|
|
must support multiple key resolution mechanisms. This increases
|
|
the attack surface:
|
|
|
|
- Each identity framework has its own revocation semantics and
|
|
timing. A key revoked in one framework may not be immediately
|
|
detectable through another framework's mechanisms.
|
|
|
|
- Deployments SHOULD maintain a unified revocation status cache
|
|
that aggregates revocation information across all supported
|
|
identity frameworks.
|
|
|
|
### Federated Ledger Security
|
|
|
|
- Split-view attacks: A foreign ledger could present different
|
|
receipts to different verifiers. Mitigation: cross-ledger
|
|
anchoring includes the commitment proof, which can be
|
|
independently verified.
|
|
|
|
- Receipt replay: A valid receipt from one EAT could be attached
|
|
to a different EAT. Mitigation: the "eat_hash" field in the
|
|
receipt binds the receipt to a specific EAT.
|
|
|
|
- Ledger key compromise: If a foreign ledger's signing key is
|
|
compromised, fake receipts can be generated. Mitigation:
|
|
ledger keys SHOULD be stored in HSMs; receipts SHOULD be
|
|
cross-checked against the foreign ledger's published
|
|
commitment history.
|
|
|
|
## Self-Assertion Limitation {#self-assertion-limitation}
|
|
|
|
EATs are self-asserted by the executing agent. The agent claims
|
|
what it did, and this claim is signed with its private key (at L2
|
|
and L3). A compromised or malicious agent could create EATs with
|
|
false claims (e.g., claiming an action was performed when it was
|
|
not).
|
|
|
|
EATs do not independently verify that:
|
|
|
|
- The claimed execution actually occurred as described
|
|
- The input/output hashes correspond to the actual data processed
|
|
- The agent faithfully performed the stated action
|
|
- The claimed regulatory profile is accurate
|
|
|
|
The trustworthiness of EAT claims depends on the trustworthiness
|
|
of the signing agent and the integrity of the broader deployment
|
|
environment. EATs provide a technical mechanism for execution
|
|
recording; they do not by themselves satisfy any specific
|
|
regulatory compliance requirement.
|
|
|
|
## Signature Verification
|
|
|
|
For L2 and L3 deployments, EATs MUST be signed with the agent's
|
|
private key using JWS {{RFC7515}}. The signature algorithm MUST
|
|
match the algorithm associated with the agent's identity
|
|
credential (see {{identity-binding}}). Receivers MUST verify the
|
|
EAT signature against the corresponding public key before
|
|
processing any claims. Receivers MUST verify that the signing key
|
|
has not been revoked within the trust domain (see step 6 in
|
|
{{l2-verification}}).
|
|
|
|
If signature verification fails or if the signing key has been
|
|
revoked, the EAT MUST be rejected entirely and the failure MUST
|
|
be logged.
|
|
|
|
Implementations MUST use established JWS libraries and MUST NOT
|
|
implement custom signature verification. Implementations SHOULD
|
|
follow the JWT security best practices defined in {{RFC8725}}.
|
|
|
|
## Replay Attack Prevention
|
|
|
|
EATs include short expiration times (RECOMMENDED: 5-15 minutes)
|
|
and audience restriction via "aud" to limit replay attacks.
|
|
Implementations MUST maintain a cache of recently-seen "jti"
|
|
values and MUST reject EATs with duplicate "jti" values. For
|
|
L2 and L3, each EAT is cryptographically bound to the issuing
|
|
agent via "kid"; verifiers MUST confirm that "kid" resolves to
|
|
the "iss" agent's key (step 8 in {{l2-verification}}).
|
|
|
|
## Man-in-the-Middle Protection
|
|
|
|
EATs MUST be transmitted over TLS or mTLS connections.
|
|
|
|
## Key Compromise
|
|
|
|
If an agent's private key is compromised, an attacker can forge
|
|
EATs that appear to originate from that agent. Mitigations:
|
|
|
|
- Implementations SHOULD use short-lived keys and rotate them
|
|
frequently.
|
|
- Private keys SHOULD be stored in hardware security modules or
|
|
equivalent secure key storage.
|
|
- Trust domains MUST support rapid key revocation.
|
|
|
|
EATs recorded before key revocation remain valid historical
|
|
records but SHOULD be flagged for audit purposes. New EATs
|
|
MUST NOT reference a parent EAT whose signing key is known to
|
|
be revoked at creation time.
|
|
|
|
## Collusion and DAG Integrity {#collusion-and-false-claims}
|
|
|
|
A single malicious agent cannot forge parent task references
|
|
because DAG validation requires parent tasks to exist in the EAT
|
|
store. However, multiple colluding agents could create a false
|
|
execution history. Additionally, a malicious agent may omit
|
|
actual parent dependencies from "pred" to hide influences on its
|
|
output; because EATs are self-asserted
|
|
({{self-assertion-limitation}}), no mechanism can force complete
|
|
dependency declaration.
|
|
|
|
Mitigations include:
|
|
|
|
- The ledger SHOULD be maintained by an entity independent of the
|
|
workflow agents.
|
|
- Multiple independent ledger replicas can be compared for
|
|
consistency.
|
|
- External auditors can compare the declared DAG against expected
|
|
workflow patterns.
|
|
|
|
## Privilege Escalation via EATs
|
|
|
|
EATs record execution history; they do not convey authorization.
|
|
Verifiers MUST NOT interpret the presence of an EAT, or a
|
|
particular set of parent references in "pred", as an authorization
|
|
grant. Authorization decisions MUST remain with the deployment's
|
|
identity and authorization layer.
|
|
|
|
## Denial of Service
|
|
|
|
Implementations SHOULD apply rate limiting to prevent excessive
|
|
EAT submissions. For L2 and L3, DAG validation SHOULD be
|
|
performed after signature verification to avoid wasting resources
|
|
on unsigned or incorrectly signed tokens. L1 EATs are cheaper
|
|
to validate (no signature verification) but are correspondingly
|
|
easier for an attacker to generate; L1 deployments SHOULD apply
|
|
stricter rate limits to compensate.
|
|
|
|
## Timestamp Accuracy
|
|
|
|
Implementations SHOULD use synchronized time sources (e.g., NTP)
|
|
and SHOULD allow a configurable clock skew tolerance (RECOMMENDED:
|
|
30 seconds). Cross-domain deployments MAY require a
|
|
higher tolerance and SHOULD document the configured value.
|
|
|
|
## EAT Size Constraints
|
|
|
|
Implementations SHOULD limit the "pred" array to a maximum of
|
|
256 entries. See {{extension-claims}} for "eat_ext" size limits.
|
|
|
|
When EATs are transported via HTTP headers, the total encoded
|
|
size of the Execution-Context header value is subject to
|
|
practical limits imposed by HTTP servers and intermediaries.
|
|
Many implementations enforce header size limits of 8 KB or 16 KB.
|
|
Implementations SHOULD ensure that the total size of an EAT
|
|
(including JWS overhead for L2/L3) does not exceed 8 KB when
|
|
transported via HTTP header. EATs that exceed HTTP header size
|
|
limits SHOULD be transported in the HTTP request body instead
|
|
(see {{l1-transport}} and {{l2-transport}}).
|
|
|
|
## Identity Binding Security
|
|
|
|
### JWK Set Binding {#sec-jwk-binding}
|
|
|
|
When identity is bound via JWK Set URI (see {{identity-binding}}),
|
|
there is a time-of-check/time-of-use gap between JWK set
|
|
refreshes. A key that has been removed from the JWK set may still
|
|
be accepted by a verifier whose cached copy has not yet been
|
|
refreshed. Implementations SHOULD refresh JWK sets at
|
|
configurable intervals (RECOMMENDED: no longer than 5 minutes).
|
|
|
|
### X.509 Binding {#sec-x509-binding}
|
|
|
|
When identity is bound via X.509 certificates, revocation checking
|
|
depends on OCSP responder or CRL distribution point availability.
|
|
If the revocation source is unreachable, the verifier needs to decide
|
|
whether to accept or reject the EAT. Implementations SHOULD
|
|
hard-fail for L3 (reject the EAT if revocation status cannot be
|
|
determined), as L3 workflows require the strongest assurance.
|
|
Implementations MAY soft-fail for L2 with logging, accepting the
|
|
EAT but recording the revocation check failure for subsequent
|
|
audit review.
|
|
|
|
## Audit Ledger Threats
|
|
|
|
### Availability
|
|
|
|
If the audit ledger is unavailable in synchronous recording mode
|
|
(see {{l3-ledger}}), all L3 workflows halt because agents cannot
|
|
obtain ledger receipts. Deployments SHOULD implement ledger
|
|
redundancy (e.g., multiple ledger replicas behind a load balancer)
|
|
to prevent the ledger from becoming a single point of failure.
|
|
|
|
### Split-View Attacks
|
|
|
|
A compromised ledger could present different views to different
|
|
verifiers (equivocation), causing inconsistent audit state across
|
|
the deployment. Deployments SHOULD use multiple independent
|
|
ledger replicas and SHOULD periodically compare their state to
|
|
detect divergence.
|
|
|
|
### Receipt Authenticity
|
|
|
|
If the ledger's signing key is compromised, an attacker can
|
|
generate fake receipts for entries that were never recorded.
|
|
Ledger signing keys SHOULD be stored in hardware security modules
|
|
(HSMs) and SHOULD be rotated regularly.
|
|
|
|
### Asynchronous Recording Gap
|
|
|
|
In asynchronous recording mode (see {{l3-ledger}}), downstream
|
|
agents act on EATs before ledger confirmation is received.
|
|
During this gap, an EAT that will ultimately fail ledger recording
|
|
may already have influenced downstream workflow steps. Deployments
|
|
using asynchronous recording SHOULD implement reconciliation
|
|
procedures to detect and handle EATs that fail ledger confirmation
|
|
after downstream processing has begun.
|
|
|
|
# Privacy Considerations
|
|
|
|
## Data Exposure in EATs
|
|
|
|
EATs necessarily reveal:
|
|
|
|
- Agent identities ("iss", "aud") for accountability purposes
|
|
- Action descriptions ("exec_act") for audit trail completeness
|
|
- Timestamps ("iat", "exp") for temporal ordering
|
|
- Domain information ("domain") for regulatory routing
|
|
|
|
EATs are designed to NOT reveal:
|
|
|
|
- Actual input or output data values (replaced with cryptographic
|
|
hashes via "inp_hash" and "out_hash")
|
|
- Internal computation details or intermediate steps
|
|
- Proprietary algorithms or intellectual property
|
|
- Personally identifiable information (PII)
|
|
|
|
Privacy exposure is equivalent across all assurance levels: the
|
|
EAT payload contains the same claims regardless of whether the
|
|
EAT is unsigned (L1), signed (L2), or signed with ledger
|
|
recording (L3). L3 ledger recording increases the durability of
|
|
the privacy-relevant data but does not increase its scope.
|
|
|
|
## Cross-Domain Privacy {#cross-domain-privacy}
|
|
|
|
Cross-domain workflows introduce additional privacy concerns:
|
|
|
|
- Workflow topology leakage: The DAG structure reveals which
|
|
agents interact across domains, potentially exposing
|
|
organizational relationships or business processes.
|
|
|
|
- Regulatory conflicts: GDPR's data minimization requirements
|
|
may conflict with another jurisdiction's audit trail
|
|
completeness requirements. The selective disclosure mechanism
|
|
({{selective-disclosure}}) helps resolve this tension.
|
|
|
|
- Jurisdiction hopping: EATs that cross multiple jurisdictions
|
|
accumulate metadata. Deployments SHOULD use selective disclosure
|
|
to minimize cross-jurisdictional data exposure.
|
|
|
|
## Data Minimization {#data-minimization}
|
|
|
|
Implementations SHOULD minimize the information included in EATs.
|
|
The "exec_act" claim SHOULD use structured identifiers (e.g.,
|
|
"process_payment") rather than natural language descriptions.
|
|
Extension keys in "eat_ext" ({{extension-claims}}) deserve
|
|
particular attention: human-readable values risk exposing
|
|
sensitive operational details.
|
|
|
|
## Storage and Access Control
|
|
|
|
EATs stored in audit ledgers SHOULD be access-controlled so that
|
|
only authorized auditors can read them. Implementations SHOULD
|
|
consider encryption at rest for ledger storage. EATs provide
|
|
structural records of execution ordering; they are not intended
|
|
for public disclosure.
|
|
|
|
Full input and output data (corresponding to the hashes in EATs)
|
|
SHOULD be stored separately from the ledger with additional access
|
|
controls, since auditors may need to verify hash correctness but
|
|
general access to the data values is not needed.
|
|
|
|
## Workflow Topology Leakage
|
|
|
|
The DAG structure of EATs reveals workflow topology: which agents
|
|
interact, fan-out and fan-in patterns, sequential versus parallel
|
|
execution, and organizational structure. At L3, this topology is
|
|
permanently recorded in the audit ledger. Deployments SHOULD
|
|
consider whether workflow topology constitutes sensitive
|
|
information and apply appropriate access controls to EAT stores
|
|
and ledgers.
|
|
|
|
## Cross-Workflow Correlation
|
|
|
|
Stable agent identifiers in the "iss" claim enable cross-workflow
|
|
activity correlation: an observer with access to EATs from
|
|
multiple workflows can track which agents participate in which
|
|
workflows and how frequently. Deployments with privacy
|
|
requirements MAY use per-workflow or rotating agent identifiers
|
|
where feasible to limit cross-workflow correlation.
|
|
|
|
# IANA Considerations
|
|
|
|
## Media Type Registration
|
|
|
|
This document requests registration of the following media type
|
|
in the "Media Types" registry maintained by IANA:
|
|
|
|
Note: The media type "application/eat+jwt" uses the "+jwt"
|
|
structured syntax suffix. While "+jwt" is widely used in
|
|
practice, it is not yet a formally registered structured syntax
|
|
suffix per {{RFC6838}}. Registration of the "+jwt" suffix is
|
|
the subject of ongoing work in the IETF.
|
|
|
|
### application/eat+jwt
|
|
|
|
Type name:
|
|
: application
|
|
|
|
Subtype name:
|
|
: eat+jwt
|
|
|
|
Required parameters:
|
|
: none
|
|
|
|
Optional parameters:
|
|
: none
|
|
|
|
Encoding considerations:
|
|
: 8bit; at Level 2 and Level 3, an EAT is a JWT that is a JWS
|
|
using the Compact Serialization, which is a sequence of
|
|
Base64url-encoded values separated by period characters. At
|
|
Level 1, this media type is not used; L1 EATs use
|
|
application/json.
|
|
|
|
Security considerations:
|
|
: See the Security Considerations section of this document.
|
|
|
|
Interoperability considerations:
|
|
: none
|
|
|
|
Published specification:
|
|
: This document
|
|
|
|
Applications that use this media type:
|
|
: Applications that implement agentic workflows requiring
|
|
cross-domain execution audit trails.
|
|
|
|
Additional information:
|
|
: Magic number(s): none
|
|
File extension(s): none
|
|
Macintosh file type code(s): none
|
|
|
|
Person and email address to contact for further information:
|
|
: Christian Nennemann, ietf@nennemann.de
|
|
|
|
Intended usage:
|
|
: COMMON
|
|
|
|
Restrictions on usage:
|
|
: none
|
|
|
|
Author:
|
|
: Christian Nennemann
|
|
|
|
Change controller:
|
|
: IETF
|
|
|
|
## HTTP Header Field Registration {#header-registration}
|
|
|
|
This document requests registration of the following header field
|
|
in the "Hypertext Transfer Protocol (HTTP) Field Name Registry"
|
|
maintained by IANA:
|
|
|
|
Field name:
|
|
: Execution-Context
|
|
|
|
Status:
|
|
: permanent
|
|
|
|
Specification document:
|
|
: This document, {{http-header}}
|
|
|
|
## JWT Claims Registration {#claims-registration}
|
|
|
|
This document requests registration of the following claims in
|
|
the "JSON Web Token Claims" registry maintained by IANA:
|
|
|
|
| Claim Name | Claim Description | Change Controller | Reference |
|
|
|:---:|:---|:---:|:---:|
|
|
| wid | Workflow Identifier | IETF | {{exec-claims}} |
|
|
| exec_act | Action/Task Type | IETF | {{exec-claims}} |
|
|
| pred | Predecessor Task Identifiers | IETF | {{exec-claims}} |
|
|
| actor_type | Actor Type | IETF | {{actor-type-claim}} |
|
|
| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} |
|
|
| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} |
|
|
| domain | Trust Domain Identifier | IETF | {{domain-claims}} |
|
|
| eat_reg | Regulatory Profile Metadata | IETF | {{domain-claims}} |
|
|
| ledger_receipt | Audit Ledger Receipt | IETF | {{domain-claims}} |
|
|
| eat_ext | Extension Object | IETF | {{extension-claims}} |
|
|
{: #table-claims title="JWT Claims Registrations"}
|
|
|
|
## Regulatory Profile Registry {#iana-profiles}
|
|
|
|
This document establishes a new "EAT Regulatory Profiles" registry
|
|
under the "JSON Web Token (JWT)" group. Registration policy is
|
|
Specification Required per RFC 8126.
|
|
|
|
Each registration includes:
|
|
|
|
- Profile URI (e.g., "urn:ietf:eat:reg:eu-dora")
|
|
- Description
|
|
- Required EAT claims
|
|
- Minimum assurance level
|
|
- Reference document
|
|
|
|
Initial registrations are defined in {{profile-registry}}.
|
|
|
|
--- back
|
|
|
|
# Use Cases {#use-cases}
|
|
{:numbered="false"}
|
|
|
|
This section describes representative use cases demonstrating how
|
|
EATs provide structured execution records across multiple domains
|
|
with different regulatory requirements.
|
|
|
|
Note: task identifiers in this section are abbreviated for
|
|
readability. In production, all "jti" values are required to be
|
|
UUIDs per {{exec-claims}}.
|
|
|
|
## Cross-Jurisdiction Financial Trading (L3)
|
|
{:numbered="false"}
|
|
|
|
An investment bank in Frankfurt coordinates with a credit rating
|
|
agency in New York. The bank operates under DORA and MiFID II;
|
|
the rating agency operates under US SOC 2. The DAG spans both
|
|
jurisdictions with different regulatory profiles.
|
|
|
|
~~~
|
|
Domain: bank.example.com (EU, DORA + MiFID II)
|
|
Agent A1 (Portfolio Risk):
|
|
jti: task-001 pred:[]
|
|
iss: https://agents.bank.example.com/risk
|
|
exec_act: analyze_portfolio_risk
|
|
domain: bank.example.com
|
|
eat_reg: {profiles: ["urn:ietf:eat:reg:eu-dora",
|
|
"urn:ietf:eat:reg:financial-mifid2"],
|
|
retention_days: 2555, jurisdiction: "EU"}
|
|
|
|
Domain: ratings.example.com (US, SOC 2)
|
|
Agent B1 (Credit Rating):
|
|
jti: task-002 pred:[]
|
|
iss: https://agents.ratings.example.com/credit
|
|
exec_act: assess_credit_rating
|
|
domain: ratings.example.com
|
|
eat_reg: {profiles: ["urn:ietf:eat:reg:us-soc2"],
|
|
retention_days: 365, jurisdiction: "US"}
|
|
|
|
Domain: bank.example.com (EU)
|
|
Agent A2 (Compliance):
|
|
jti: task-003 pred:[task-001, task-002]
|
|
iss: https://agents.bank.example.com/compliance
|
|
exec_act: verify_trade_compliance
|
|
domain: bank.example.com
|
|
eat_reg: {profiles: ["urn:ietf:eat:reg:eu-dora"],
|
|
retention_days: 2555, jurisdiction: "EU"}
|
|
|
|
Agent A3 (Execution):
|
|
jti: task-004 pred:[task-003]
|
|
iss: https://agents.bank.example.com/execution
|
|
exec_act: execute_trade
|
|
~~~
|
|
{: #fig-finance title="Cross-Jurisdiction Trading (L3)"}
|
|
|
|
The resulting DAG:
|
|
|
|
~~~
|
|
task-001 (analyze_portfolio_risk) task-002 (assess_credit_rating)
|
|
[bank.example.com, EU] [ratings.example.com, US]
|
|
\ /
|
|
v v
|
|
task-003 (verify_trade_compliance)
|
|
[bank.example.com, EU]
|
|
|
|
|
v
|
|
task-004 (execute_trade)
|
|
[bank.example.com, EU]
|
|
~~~
|
|
{: #fig-finance-dag title="Cross-Jurisdiction DAG"}
|
|
|
|
Task 002 from the US domain carries a ledger_receipt from the
|
|
US ledger. When task 003 in the EU domain references task 002
|
|
as a parent, the EU ledger records the cross-ledger anchor,
|
|
creating an end-to-end verifiable audit trail across both
|
|
jurisdictions.
|
|
|
|
## Healthcare Agent Pipeline with HITL (L2/L3)
|
|
{:numbered="false"}
|
|
|
|
A clinical AI agent recommends a treatment plan that requires
|
|
human physician approval before the pharmacy agent can proceed.
|
|
The workflow demonstrates the "actor_type" claim for
|
|
human-in-the-loop steps.
|
|
|
|
~~~
|
|
Domain: hospital.example.org (US, HIPAA)
|
|
|
|
Agent C1 (Clinical AI):
|
|
jti: task-101 pred:[]
|
|
iss: https://agents.hospital.example.org/clinical-ai
|
|
exec_act: recommend_treatment
|
|
actor_type: agent
|
|
eat_reg: {profiles: ["urn:ietf:eat:reg:us-hipaa"],
|
|
retention_days: 2190, jurisdiction: "US"}
|
|
|
|
Dr. Smith (Physician Approval):
|
|
jti: task-102 pred:[task-101]
|
|
iss: https://staff.hospital.example.org/dr-smith
|
|
exec_act: approve_treatment
|
|
actor_type: human
|
|
eat_reg: {profiles: ["urn:ietf:eat:reg:us-hipaa"],
|
|
retention_days: 2190, jurisdiction: "US"}
|
|
|
|
Agent C2 (Pharmacy):
|
|
jti: task-103 pred:[task-102]
|
|
iss: https://agents.hospital.example.org/pharmacy
|
|
exec_act: dispense_medication
|
|
actor_type: agent
|
|
~~~
|
|
{: #fig-healthcare title="Healthcare HITL Workflow (L2/L3)"}
|
|
|
|
Task 102 has "actor_type": "human", indicating a physician
|
|
reviewed and approved the AI's recommendation. The EAT is
|
|
signed by the hospital's approval gateway on behalf of
|
|
Dr. Smith. When this workflow's output crosses to a research
|
|
partner under GDPR, selective disclosure redacts the physician's
|
|
identity and treatment details while preserving the DAG structure
|
|
proving human approval occurred.
|
|
|
|
## Multi-Cloud AI Pipeline with Mixed Identity (L2)
|
|
{:numbered="false"}
|
|
|
|
An AI pipeline spans three cloud providers, each using a
|
|
different identity framework. The DAG demonstrates cross-domain
|
|
identity resolution.
|
|
|
|
~~~
|
|
Domain: aws.customer.example (X.509 identity)
|
|
Agent P1 (Data Preprocessor):
|
|
jti: task-301 pred:[]
|
|
iss: urn:x509:CN=preprocessor.aws.customer.example
|
|
exec_act: preprocess_training_data
|
|
kid: x5t#sha256:abc123...
|
|
|
|
Domain: gcp.partner.example (OAuth identity)
|
|
Agent P2 (Model Training):
|
|
jti: task-302 pred:[task-301]
|
|
iss: https://oauth.gcp.partner.example/client/trainer
|
|
exec_act: train_model
|
|
kid: oauth-key-456
|
|
|
|
Domain: azure.customer.example (JWK Set identity)
|
|
Agent P3 (Model Validation):
|
|
jti: task-303 pred:[task-302]
|
|
iss: https://agents.azure.customer.example/validator
|
|
exec_act: validate_model
|
|
kid: jwk-789
|
|
~~~
|
|
{: #fig-multicloud title="Multi-Cloud Mixed Identity (L2)"}
|
|
|
|
Each domain uses its own identity framework; the EAT format
|
|
remains the same across all three. Cross-domain key resolution
|
|
is handled through pre-established federation (e.g., shared
|
|
JWK set endpoints).
|
|
|
|
## Internal Microservice Mesh (L1)
|
|
{:numbered="false"}
|
|
|
|
In an internal AI platform, multiple microservices coordinate to
|
|
process requests. All agents operate within a single trust domain
|
|
behind a service mesh with mTLS. Non-repudiation is not required;
|
|
the EATs are used for observability and debugging.
|
|
|
|
~~~
|
|
Domain: internal.example
|
|
Agent S1 (Preprocessor):
|
|
jti: task-401 pred:[]
|
|
exec_act: preprocess_input
|
|
|
|
Agent S2 (Model Inference):
|
|
jti: task-402 pred:[task-401]
|
|
exec_act: run_inference
|
|
|
|
Agent S3 (Postprocessor):
|
|
jti: task-403 pred:[task-402]
|
|
exec_act: format_output
|
|
~~~
|
|
{: #fig-internal title="Internal Microservice Workflow (L1)"}
|
|
|
|
# Relationship to WIMSE ECT
|
|
{:numbered="false"}
|
|
|
|
This specification generalizes the Execution Context Token (ECT)
|
|
concept originally defined in the context of the WIMSE working
|
|
group. The WIMSE ECT specification focuses on
|
|
SPIFFE/WIMSE-based identity; this specification provides the
|
|
same core functionality (DAG-based execution audit with three
|
|
assurance levels) while being identity-framework agnostic.
|
|
|
|
Deployments using WIMSE can implement EATs with the following
|
|
profile:
|
|
|
|
- "iss" is the workload's SPIFFE ID
|
|
(e.g., `spiffe://trust-domain/path`)
|
|
- "kid" references the WIT public key
|
|
- "alg" matches the WIT algorithm
|
|
- Revocation is checked via SPIFFE trust bundles
|
|
- EATs are transported alongside WIT and WPT per the WIMSE
|
|
service-to-service protocol {{I-D.ietf-wimse-s2s-protocol}}
|
|
|
|
# Related Work
|
|
{:numbered="false"}
|
|
|
|
## OAuth 2.0 Token Exchange and the "act" Claim
|
|
{:numbered="false"}
|
|
|
|
{{RFC8693}} defines the OAuth 2.0 Token Exchange protocol and
|
|
registers the "act" (Actor) claim in the JWT Claims registry.
|
|
The "act" claim creates nested JSON objects representing a
|
|
delegation chain: "who is acting on behalf of whom." While
|
|
the nesting superficially resembles a chain, it is strictly
|
|
linear (each "act" object contains at most one nested "act"),
|
|
represents authorization delegation rather than task execution,
|
|
and carries no task identifiers or input/output integrity
|
|
data. The "act" chain cannot represent branching (fan-out)
|
|
or convergence (fan-in) and therefore cannot form a DAG.
|
|
|
|
EATs intentionally use the distinct claim name "exec_act" for the
|
|
action/task type to avoid collision with the "act" claim.
|
|
|
|
## Transaction Tokens
|
|
{:numbered="false"}
|
|
|
|
OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}}
|
|
propagate authorization context across workload call chains.
|
|
The Txn-Token "req_wl" claim accumulates a comma-separated list
|
|
of workloads that requested replacement tokens, which is the
|
|
closest existing mechanism to call-chain recording.
|
|
|
|
However, "req_wl" cannot form a DAG because it is linear, it
|
|
is incomplete (only workloads that request replacement tokens
|
|
are recorded), and it cannot represent convergence (fan-in).
|
|
|
|
EATs and Transaction Tokens are complementary: a Txn-Token
|
|
propagates authorization context ("this request is authorized
|
|
for scope X on behalf of user Y"), while an EAT records
|
|
execution accountability ("task T was performed, depending on
|
|
tasks P1 and P2").
|
|
|
|
## Distributed Tracing (OpenTelemetry)
|
|
{:numbered="false"}
|
|
|
|
OpenTelemetry {{OPENTELEMETRY}} and similar distributed tracing
|
|
systems provide observability for debugging and monitoring. EATs
|
|
differ in several important ways: at L2 and L3, EATs are
|
|
cryptographically signed per-task with the agent's private key;
|
|
EATs are tamper-evident through JWS signatures; EATs enforce DAG
|
|
validation rules; and EATs are designed for regulatory audit rather
|
|
than operational monitoring. OpenTelemetry data is typically
|
|
controlled by the platform operator and can be modified or deleted
|
|
without detection.
|
|
|
|
## SCITT (Supply Chain Integrity, Transparency, and Trust)
|
|
{:numbered="false"}
|
|
|
|
The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a
|
|
framework for transparent and auditable supply chain records.
|
|
There is a notable parallel between SCITT's Transparency Service
|
|
and EAT's Level 3 audit ledger: both use append-only logs with
|
|
cryptographic commitment. The federated ledger model defined in
|
|
this specification ({{federated-ledger}}) draws on similar
|
|
principles to Certificate Transparency
|
|
{{CERTIFICATE-TRANSPARENCY}} and SCITT.
|
|
|
|
## RATS (Remote Attestation Procedures)
|
|
{:numbered="false"}
|
|
|
|
RATS {{RFC9334}} defines an architecture for conveying attestation
|
|
evidence about platform trustworthiness. RATS attests "is this
|
|
platform in a trustworthy state?" while EATs record "what did
|
|
this agent do?" — both deal with claims about entities but at
|
|
different layers. EATs could complement RATS by recording
|
|
execution context on platforms whose trustworthiness has been
|
|
established through RATS attestation.
|
|
|
|
## Emerging Agent Protocol Frameworks
|
|
{:numbered="false"}
|
|
|
|
Several emerging frameworks address agent-to-agent communication,
|
|
including Google's Agent-to-Agent Protocol (A2A), Anthropic's
|
|
Model Context Protocol (MCP), and orchestration frameworks such
|
|
as LangChain and LangGraph. These frameworks primarily address
|
|
agent discovery, message routing, and tool invocation but do not
|
|
provide cryptographically verifiable execution records or
|
|
DAG-based audit trails. EATs complement these frameworks by
|
|
adding an execution accountability layer.
|
|
|
|
# Acknowledgments
|
|
{:numbered="false"}
|
|
|
|
The author thanks the WIMSE working group for their foundational
|
|
work on workload identity in multi-system environments, which
|
|
provided the original motivation for execution context tracing.
|