diff --git a/draft-nennemann-wimse-ect.md b/draft-nennemann-wimse-ect.md index ae8c529..57feaa9 100644 --- a/draft-nennemann-wimse-ect.md +++ b/draft-nennemann-wimse-ect.md @@ -23,12 +23,10 @@ author: email: ietf@nennemann.de normative: - RFC2119: RFC7515: RFC7517: RFC7518: RFC7519: - RFC8174: RFC9449: RFC9562: RFC9110: @@ -49,7 +47,12 @@ informative: - org: Cloud Native Computing Foundation I-D.ietf-scitt-architecture: I-D.ietf-oauth-transaction-tokens: - I-D.bertocci-oauth-transaction-tokens-for-agents: + 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/ + date: 2025 + author: + - fullname: Vittorio Bertocci RFC9334: --- abstract @@ -347,7 +350,7 @@ verification steps: 3. Verify that the "jti" has not been previously seen within the expiration window, consistent with the replay detection - requirement in {{jwt-claims}}. + requirement in {{exec-claims}}. 4. Verify the "exp" claim indicates the ECT has not expired. @@ -959,7 +962,7 @@ perceived ordering. ## Level-Specific Security Properties {#level-security} -### Level 1 +### Level 1 {#sec-level-1} L1 provides no cryptographic binding between the ECT and its issuer. A compromised or malicious intermediary with access to @@ -974,14 +977,14 @@ 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 +### Level 2 {#sec-level-2} L2 inherits all security properties of the JWS-based ECT mechanism defined in this document. The existing security analysis (signature verification, replay prevention, key compromise, collusion) applies directly to L2. -### Level 3 +### Level 3 {#sec-level-3} L3 provides all L2 security properties plus tamper-evident history via the audit ledger's hash chain and cryptographic @@ -1151,7 +1154,7 @@ Implementations SHOULD limit the "pred" array to a maximum of ## Identity Binding Security -### JWK Set Binding +### 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 @@ -1160,7 +1163,7 @@ 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 +### 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. @@ -1172,7 +1175,7 @@ Implementations MAY soft-fail for L2 with logging, accepting the ECT but recording the revocation check failure for subsequent audit review. -### WIMSE Binding +### WIMSE Binding {#sec-wimse-binding} When identity is bound via WIMSE trust bundles, the same time-of-check/time-of-use concern applies to trust bundle @@ -1444,6 +1447,7 @@ readability. In production, all "jti" values are required to be UUIDs per {{exec-claims}}. ## Cross-Organization Financial Trading (L3) +{:numbered="false"} In a cross-organization trading workflow, an investment bank's agents coordinate with an external credit rating agency. The @@ -1503,6 +1507,7 @@ verifies both parent ECTs — one signed by a local key and one by a federated key from the rating agency's trust domain. ## Multi-Vendor SaaS Integration (L2) +{:numbered="false"} In a document processing pipeline, a customer's orchestration agent coordinates with third-party vendor agents across @@ -1578,6 +1583,7 @@ cross-organizational non-repudiation without requiring an external audit ledger. ## 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 @@ -1608,6 +1614,7 @@ Trust Domain: internal.example {:numbered="false"} ## WIMSE Workload Identity +{:numbered="false"} The WIMSE architecture {{I-D.ietf-wimse-arch}} and service-to- service protocol {{I-D.ietf-wimse-s2s-protocol}} provide one @@ -1619,6 +1626,7 @@ systems. ECTs define an explicit WIMSE identity binding (see {{wimse-binding}}) but are not limited to WIMSE deployments. ## 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. @@ -1638,6 +1646,7 @@ two concepts are orthogonal: "act" records "who authorized whom," ECTs record "what was done, in what order." ## Transaction Tokens +{:numbered="false"} OAuth Transaction Tokens {{I-D.ietf-oauth-transaction-tokens}} propagate authorization context across workload call chains. @@ -1661,7 +1670,7 @@ However, "req_wl" cannot form a DAG because: linear "req_wl" string cannot express that relationship. Extensions for agentic use cases -({{I-D.bertocci-oauth-transaction-tokens-for-agents}}) add agent +({{I-D.oauth-transaction-tokens-for-agents}}) add agent identity and constraints ("agentic_ctx") but no execution ordering or DAG structure. @@ -1677,6 +1686,7 @@ hash-bind a WPT to a co-present Txn-Token; a similar binding mechanism for ECTs is a potential future extension. ## Distributed Tracing (OpenTelemetry) +{:numbered="false"} OpenTelemetry {{OPENTELEMETRY}} and similar distributed tracing systems provide observability for debugging and monitoring. ECTs @@ -1692,6 +1702,7 @@ ECTs may reference OpenTelemetry trace identifiers in the "ext" claim for correlation. ## W3C Provenance Data Model (PROV) +{:numbered="false"} The W3C PROV Data Model defines an Entity-Activity-Agent ontology for representing provenance information. PROV's concepts map @@ -1704,6 +1715,7 @@ cryptographic signatures. ECT audit data could be exported to 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 framework for transparent and auditable supply chain records. @@ -1722,6 +1734,7 @@ SCITT Transparency Service as the audit ledger backend, recording ECTs as supply chain statements about agent execution. ## RATS (Remote Attestation Procedures) +{:numbered="false"} RATS {{RFC9334}} defines an architecture for conveying attestation evidence about platform trustworthiness. RATS attests "is this