|
|
|
|
@@ -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"}
|
|
|
|
|
|
|
|
|
|
|
