feat: polish draft-01 for submission — claim renames, review fixes, refimpl docs
Draft improvements: - Rename ext -> ect_ext, clarify iss/aud requirements per level - Add algorithm agility guidance and RFC 8725 reference - Add HTTP header size constraints and body transport fallback - Add cross-level parent reference semantics - Add emerging agent protocols (A2A, MCP) to Related Work - Fix HTTP error handling (403 not 401), IANA +jwt suffix note - Add workflow consistency check to DAG validation - Add defense-in-depth note for acyclicity check Supporting files: - Fix blog post outdated claim names (par -> pred, ext -> ect_ext) - Update refimpl README with -00 vs -01 migration mapping - Add refimpl IMPROVEMENTS.md section 6 with -01 migration tasks
This commit is contained in:
@@ -32,12 +32,14 @@ normative:
|
||||
RFC9110:
|
||||
|
||||
informative:
|
||||
RFC6838:
|
||||
RFC8693:
|
||||
RFC8725:
|
||||
I-D.ietf-wimse-arch:
|
||||
I-D.ietf-wimse-s2s-protocol:
|
||||
SPIFFE:
|
||||
title: "SPIFFE ID"
|
||||
target: https://github.com/spiffe/spiffe/blob/main/standards/SPIFFE-ID.md
|
||||
target: https://spiffe.io/docs/latest/spiffe-about/spiffe-concepts/
|
||||
date: false
|
||||
OPENTELEMETRY:
|
||||
title: "OpenTelemetry Specification"
|
||||
@@ -49,7 +51,9 @@ informative:
|
||||
I-D.ietf-oauth-transaction-tokens:
|
||||
I-D.oauth-transaction-tokens-for-agents:
|
||||
title: "Transaction Tokens for Agentic AI Systems"
|
||||
target: https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents/
|
||||
target: https://datatracker.ietf.org/doc/draft-oauth-transaction-tokens-for-agents-00/
|
||||
seriesinfo:
|
||||
Internet-Draft: draft-oauth-transaction-tokens-for-agents-00
|
||||
date: 2025
|
||||
author:
|
||||
- fullname: Vittorio Bertocci
|
||||
@@ -197,21 +201,23 @@ this section.
|
||||
The following standard JWT claims {{RFC7519}} are defined for ECTs:
|
||||
|
||||
iss:
|
||||
: RECOMMENDED. StringOrURI. A URI identifying the issuer of the
|
||||
ECT. The value MUST correspond to the agent's identity as
|
||||
asserted by its identity credential (see {{identity-binding}}).
|
||||
In WIMSE deployments, this SHOULD be the workload's SPIFFE ID
|
||||
in the format `spiffe://<trust-domain>/<path>`. Other
|
||||
deployments MAY use HTTPS URLs, URN:UUID identifiers, or other
|
||||
URI schemes appropriate to the identity framework in use. The
|
||||
"iss" claim is REQUIRED for L2 and L3 deployments (see
|
||||
{{l2-verification}} and {{l3-verification}}).
|
||||
: OPTIONAL at L1; REQUIRED at L2 and L3. StringOrURI. A URI
|
||||
identifying the issuer of the ECT. The value MUST correspond
|
||||
to the agent's identity as asserted by its identity credential
|
||||
(see {{identity-binding}}). In WIMSE deployments, this SHOULD
|
||||
be the workload's SPIFFE ID in the format
|
||||
`spiffe://<trust-domain>/<path>`. Other deployments MAY use
|
||||
HTTPS URLs, URN:UUID identifiers, 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 ECT. The "aud" claim SHOULD contain the
|
||||
identifiers of all entities that will verify the ECT. When
|
||||
an ECT must be verified by both the next agent and the audit
|
||||
an ECT 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
|
||||
@@ -254,7 +260,10 @@ pred:
|
||||
representing DAG dependencies. Each element MUST be the "jti"
|
||||
value of a previously verified ECT. An empty array indicates
|
||||
a root task with no dependencies. A workflow MAY contain
|
||||
multiple root tasks.
|
||||
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.
|
||||
|
||||
### Data Integrity Claims {#data-integrity-claims}
|
||||
|
||||
@@ -275,15 +284,15 @@ out_hash:
|
||||
|
||||
### Extension Claims {#extension-claims}
|
||||
|
||||
ext:
|
||||
ect_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 "ext" object MUST NOT exceed
|
||||
collisions. The serialized "ect_ext" object MUST NOT exceed
|
||||
4096 bytes and MUST NOT exceed a nesting depth of 5 levels.
|
||||
Receivers MUST reject ECTs whose "ext" object exceeds these
|
||||
Receivers MUST reject ECTs whose "ect_ext" object exceeds these
|
||||
limits.
|
||||
|
||||
## Complete ECT Payload Example
|
||||
@@ -307,7 +316,7 @@ envelope differs.
|
||||
"inp_hash": "n4bQgYhMfWWaL-qgxVrQFaO_TxsrC4Is0V1sFbDwCgg",
|
||||
"out_hash": "LCa0a2j_xo_5m0U8HTBBNBNCLXBkg7-g-YpeiGJm564",
|
||||
|
||||
"ext": {
|
||||
"ect_ext": {
|
||||
"com.example.trace_id": "abc123"
|
||||
}
|
||||
}
|
||||
@@ -428,7 +437,15 @@ alg:
|
||||
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 ECTs require
|
||||
asymmetric signatures for non-repudiation.
|
||||
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. The algorithm
|
||||
is signaled in-band via the "alg" header parameter, enabling
|
||||
verifiers to support multiple algorithms during a transition
|
||||
period. Deployments SHOULD document their algorithm migration
|
||||
strategy and SHOULD NOT assume that ES256 will remain
|
||||
sufficient indefinitely.
|
||||
|
||||
typ:
|
||||
: REQUIRED. MUST be set to "exec+jwt" to distinguish ECTs from
|
||||
@@ -616,18 +633,23 @@ REQUIRED at L3.
|
||||
1. Perform all L2 verification steps (steps 1 through 14 of
|
||||
{{l2-verification}}).
|
||||
|
||||
2. Submit the ECT to the audit ledger for recording per
|
||||
{{l3-recording}}.
|
||||
2. Verify that the ECT has been recorded in the audit ledger by
|
||||
querying the ledger for the ECT's "jti". If the ECT is
|
||||
found, verify that the ledger entry's receipt contains a
|
||||
valid sequence number, ECT hash, and cryptographic commitment
|
||||
proof. Note: the producing agent is responsible for recording
|
||||
the ECT per {{l3-recording}}; the verifier checks that
|
||||
recording has occurred.
|
||||
|
||||
3. Verify that the ledger returned a valid receipt containing
|
||||
the sequence number, ECT hash, and cryptographic commitment
|
||||
proof.
|
||||
3. If the ECT 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 ECT within
|
||||
the configured timeout, the verifier MUST either reject the
|
||||
ECT or downgrade to L2 verification per deployment policy.
|
||||
|
||||
4. If synchronous recording is required by deployment policy and
|
||||
the ledger does not return a receipt within the configured
|
||||
timeout, the agent SHOULD retry with exponential backoff.
|
||||
If the ledger remains unavailable after a
|
||||
deployment-configured number of retries, the agent MUST
|
||||
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 ECT or downgrade to L2 verification per
|
||||
deployment policy.
|
||||
|
||||
@@ -668,13 +690,23 @@ following criteria:
|
||||
|
||||
- Use L3 when regulatory requirements mandate tamper-evident
|
||||
audit trails with cryptographic commitment, or when the
|
||||
deployment must demonstrate compliance with frameworks such as
|
||||
deployment needs to demonstrate compliance with frameworks such as
|
||||
FDA 21 CFR Part 11, MiFID II, or the EU AI Act.
|
||||
|
||||
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.
|
||||
requirements apply to the receiving agent. Specifically, an
|
||||
ECT at a higher assurance level MAY reference parent ECTs at a
|
||||
lower assurance level in its "pred" claim. In this case, the
|
||||
receiving agent applies its own level's verification to the
|
||||
current ECT and the parent's level verification to each parent
|
||||
ECT. For example, an L2 agent receiving an L1 parent ECT
|
||||
verifies the L1 parent per {{l1-verification}} and its own L2
|
||||
ECT per {{l2-verification}}. Whether cross-level parent
|
||||
references are permitted is a deployment policy decision;
|
||||
deployments MAY reject ECTs 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.
|
||||
@@ -817,13 +849,17 @@ subsequent ECT.
|
||||
## HTTP Error Handling
|
||||
|
||||
When ECT verification fails during HTTP request processing, the
|
||||
receiving agent SHOULD respond with HTTP 403 (Forbidden) if the
|
||||
agent's identity credential is valid but the ECT is invalid, and
|
||||
HTTP 401 (Unauthorized) if the ECT signature verification fails.
|
||||
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 ECT verification
|
||||
fails.
|
||||
receiving agent SHOULD respond with HTTP 403 (Forbidden). This
|
||||
applies regardless of whether the failure is due to an invalid
|
||||
ECT payload, a signature verification failure, or a missing ECT
|
||||
when one is required by deployment policy. HTTP 401
|
||||
(Unauthorized) SHOULD NOT be used for ECT 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 ECT verification fails.
|
||||
|
||||
# DAG Validation {#dag-validation}
|
||||
|
||||
@@ -861,12 +897,25 @@ the following DAG validation steps:
|
||||
|
||||
4. Acyclicity: Following the chain of parent references MUST NOT
|
||||
lead back to the current ECT's "jti". If a cycle is detected,
|
||||
the ECT MUST be rejected.
|
||||
the ECT MUST be rejected. Note: because the Parent Existence
|
||||
check (step 2) requires that all parents already exist in the
|
||||
ECT store, and an ECT cannot reference itself or a future ECT,
|
||||
cycles are prevented by construction. This explicit check
|
||||
serves as defense in depth against implementation errors or
|
||||
store corruption.
|
||||
|
||||
5. Trust Domain Consistency: Parent tasks SHOULD belong to the
|
||||
same trust domain or to a trust domain with which a federation
|
||||
relationship has been established.
|
||||
|
||||
6. Workflow Consistency: When "wid" is present, verifiers SHOULD
|
||||
validate that the "wid" of each parent ECT matches the "wid"
|
||||
of the current ECT. Cross-workflow parent references (where
|
||||
a parent's "wid" differs from the child's "wid") MUST be
|
||||
rejected unless explicitly permitted by deployment policy.
|
||||
See also {{collusion-and-false-claims}} for the security
|
||||
rationale.
|
||||
|
||||
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
|
||||
@@ -1057,7 +1106,8 @@ revoked, the ECT MUST be rejected entirely and the failure MUST
|
||||
be logged.
|
||||
|
||||
Implementations MUST use established JWS libraries and MUST NOT
|
||||
implement custom signature verification.
|
||||
implement custom signature verification. Implementations SHOULD
|
||||
follow the JWT security best practices defined in {{RFC8725}}.
|
||||
|
||||
The prohibition of "alg": "none" (see {{l2-verification}}) also
|
||||
serves as defense against level-confusion attacks: an L1 payload
|
||||
@@ -1150,7 +1200,18 @@ higher tolerance and SHOULD document the configured value.
|
||||
## ECT Size Constraints
|
||||
|
||||
Implementations SHOULD limit the "pred" array to a maximum of
|
||||
256 entries. See {{extension-claims}} for "ext" size limits.
|
||||
256 entries. See {{extension-claims}} for "ect_ext" size limits.
|
||||
|
||||
When ECTs 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 ECT
|
||||
(including JWS overhead for L2/L3) does not exceed 8 KB when
|
||||
transported via HTTP header. ECTs that exceed HTTP header size
|
||||
limits SHOULD be transported in the HTTP request body instead
|
||||
(see {{l1-transport}} and {{l2-transport}}). Deployments SHOULD
|
||||
monitor ECT sizes and alert when ECTs approach transport limits.
|
||||
|
||||
## Identity Binding Security
|
||||
|
||||
@@ -1167,7 +1228,7 @@ configurable intervals (RECOMMENDED: no longer than 5 minutes).
|
||||
|
||||
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 must decide
|
||||
If the revocation source is unreachable, the verifier needs to decide
|
||||
whether to accept or reject the ECT. Implementations SHOULD
|
||||
hard-fail for L3 (reject the ECT if revocation status cannot be
|
||||
determined), as L3 workflows require the strongest assurance.
|
||||
@@ -1247,7 +1308,7 @@ the privacy-relevant data but does not increase its scope.
|
||||
Implementations SHOULD minimize the information included in ECTs.
|
||||
The "exec_act" claim SHOULD use structured identifiers (e.g.,
|
||||
"process_payment") rather than natural language descriptions.
|
||||
Extension keys in "ext" ({{extension-claims}}) deserve particular
|
||||
Extension keys in "ect_ext" ({{extension-claims}}) deserve particular
|
||||
attention: human-readable values risk exposing sensitive operational
|
||||
details. See {{extension-claims}} for guidance on using
|
||||
structured identifiers.
|
||||
@@ -1290,6 +1351,12 @@ cross-workflow correlation.
|
||||
This document requests registration of the following media types
|
||||
in the "Media Types" registry maintained by IANA:
|
||||
|
||||
Note: The media type "application/exec+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/exec+jwt
|
||||
|
||||
Type name:
|
||||
@@ -1430,7 +1497,7 @@ the "JSON Web Token Claims" registry maintained by IANA:
|
||||
| pred | Predecessor Task Identifiers | IETF | {{exec-claims}} |
|
||||
| inp_hash | Input Data Hash | IETF | {{data-integrity-claims}} |
|
||||
| out_hash | Output Data Hash | IETF | {{data-integrity-claims}} |
|
||||
| ext | Extension Object | IETF | {{extension-claims}} |
|
||||
| ect_ext | Extension Object | IETF | {{extension-claims}} |
|
||||
{: #table-claims title="JWT Claims Registrations"}
|
||||
|
||||
--- back
|
||||
@@ -1698,7 +1765,7 @@ than operational monitoring. OpenTelemetry data is typically
|
||||
controlled by the platform operator and can be modified or deleted
|
||||
without detection. ECTs and distributed traces are complementary:
|
||||
traces provide observability while ECTs provide execution records.
|
||||
ECTs may reference OpenTelemetry trace identifiers in the "ext"
|
||||
ECTs may reference OpenTelemetry trace identifiers in the "ect_ext"
|
||||
claim for correlation.
|
||||
|
||||
## W3C Provenance Data Model (PROV)
|
||||
@@ -1748,6 +1815,20 @@ agents. ECTs 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. ECTs complement these frameworks by adding an
|
||||
execution accountability layer: agents communicating via any of
|
||||
these protocols can produce and verify ECTs to record what was
|
||||
done, regardless of the communication mechanism used.
|
||||
|
||||
# Acknowledgments
|
||||
{:numbered="false"}
|
||||
|
||||
|
||||
Reference in New Issue
Block a user