feat: draft -02 with ACT liaison, related work, IETF 123 prep
- bump docname to draft-nennemann-wimse-ect-02 - add Relationship to ACT subsection (normative ACT reference) - add Related Work: WIMSE arch §3.3.9, Composition Safety (AgentRFC), MIGT taxonomy, NIST/NCCoE, SCITT-AI-agent-execution, DAWN - acknowledge wimse-http-signature -03 breaking change (wimse-aud param) - pin SCITT arch to -22 (AUTH48), txn-tokens to -08 (WG Last Call) - add DIFF vs txn-tokens-for-agents-06 for WIMSE list intro - add IETF 123 slide outline (10-min WIMSE slot) - add wimse-intro-email draft for mailing list post - mark refimpl as moved to workspace/packages/ect/
This commit is contained in:
@@ -2,7 +2,7 @@
|
||||
title: "Execution Context Tokens for Distributed Agentic Workflows"
|
||||
abbrev: "WIMSE Execution Context"
|
||||
category: std
|
||||
docname: draft-nennemann-wimse-ect-01
|
||||
docname: draft-nennemann-wimse-ect-02
|
||||
submissiontype: IETF
|
||||
number:
|
||||
date:
|
||||
@@ -30,6 +30,14 @@ normative:
|
||||
RFC9449:
|
||||
RFC9562:
|
||||
RFC9110:
|
||||
I-D.nennemann-act:
|
||||
title: "Agent Context Token (ACT)"
|
||||
target: https://datatracker.ietf.org/doc/draft-nennemann-act/
|
||||
seriesinfo:
|
||||
Internet-Draft: draft-nennemann-act-01
|
||||
date: 2026
|
||||
author:
|
||||
- fullname: Christian Nennemann
|
||||
|
||||
informative:
|
||||
RFC6838:
|
||||
@@ -37,6 +45,13 @@ informative:
|
||||
RFC8725:
|
||||
I-D.ietf-wimse-arch:
|
||||
I-D.ietf-wimse-s2s-protocol:
|
||||
I-D.ietf-wimse-http-signature:
|
||||
title: "HTTP Message Signatures for Workloads"
|
||||
target: https://datatracker.ietf.org/doc/draft-ietf-wimse-http-signature-03/
|
||||
seriesinfo:
|
||||
Internet-Draft: draft-ietf-wimse-http-signature-03
|
||||
date: 2026-04-07
|
||||
RFC9421:
|
||||
SPIFFE:
|
||||
title: "SPIFFE ID"
|
||||
target: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
|
||||
@@ -47,7 +62,13 @@ informative:
|
||||
date: false
|
||||
author:
|
||||
- org: Cloud Native Computing Foundation
|
||||
# draft-ietf-scitt-architecture is currently in AUTH48 (RFC Editor
|
||||
# queue) at version -22. To become RFC upon publication. Readers
|
||||
# should use the RFC number once assigned. Refcache pins -22.
|
||||
I-D.ietf-scitt-architecture:
|
||||
# draft-ietf-oauth-transaction-tokens is in IETF WG Last Call at
|
||||
# version -08. Normative reference will be updated to the published
|
||||
# RFC. Refcache pins -08.
|
||||
I-D.ietf-oauth-transaction-tokens:
|
||||
I-D.oauth-transaction-tokens-for-agents:
|
||||
title: "Transaction Tokens for Agentic AI Systems"
|
||||
@@ -57,6 +78,39 @@ informative:
|
||||
date: 2025
|
||||
author:
|
||||
- fullname: Vittorio Bertocci
|
||||
I-D.draft-emirdag-scitt-ai-agent-execution:
|
||||
title: "SCITT Profile for AI Agent Execution"
|
||||
target: https://datatracker.ietf.org/doc/draft-emirdag-scitt-ai-agent-execution/
|
||||
date: 2026
|
||||
author:
|
||||
- fullname: Emirdag
|
||||
I-D.draft-king-dawn-requirements:
|
||||
title: "Requirements for Discovery of AI Agents and Workloads Across Network Boundaries"
|
||||
target: https://datatracker.ietf.org/doc/draft-king-dawn-requirements/
|
||||
date: 2026
|
||||
author:
|
||||
- fullname: King
|
||||
- fullname: Farrel
|
||||
AgentRFC:
|
||||
title: "AgentRFC: Security Design Principles and Conformance Testing for Agent Protocols"
|
||||
target: https://arxiv.org/abs/2603.23801
|
||||
date: 2026
|
||||
author:
|
||||
- fullname: Zheng, Shenghan
|
||||
- fullname: Zhang, Qifan
|
||||
MIGT:
|
||||
title: "Who Governs the Machine? A Machine Identity Governance Taxonomy"
|
||||
target: https://arxiv.org/abs/2604.06148
|
||||
date: 2026
|
||||
author:
|
||||
- fullname: Kurtz, Andrew
|
||||
- fullname: Krawiecka, Klaudia
|
||||
NIST-NCCoE-AI-Agents:
|
||||
title: "Accelerating the Adoption of Software and AI Agent Identity and Authorization"
|
||||
target: https://www.nccoe.nist.gov/projects/ai-agent-identity-authorization
|
||||
date: 2026
|
||||
author:
|
||||
- org: NIST
|
||||
RFC9334:
|
||||
|
||||
--- abstract
|
||||
@@ -141,6 +195,31 @@ 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}}.
|
||||
|
||||
## Relationship to Agent Context Tokens (ACT)
|
||||
|
||||
The Agent Context Token (ACT) {{I-D.nennemann-act}} defines a
|
||||
two-phase authorization and accountability mechanism for agentic
|
||||
workflows. In the first phase an ACT Mandate authorizes an agent
|
||||
to perform a bounded set of actions with explicit capability
|
||||
constraints and delegation chains. In the second phase an ACT
|
||||
Record captures what the agent actually did, enabling post-hoc
|
||||
comparison between authorized and observed behavior.
|
||||
|
||||
ECTs and ACTs are complementary. ACTs answer "was this agent
|
||||
authorized to act, and what did it do relative to that
|
||||
authorization?" ECTs answer "which workload executed this task,
|
||||
in which trust domain, and at what assurance level?" The two
|
||||
tokens serve different accountability layers and a deployment MAY
|
||||
carry both simultaneously: an ACT for capability-scoped
|
||||
authorization and audit, and an ECT for workload-identity-bound
|
||||
execution recording with DAG ordering and assurance levels.
|
||||
|
||||
The following claims have identical semantics in both
|
||||
specifications: "exec_act", "jti", "wid", "inp_hash", "out_hash",
|
||||
and "pred". Implementations that produce both token types MUST
|
||||
use consistent values for these claims when they refer to the same
|
||||
task.
|
||||
|
||||
# Conventions and Definitions
|
||||
|
||||
{::boilerplate bcp14-tagged}
|
||||
@@ -778,6 +857,18 @@ When the deployment uses the WIMSE framework
|
||||
- ECTs are transported alongside the WIT and WPT
|
||||
({{I-D.ietf-wimse-s2s-protocol}}) in HTTP requests.
|
||||
|
||||
ECT defines its own `Execution-Context` HTTP header field
|
||||
({{http-header}}) and does not rely on WIMSE HTTP message
|
||||
signature machinery. Deployments that additionally apply WIMSE
|
||||
HTTP message signatures {{I-D.ietf-wimse-http-signature}} to
|
||||
protect requests should note that as of
|
||||
draft-ietf-wimse-http-signature-03 the audience value is conveyed
|
||||
via the `wimse-aud` signature metadata parameter (per the HTTP
|
||||
Message Signatures framework {{RFC9421}}) rather than a dedicated
|
||||
HTTP header. This change does not affect the ECT payload's own
|
||||
`aud` claim or the `Execution-Context` header defined in this
|
||||
document.
|
||||
|
||||
### X.509 Binding {#x509-binding}
|
||||
|
||||
When the deployment uses X.509 certificates:
|
||||
@@ -1692,6 +1783,108 @@ identity-plus-accountability framework for regulated agentic
|
||||
systems. ECTs define an explicit WIMSE identity binding (see
|
||||
{{wimse-binding}}) but are not limited to WIMSE deployments.
|
||||
|
||||
Section 3.3.9 of the WIMSE architecture
|
||||
{{I-D.ietf-wimse-arch}} explicitly names "AI and ML-Based
|
||||
Intermediaries as autonomous agents propagating security context
|
||||
downstream" as an in-scope architectural case but does not itself
|
||||
specify a format for that propagated execution context. ECTs
|
||||
provide the standardized execution-context format that this
|
||||
architectural section requires: a JWT-based per-task record that
|
||||
an AI/ML intermediary can produce, sign, and propagate downstream
|
||||
to preserve accountability across the agent chain. In this
|
||||
sense, ECTs directly realize a requirement surfaced by the WIMSE
|
||||
charter itself, and the Execution-Context HTTP header defined in
|
||||
{{http-header}} is the concrete on-the-wire encoding for the
|
||||
§3.3.9 propagation model.
|
||||
|
||||
ECTs are also designed to compose with the HTTP message signing
|
||||
profile defined in {{I-D.ietf-wimse-http-signature}}: an
|
||||
Execution-Context header carrying an L2 or L3 ECT can be covered
|
||||
by a WIMSE HTTP message signature over the same request, so that
|
||||
integrity protection of the ECT and of its transport binding are
|
||||
aligned under a single signing model.
|
||||
|
||||
## Composition Safety for Agent Protocols
|
||||
{:numbered="false"}
|
||||
|
||||
Recent analysis of agent protocol security
|
||||
({{AgentRFC}}) establishes that security properties which hold
|
||||
for individual agent protocols can break when those protocols
|
||||
are composed through shared infrastructure, because assumptions
|
||||
made by one protocol are not necessarily preserved by adjacent
|
||||
hops. This provides theoretical motivation for tracking
|
||||
execution context at each hop in an agent chain rather than
|
||||
relying solely on end-to-end authorization tokens, since the
|
||||
boundary where composition fails is generally not observable
|
||||
from any single endpoint. ECTs record execution context
|
||||
per-task with a cryptographic binding to the issuing agent, so
|
||||
that composition-induced failures become detectable during
|
||||
post-hoc audit even when they were not prevented in-band.
|
||||
|
||||
## Machine Identity Governance (MIGT)
|
||||
{:numbered="false"}
|
||||
|
||||
The Machine Identity Governance Taxonomy {{MIGT}} catalogues
|
||||
risk categories for enterprise machine identities and documents
|
||||
that AI agents and automated workflows now outnumber human
|
||||
identities in enterprise environments by ratios exceeding 80 to
|
||||
1. The taxonomy identifies record-keeping, traceability, and
|
||||
non-repudiation of automated actions as primary risk categories
|
||||
under regulatory regimes such as EU AI Act Article 12 on
|
||||
record-keeping, which ECT execution records are specifically
|
||||
designed to address. ECTs provide the per-task signed artifact
|
||||
that such governance frameworks require as evidence that a given
|
||||
automated action was performed by a specific agent identity at a
|
||||
specific time.
|
||||
|
||||
## NIST/NCCoE AI Agent Identity
|
||||
{:numbered="false"}
|
||||
|
||||
The NIST/NCCoE concept paper on AI agent identity and
|
||||
authorization {{NIST-NCCoE-AI-Agents}} is the first US
|
||||
government standards-body document to treat AI agent identity as
|
||||
an enterprise identity management concern, explicitly building on
|
||||
OAuth, OIDC, and SCIM rather than proposing a parallel stack.
|
||||
This validates ECT's standards-first approach of layering
|
||||
accountability on existing IETF credentials and JOSE signing
|
||||
primitives, and ECTs are positioned to serve as a referenced
|
||||
execution-record format for the NCCoE demonstration project
|
||||
alongside the identity and authorization primitives it
|
||||
enumerates.
|
||||
|
||||
## SCITT AI Agent Execution Profile
|
||||
{:numbered="false"}
|
||||
|
||||
The SCITT profile for AI agent execution
|
||||
{{I-D.draft-emirdag-scitt-ai-agent-execution}} defines an
|
||||
AgentInteractionRecord (AIR) with COSE_Sign1 payloads intended
|
||||
for anchoring into SCITT Transparency Services. ECTs and AIR
|
||||
are complementary along the in-transit vs. at-rest dimension:
|
||||
ECTs carry execution context in transit, embedded in a JWT and
|
||||
propagated through the Execution-Context HTTP header defined in
|
||||
{{http-header}}, while AIR anchors records into a SCITT
|
||||
transparency service for long-term tamper-evident storage.
|
||||
Higher-assurance ECT deployments operating at Level 3
|
||||
({{level-3}}) MAY use AIR as the SCITT payload format when the
|
||||
configured audit ledger is a SCITT Transparency Service, with
|
||||
the ECT's signed payload converted into the COSE_Sign1 envelope
|
||||
expected by AIR.
|
||||
|
||||
## DAWN: Discovery of Agents and Workloads
|
||||
{:numbered="false"}
|
||||
|
||||
The proposed DAWN working group and its requirements draft
|
||||
{{I-D.draft-king-dawn-requirements}} define requirements for
|
||||
discovering AI agents, workloads, and named entities across
|
||||
organizational boundaries. ECTs are identity-framework agnostic
|
||||
by design ({{identity-binding}}) and therefore compose cleanly
|
||||
with any discovery mechanism DAWN may produce, regardless of the
|
||||
underlying credential type (WIMSE WIT/WPT, X.509, OAuth, or JWK
|
||||
sets). If DAWN charters, the workload and agent bindings
|
||||
recorded in an ECT are directly usable as discoverable
|
||||
execution-context metadata for agents located through DAWN
|
||||
discovery, without requiring changes to the ECT format itself.
|
||||
|
||||
## OAuth 2.0 Token Exchange and the "act" Claim
|
||||
{:numbered="false"}
|
||||
|
||||
@@ -1716,6 +1909,8 @@ ECTs record "what was done, in what order."
|
||||
{:numbered="false"}
|
||||
|
||||
OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}}
|
||||
(currently at version -08 and in IETF Last Call; the normative
|
||||
reference will be updated to the published RFC)
|
||||
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
|
||||
@@ -1784,7 +1979,9 @@ PROV format for interoperability with provenance-aware systems.
|
||||
## SCITT (Supply Chain Integrity, Transparency, and Trust)
|
||||
{:numbered="false"}
|
||||
|
||||
The SCITT architecture {{I-D.ietf-scitt-architecture}} defines a
|
||||
The SCITT architecture {{I-D.ietf-scitt-architecture}} (version -22,
|
||||
currently in AUTH48 / RFC Editor queue and about to become an RFC;
|
||||
readers should use the RFC number once assigned) defines a
|
||||
framework for transparent and auditable supply chain records.
|
||||
ECTs and SCITT are complementary: the ECT "wid" claim can serve
|
||||
as a correlation identifier in SCITT Signed Statements, linking
|
||||
|
||||
Reference in New Issue
Block a user