| Internet-Draft | WIMSE Authorization Evidence | May 2026 |
| Munoz | Expires 15 November 2026 | [Page] |
This document specifies a companion profile to the AI Agent Authentication and Authorization draft [I-D.klrc-aiagent-auth], defining a signed authorization-evidence record produced by WIMSE-authorized AI agent actions. The evidence record (referred to as a Permit) commits cryptographically to the canonical request bytes dispatched after authorization, satisfies the audit minimum requirements enumerated in Section 11 of the companion draft, and composes with HTTP Message Signatures, OAuth access tokens, and Shared Signals Framework eventing without requiring modifications to those existing standards. The profile is anchored in the SCITT profile defined in [I-D.munoz-scitt-permit-profile].¶
This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.¶
Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/.¶
Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."¶
This Internet-Draft will expire on 15 November 2026.¶
Copyright (c) 2026 IETF Trust and the persons identified as the document authors. All rights reserved.¶
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶
The AI Agent Authentication and Authorization draft [I-D.klrc-aiagent-auth] composes existing standards (SPIFFE, WIMSE, OAuth 2.0, HTTP Message Signatures) to specify how AI agents obtain identity, authenticate, and acquire runtime authorization for invocations against tools, services, and large language models. That draft explicitly states it does not define new protocols.¶
A consequence of this scoping decision is that the draft does not define a signed evidence record of the authorization decision itself. Section 11 of the draft enumerates audit minimum requirements (authenticated agent identifier, delegated subject, resource or tool, action requested and authorization decision, timestamp and correlation identifier, attestation or risk state, remediation or revocation events) but leaves the format of the evidence record to implementations.¶
This document defines such a record. The record is a Permit, as specified in the companion SCITT profile [I-D.munoz-scitt-permit-profile], with this document adding the WIMSE-specific integration guidance: how Permits represent SPIFFE identities, how they satisfy the Section 11 audit minimum requirements, how they integrate with HTTP Message Signatures and OAuth access tokens, and how Permit lifecycle states bridge to Shared Signals Framework eventing.¶
This profile specifies:¶
How to populate Permit subject fields with SPIFFE URIs¶
A crosswalk from Section 11 of [I-D.klrc-aiagent-auth] to Permit fields¶
Optional integration with HTTP Message Signatures [RFC9421] for request-level signature coverage that extends Permit's canonical-body binding to header coverage¶
Optional integration with OAuth access tokens through a Permit-ID claim that allows runtime tokens to reference the signed authorization-evidence record¶
A descriptive (non-normative) bridge between Permit lifecycle state transitions and Shared Signals Framework / Continuous Access Evaluation Profile / Risk Incident Sharing eventing¶
This profile does not specify:¶
Modifications to [I-D.klrc-aiagent-auth] or any standard it builds upon¶
A new authorization protocol or token format¶
Identity management beyond what SPIFFE/WIMSE define¶
The Permit object itself; that specification is in [KEEL-PERMIT] and the SCITT profile in [I-D.munoz-scitt-permit-profile]¶
This document is a companion to [I-D.munoz-scitt-permit-profile]. That document defines the Permit object as a SCITT Signed Statement and specifies the COSE_Sign1 envelope, Receipt format, and verification rules. This document extends that profile with WIMSE-specific integration guidance. An implementation that conforms to both profiles produces evidence that is consumable by SCITT-aware verifiers and that satisfies the audit minimum requirements of [I-D.klrc-aiagent-auth].¶
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶
This document uses terminology from [I-D.klrc-aiagent-auth]: Agent Identifier, Agent Credential, Workload Identity Token (WIT), Workload Proof Token (WPT), Transaction Token, Agent Authentication, Agent Authorization, Audit Event.¶
This document uses terminology from [KEEL-PERMIT] and [I-D.munoz-scitt-permit-profile]: Permit, Closure Record, binding_request_hash, dispatch_request_digest_v1, Signed Statement, Receipt, Transparent Statement.¶
A Permit, as specified in [I-D.munoz-scitt-permit-profile] and [KEEL-PERMIT], is a Signed Statement that records the pre-execution authorization decision for an AI agent action. It satisfies the Section 11 audit minimum requirements directly, binds to the dispatched request bytes cryptographically, and is verifiable independently of the issuer. It serves as the audit evidence record the WIMSE draft requires.¶
A Permit emitted under this WIMSE companion profile and signed under [I-D.munoz-scitt-permit-profile] satisfies both:¶
SCITT verifiers (via the COSE_Sign1 Signed Statement envelope and chain-entry Receipt)¶
[I-D.klrc-aiagent-auth] Section 11 audit minimum requirements¶
Implementations MAY produce Permits that conform only to this companion profile (without the SCITT COSE_Sign1 envelope) if SCITT compatibility is not required. In that case, the Permit's legacy signature envelope [KEEL-PERMIT] satisfies the integrity requirement for Section 11 evidence purposes, but the artifact is not consumable by SCITT-aware verifiers.¶
A future version of this profile MAY deprecate the legacy-only mode in favor of SCITT-compatible emission. This profile-00 does not.¶
OAuth access tokens, WITs, and WPTs are short-lived runtime credentials. Permits are long-lived signed evidence records. The two are linked by the permit_id claim (when present) but their verification lifetimes are distinct.¶
Compromise of a runtime credential does not retroactively invalidate the Permit (because the Permit was signed by the Issuer at decision time, not by the runtime credential). Compromise of an Issuer signing key, however, permits forgery of Permits and SHOULD be addressed through key-rotation procedures specified in the Issuer's key manifest.¶
A Permit's subject_id, when a SPIFFE URI, identifies the agent's trust domain and workload path. When a delegated subject is present, the delegated principal is also identified. Verifiers processing Permits SHOULD apply access controls appropriate to the sensitivity of the subject identifiers.¶
Transaction Tokens carry per-call context that should not appear in long-lived hashes. The Permit's binding_request_hash is computed over canonical request bytes after volatile-key stripping ([KEEL-PERMIT]); Transaction Token identifiers are stripped if they appear in the request body. Transaction Token correlation recorded in the Permit's idempotency_key field is not subject to the stripping rules; this is intentional, since the correlation ID is the same artifact that downstream eventing references.¶
When an HTTP Message Signature is recorded in the Closure Record, the signature's signed components include the WIT itself (per [I-D.klrc-aiagent-auth] Section 9.2.2). The WIT carries the agent's public key reference; the signature commits to the agent's authentication context at dispatch time. Verifiers validating both the Permit and the HTTP Message Signature obtain two independent cryptographic commitments to the dispatched request.¶
The descriptive bridge from Permit chain events to SSF events is not normative in this profile. Deployments that adopt the bridge MUST ensure that bridge-generated SSF events are produced by a component with appropriate trust relative to the Permit Issuer and the SSF transmitter. Bridge components SHOULD sign or otherwise authenticate the events they generate.¶
When a delegated subject is identified in the Permit's decision_details.delegated_subject, the privacy considerations of the delegated principal apply. Issuers SHOULD consider whether direct identifier inclusion is appropriate or whether a pseudonymized identifier is required, depending on the audience consuming the Transparent Statement.¶
A SPIFFE URI in subject_id discloses the agent's trust domain. The trust domain may identify an organization, a deployment environment, or a particular system. Verifiers and Transparency Service operators SHOULD treat trust domain disclosure with appropriate sensitivity.¶
The combination of subject_id, policy_id, and resource fields across many Permits supports re-identification of agents and correlation across requests. Operators SHOULD apply data minimization and access control to the audit-export delivery mechanism for Permits and their chain entries.¶
This document has no immediate IANA requests. A future revision MAY request registration of the permit_id OAuth claim and the http_message_signature Closure Record extension.¶
This section is to be removed before publication as an RFC.¶
A reference Issuer implementation is published at [KEEL-PERMIT] under Apache 2.0. SPIFFE subject typing is supported by the open subject model. The Section 11 audit minimum requirements crosswalk is satisfied by the Permit fields as deployed. HTTP Message Signature integration, OAuth permit_id claim, and SSF bridge are work in progress.¶
The author thanks the authors of [I-D.klrc-aiagent-auth] — Pieter Kasselman, Jeff Lombardo, Yaroslav Rosomakho, Brian Campbell, and Nick Steele — for the framing of the AI agent authentication and authorization model that this companion profile extends. The author also thanks the SCITT working group and the authors of adjacent profiles [I-D.emirdag-scitt-ai-agent-execution] and [I-D.veridom-omp] for related work.¶
This section is to be removed before publication as an RFC.¶
Open issues:¶
Whether to specify the permit_id OAuth claim as a normative addition or to leave it as an implementation pattern.¶
Whether to define the http_message_signature field in the Closure Record normatively, including its exact serialization.¶
Whether to specify normative bridge event formats from Permit chain events to SSF / CAEP / RISC signals.¶
The exact registration mechanism for the permit_id claim (IANA OAuth Parameters registry, private vendor claim, or both).¶
Whether to specify a SPIFFE-required mode or to keep SPIFFE subject typing as optional.¶
Feedback on any of these is welcome on the WIMSE and SCITT mailing lists.¶