Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent Actions
draft-munoz-wimse-authorization-evidence-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Christian Munoz | ||
| Last updated | 2026-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-munoz-wimse-authorization-evidence-01
Network Working Group C. Munoz
Internet-Draft Keel API, Inc.
Intended status: Informational 18 July 2026
Expires: 19 January 2027
Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent
Actions
draft-munoz-wimse-authorization-evidence-01
Abstract
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) cryptographically commits to the canonical bytes of the
request authorized before dispatch and, via a paired Closure Record,
to the recorded dispatched-request digest; it maps to and can satisfy
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 revision also describes how WIMSE deployments compose with
authorization-lineage evidence defined by the companion SCITT
profile: workload identity, delegated subject context, runtime token
claims, and HTTP Message Signature coverage become Verifier inputs
for parent/child Permit relationships.
Status of This Memo
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 19 January 2027.
Munoz Expires 19 January 2027 [Page 1]
Internet-Draft WIMSE Authorization Evidence July 2026
Copyright Notice
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.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Relationship to Other Specifications . . . . . . . . . . 4
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1. The Audit Gap in WIMSE-Style Authorization . . . . . . . 5
2.2. The Permit as Evidence Record . . . . . . . . . . . . . . 6
3. The WIMSE Authorization-Evidence Profile . . . . . . . . . . 6
3.1. SPIFFE Subject Typing . . . . . . . . . . . . . . . . . . 6
3.2. Audit Minimum Requirements Crosswalk . . . . . . . . . . 7
3.3. HTTP Message Signature Integration . . . . . . . . . . . 9
3.4. OAuth Access Token Composition . . . . . . . . . . . . . 9
3.5. Transaction Token Linkage . . . . . . . . . . . . . . . . 10
3.6. Authorization Lineage for Delegated Actions . . . . . . . 10
3.7. Lifecycle State and Eventing Bridge . . . . . . . . . . . 11
4. Composition with the SCITT Profile . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13
5.1. Token Lifetime versus Evidence Persistence . . . . . . . 13
5.2. Subject Identifier Disclosure . . . . . . . . . . . . . . 13
5.3. Transaction Token Replay . . . . . . . . . . . . . . . . 13
5.4. HTTP Message Signature Composition . . . . . . . . . . . 14
5.5. SSF Event Integrity . . . . . . . . . . . . . . . . . . . 14
5.6. Authorization-Lineage Evidence Confusion . . . . . . . . 14
6. Privacy Considerations . . . . . . . . . . . . . . . . . . . 14
6.1. Delegated Subject Identification . . . . . . . . . . . . 14
6.2. Trust Domain Disclosure . . . . . . . . . . . . . . . . . 15
6.3. Long-Lived Identifiers . . . . . . . . . . . . . . . . . 15
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
10.1. Normative References . . . . . . . . . . . . . . . . . . 16
Munoz Expires 19 January 2027 [Page 2]
Internet-Draft WIMSE Authorization Evidence July 2026
10.2. Informative References . . . . . . . . . . . . . . . . . 16
Appendix A. Open Issues for -02 and Beyond . . . . . . . . . . . 18
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18
1. Introduction
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. It is an
individual Internet-Draft and is not, at the time of writing, a WIMSE
working group document.
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, posture assessment 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 revision also describes how WIMSE deployments compose with
authorization-lineage evidence defined by the companion SCITT
profile. The WIMSE profile does not define delegated authority
semantics; it specifies how workload identity, delegated subject
context, runtime token references, and HTTP Message Signature
coverage appear as evidence that a Verifier can cross-check when
evaluating parent/child Permit relationships.
1.1. Scope
This profile specifies:
* How to populate Permit subject fields with SPIFFE URIs
Munoz Expires 19 January 2027 [Page 3]
Internet-Draft WIMSE Authorization Evidence July 2026
* 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-
reference claim that allows runtime tokens to reference the signed
authorization-evidence record
* How WIMSE identity, delegated-subject, OAuth, and HTTP Message
Signature evidence compose with Authority Lineage as defined in
[I-D.munoz-scitt-permit-profile]
* 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; this revision relies on the SCITT
profile in [I-D.munoz-scitt-permit-profile] and the provisional
reference material in [KEEL-PERMIT]
* Authority Representation formats, Comparator Profiles, or
Authority Attenuation rules; those are defined by the SCITT
profile or by other companion profiles
1.2. Relationship to Other Specifications
This document is a companion to [I-D.munoz-scitt-permit-profile].
That document defines a SCITT-compatible Permit Signed Statement and
specifies the COSE_Sign1 [RFC9052] envelope, Receipt construction,
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]. Deployments that use WIMSE workload
identity may also consult the WIMSE architecture
[I-D.ietf-wimse-arch] and workload identifier
Munoz Expires 19 January 2027 [Page 4]
Internet-Draft WIMSE Authorization Evidence July 2026
[I-D.ietf-wimse-identifier] documents for the identity context this
profile records.
1.3. Terminology
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 [I-D.munoz-scitt-permit-profile]:
Permit, Closure Record, binding_request_hash,
dispatch_request_digest_v1, Signed Statement, Receipt, Transparent
Statement, Authority Representation, Comparator Profile, Authority
Attenuation, and Authority Lineage. It also references [KEEL-PERMIT]
as provisional reference material for one implementation of these
concepts.
2. Background
2.1. The Audit Gap in WIMSE-Style Authorization
A WIMSE-authorized AI agent action proceeds as follows: the agent
authenticates via mTLS or WPT, obtains an OAuth access token from an
authorization server, presents the token at a resource server, and
invokes the resource. Each step produces transient authentication
evidence (channel binding, signed proof-of-possession tokens,
validated access tokens) but the authorization decision itself does
not produce a durable signed record.
Section 11 of [I-D.klrc-aiagent-auth] states that, at a minimum,
audit events are required to record:
* authenticated agent identifier
* delegated subject (user or system) when present
* resource or tool being accessed
* action requested and authorization decision
* timestamp and transaction or request correlation identifier
Munoz Expires 19 January 2027 [Page 5]
Internet-Draft WIMSE Authorization Evidence July 2026
* posture assessment or risk state influencing the decision
* remediation or revocation events and their cause
These are evidence requirements without a defined evidence format.
The draft is explicit that the format is left to implementations.
2.2. The Permit as Evidence Record
A SCITT-compatible Permit Signed Statement, as specified in
[I-D.munoz-scitt-permit-profile], records the pre-execution
authorization decision for an AI agent action. It can satisfy the
Section 11 audit minimum requirements when the deployment populates,
or makes available by reference, the delegated-subject, posture/risk,
correlation, and remediation/revocation evidence for the decision; it
binds to the dispatched request bytes cryptographically and is
verifiable independently of the issuer. It is one format capable of
satisfying the audit evidence requirements identified by the
companion draft. [KEEL-PERMIT] provides provisional reference
material and an implementation source for the Permit object.
3. The WIMSE Authorization-Evidence Profile
3.1. SPIFFE Subject Typing
The Permit object's subject_type and subject_id fields together
identify the actor that an authorization decision applies to. When
the agent identity is established through SPIFFE/WIMSE:
* If the workload identity is expressed as a SPIFFE URI,
subject_type MUST be set to "spiffe" and subject_id MUST contain
that SPIFFE URI, in the format spiffe://{trust-domain}/{path}.
* If a WIMSE workload identifier [I-D.ietf-wimse-identifier] is used
instead, subject_type MUST identify the WIMSE identifier scheme
and subject_id MUST contain the workload identifier, in the format
wimse://{trust-domain}/{path}.
The subject_type and subject_id fields describe how an actor identity
is expressed; how that identity is established is a separate concern.
In the reference implementation, when the authenticating credential
resolves to a bound agent principal, the platform sets the subject
from that server-side reconciliation rather than from the caller's
declared subject: the reconciled principal becomes the subject, with
subject_type "agent" and subject_id set to the reconciled principal
identifier, and a conflicting caller-declared subject is overridden.
A permit-level boolean signal records that the subject was reconciled
server-side from the credential rather than caller-asserted; this
Munoz Expires 19 January 2027 [Page 6]
Internet-Draft WIMSE Authorization Evidence July 2026
signal indicates provenance only and does not by itself attest that
the underlying principal is currently valid or active. Whether an
unverified or invalid identity may influence an authorization
decision is governed separately by a configurable policy identity
gate, which in its default configuration evaluates caller-asserted
identity conditions as UNKNOWN: such a condition cannot satisfy an
allow rule and cannot be used to evade a deny. This provenance
signal is not part of the signed binding payload, and the Permit's
binding_request_hash remains the binding-level cryptographic
commitment to the dispatched request.
A deployment MAY additionally carry a delegated subject identifier in
the Permit's decision_details as an optional composition field (for
example, decision_details.delegated_subject) when the agent is acting
on behalf of another principal. Such a value SHOULD identify the
trust domain and identifier of the delegated principal. This is
optional composition guidance: the reference implementation does not
populate a delegated-subject field today, and this profile does not
require it.
When the agent's WIT is presented at authorization time, the WIT's
serial number or thumbprint MAY be carried as an optional composition
field (for example, decision_details.credential_thumbprint) as
additional binding context. This is descriptive metadata that the
reference implementation does not populate today; the Permit's
binding_request_hash remains the cryptographic commitment to the
dispatched request.
3.2. Audit Minimum Requirements Crosswalk
The following table maps Section 11 of [I-D.klrc-aiagent-auth] to
Permit fields used by the provisional reference material in
[KEEL-PERMIT]. Fields marked "optional composition" are not
populated by the reference implementation today.
Munoz Expires 19 January 2027 [Page 7]
Internet-Draft WIMSE Authorization Evidence July 2026
+===============+==============================================+
| Section 11 | Permit Field |
| Requirement | |
+===============+==============================================+
| authenticated | subject_type + subject_id (SPIFFE URI or |
| agent | WIMSE workload identifier) |
| identifier | |
+---------------+----------------------------------------------+
| delegated | decision_details.delegated_subject (optional |
| subject | composition) |
+---------------+----------------------------------------------+
| resource or | resource_provider + resource_model + |
| tool being | action_name |
| accessed | |
+---------------+----------------------------------------------+
| action | action_name + actions_json |
| requested | |
+---------------+----------------------------------------------+
| authorization | decision (allow / deny / challenge) + |
| decision | decision_details |
+---------------+----------------------------------------------+
| timestamp | created_at |
+---------------+----------------------------------------------+
| transaction | idempotency_key + request_fingerprint |
| or request | |
| correlation | |
| identifier | |
+---------------+----------------------------------------------+
| posture | decision_details.code + routing metadata |
| assessment or | (policy/authority reason codes; the |
| risk state | reference implementation does not compute a |
| | risk score) |
+---------------+----------------------------------------------+
| remediation | Permit and closure status transitions (e.g., |
| or revocation | permit.status evaluated / attested / |
| events | completed / expired / revoked; |
| | closure_status; governed-request lifecycle) |
| | recorded as tamper-evident governance events |
+---------------+----------------------------------------------+
Table 1: Section 11 to Permit field crosswalk
The base Permit fields cover several Section 11 elements directly.
The delegated-subject, posture/risk, and remediation/revocation
elements are satisfied only when the corresponding composition fields
or lifecycle records are populated and made available to the
Verifier.
Munoz Expires 19 January 2027 [Page 8]
Internet-Draft WIMSE Authorization Evidence July 2026
3.3. HTTP Message Signature Integration
Section 9.2.2 of [I-D.klrc-aiagent-auth] describes signing of HTTP
request components via HTTP Message Signatures [RFC9421]. The
mandatory signed components include method, request-target, content
digest, and the WIT itself.
The Permit's binding_request_hash covers the canonical bytes of the
request body but does not directly cover request method, request-
target, or selected headers. For deployments requiring header
coverage:
* The Issuer MAY compute an HTTP Message Signature over the full
request and record the signature input string and signature value
in the paired Closure Record (for example, in an
http_message_signature composition field).
* The Closure Record's dispatch_request_digest_v1 continues to
commit to the canonical request body bytes; the HTTP Message
Signature commits to the full request envelope.
* Verifiers of the Permit profile MAY use the HTTP Message Signature
as an additional verification step beyond the binding_request_hash
equality check.
This composition layers RFC 9421 signature coverage on top of
Permit's canonical-body binding without requiring expansion of the
canonicalization function described by the SCITT profile. It is
optional composition guidance; the reference implementation does not
compute or record an HTTP Message Signature today.
3.4. OAuth Access Token Composition
OAuth access tokens issued under the [I-D.klrc-aiagent-auth] model
carry standard claims (client_id, sub, aud, scope) as described by
the JWT profile for OAuth 2.0 access tokens [RFC9068], and MAY carry
profile-specific claims.
For deployments where a runtime access token should reference the
signed pre-execution authorization-evidence record:
* The Authorization Server MAY include an issuer-private claim whose
value identifies the Permit. The claim name permit_id is used
here as an illustrative private claim.
Munoz Expires 19 January 2027 [Page 9]
Internet-Draft WIMSE Authorization Evidence July 2026
* A Resource Server validating the access token MAY retrieve the
referenced Permit and verify the relationship between the in-token
claims (client_id, sub, aud, scope) and the Permit's subject,
resource, and decision fields.
* A token claim that references a Permit MUST NOT be treated as a
substitute for Permit verification. A Verifier claiming
conformance to the SCITT-backed mode of this profile MUST retrieve
and verify the Permit's COSE_Sign1 signature and Receipt per
[I-D.munoz-scitt-permit-profile].
This composition keeps the OAuth access token in its runtime role
(short-lived authorization grant) while making the durable signed
authorization-evidence record retrievable from the token.
This document does not register, reserve, or require the permit_id
claim name. Implementations MAY use a private claim under the
issuer's namespace until registration is sought. The reference
implementation does not emit a Permit reference claim today.
3.5. Transaction Token Linkage
Section 10.5 of [I-D.klrc-aiagent-auth] discusses Transaction Tokens
[I-D.ietf-oauth-transaction-tokens] for downscoped per-call context;
OAuth 2.0 Token Exchange [RFC8693] may be used to obtain such tokens.
A Transaction Token's transaction identifier MAY appear in:
* The Permit's idempotency_key field
* The paired Closure Record's correlation_id field
Both fields permit a Verifier consuming Permits and Transaction
Tokens to correlate the runtime per-call context with the durable
signed evidence record. This profile does not require Transaction
Token use; it specifies the correlation pattern for deployments that
adopt them. The reference implementation carries generic
idempotency_key and correlation_id fields but does not implement RFC
8693 token exchange.
3.6. Authorization Lineage for Delegated Actions
The guidance in this document treats a Permit as the authorization-
evidence record for a single authorized AI agent action. Many WIMSE-
authorized deployments involve delegated authority, where one
authorization decision leads to dependent actions across tools,
services, or models.
Munoz Expires 19 January 2027 [Page 10]
Internet-Draft WIMSE Authorization Evidence July 2026
The companion SCITT profile defines Authority Lineage as an
interoperable verification problem: a Verifier determines whether a
child Permit's Authority Representation is equal to or narrower than
the Authority Representation committed by its parent Permit, under
the declared Comparator Profile. This WIMSE companion profile does
not define Authority Representations or Comparator Profiles.
A Permit emitted in a WIMSE context participates in Authority Lineage
when it includes or references:
* The parent Permit.
* The child's Authority Representation.
* The declared Comparator Profile.
* Sufficient parent evidence for a Verifier to evaluate Authority
Attenuation.
Lineage-capable WIMSE Permits should include or reference enough
evidence to compare delegated-subject identity across parent and
child; this profile does not define a mandatory minimum evidence set.
Relevant evidence can include the SPIFFE subject, delegated_subject,
OAuth client_id, sub, aud, and scope claims, Transaction Token
correlation identifiers, and HTTP Message Signature-covered
components such as method, request-target, content digest, and the
WIT.
Runtime-token references MAY identify the relevant Permit or parent
Permit, but such references MUST NOT replace verification of the
signed Permit itself. A Verifier MUST NOT report successful
Authority Attenuation solely because token claims appear consistent;
Authority Attenuation is established only by verifying the Permit
evidence under the declared Comparator Profile. As noted in
[I-D.munoz-scitt-permit-profile], the reference implementation
enforces attenuation at issuance and verifies it over exported,
chain-committed evidence, limited to the fields published by the
declared Comparator Profile, rather than from a per-Permit signed
Authority Representation.
3.7. Lifecycle State and Eventing Bridge
The provisional reference Permit object carries a status lifecycle.
In the reference implementation the permit status vocabulary (for
example, evaluated, attested, completed, expired, revoked) is
distinct from the closure status and from the governed-request
lifecycle; a deployment building the bridge below selects the
transitions relevant to its eventing.
Munoz Expires 19 January 2027 [Page 11]
Internet-Draft WIMSE Authorization Evidence July 2026
State transitions emit governance-ledger entries with severity and
outcome metadata. [I-D.klrc-aiagent-auth] expects authorization-
state changes (revocation, suspension, posture degradation) to
propagate as Shared Signals Framework (SSF), Continuous Access
Evaluation Profile (CAEP), or Risk Incident Sharing (RISC) signals.
Deployments requiring real-time authorization-state propagation can
provide a bridge from Permit lifecycle entries to SSF / CAEP / RISC
signals. Such a bridge would transform a lifecycle entry of severity
"warning" or "error" affecting a Permit's revoked or expired status
into an outbound SSF event of the appropriate type. This profile
does not specify the bridge normatively; it documents the integration
pattern. The reference implementation does not implement an SSF /
CAEP / RISC bridge today.
A future revision of this profile might specify normative bridge
event formats once production deployments demonstrate stable
patterns.
4. Composition with the SCITT Profile
A SCITT-compatible Permit Signed Statement 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
linked-chain Receipt)
* [I-D.klrc-aiagent-auth] Section 11 audit minimum requirements,
when the audit elements identified in Section 3.2 are populated or
made available by reference
Such a Permit can also participate in Authority Lineage when its
WIMSE identity and delegated-authority evidence are available to the
Verifier. The WIMSE evidence is compositional: it helps a Verifier
cross-check subject identity, delegated-subject context, token
audience and scope, and HTTP request coverage, but it does not
replace the Authority Representation or Comparator Profile defined by
the SCITT profile. As described in [I-D.munoz-scitt-permit-profile],
Authority Attenuation in the reference implementation is enforced at
issuance and is verifiable over exported, chain-committed evidence,
limited to the fields published by the declared Comparator Profile,
rather than from a per-Permit signed Authority Representation.
Munoz Expires 19 January 2027 [Page 12]
Internet-Draft WIMSE Authorization Evidence July 2026
Deployments may also produce legacy Permit evidence records without
the SCITT COSE_Sign1 envelope. Such records can satisfy local
Section 11 evidence requirements, but they are not SCITT-compatible
Permit Signed Statements under [I-D.munoz-scitt-permit-profile] and
are not consumable by SCITT-aware verifiers as Transparent
Statements.
5. Security Considerations
5.1. Token Lifetime versus Evidence Persistence
OAuth access tokens, WITs, and WPTs are short-lived runtime
credentials. Permits are long-lived signed evidence records. The
two may be linked by a Permit reference claim, such as the
illustrative private permit_id claim, 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.
5.2. Subject Identifier Disclosure
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.
5.3. Transaction Token Replay
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, as
described by the SCITT profile. A Transaction Token identifier is
removed from the committed bytes only if it appears under a key the
canonicalization pipeline already strips as volatile or credential
metadata; a deployment that places it under an unstripped key SHOULD
treat it as sensitive input, because it would otherwise enter the
committed request hash. 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.
Munoz Expires 19 January 2027 [Page 13]
Internet-Draft WIMSE Authorization Evidence July 2026
5.4. HTTP Message Signature Composition
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.
5.5. SSF Event Integrity
The descriptive bridge from Permit lifecycle entries to SSF events is
not normative in this profile. Deployments that adopt such a bridge
need to 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.
5.6. Authorization-Lineage Evidence Confusion
WIMSE identity evidence and runtime token claims can support
Authority Lineage verification, but they do not establish Authority
Attenuation by themselves. A token reference to a Permit, a matching
delegated subject, or an HTTP Message Signature over request
components is insufficient unless the underlying Permit evidence is
verified under the declared Comparator Profile.
If delegated-subject evidence is missing, token claims cannot be
cross-checked, HTTP Message Signature coverage is incomplete, or the
relevant parent Permit is unavailable, a Verifier MUST NOT treat the
WIMSE evidence as successful Authority Attenuation. The correct
result is a non-success verdict or a structured indication that the
lineage evidence was insufficient.
6. Privacy Considerations
6.1. Delegated Subject Identification
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.
Munoz Expires 19 January 2027 [Page 14]
Internet-Draft WIMSE Authorization Evidence July 2026
6.2. Trust Domain Disclosure
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.
6.3. Long-Lived Identifiers
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
lifecycle entries.
7. IANA Considerations
This document has no immediate IANA requests. A future revision
might request registration of a Permit reference OAuth claim and an
http_message_signature Closure Record extension.
8. Implementation Status
This section is to be removed before publication as an RFC.
A provisional reference Issuer implementation is published at
[KEEL-PERMIT] and in the keel-api repository under Apache 2.0.
SPIFFE subject typing (subject_type and subject_id) and the
Section 11 audit-minimum field mapping are implemented by the
reference Permit fields. The reference implementation also
establishes the agent subject by server-side reconciliation from the
authenticating credential and records a provenance signal for that
reconciliation (Section 3.1); that signal is recorded for coverage
accounting, indicates provenance rather than principal validity, and
is not part of the signed binding payload. The delegated-subject and
credential-thumbprint fields (Section 3.1), the OAuth Permit-
reference claim (Section 3.4), HTTP Message Signature integration
(Section 3.3), Transaction Token linkage (Section 3.5), and the SSF /
CAEP / RISC bridge (Section 3.7) are not implemented in the reference
implementation and are described here as optional composition
patterns. Authority-lineage attenuation is enforced at issuance and
is verifiable over exported, chain-committed evidence by the separate
verifier package, as described in [I-D.munoz-scitt-permit-profile].
Munoz Expires 19 January 2027 [Page 15]
Internet-Draft WIMSE Authorization Evidence July 2026
9. Acknowledgments
The author thanks the authors of [I-D.klrc-aiagent-auth] -- Pieter
Kasselman, Jeff Lombardo, Yaroslav Rosomakho, Brian Campbell, Nick
Steele, and Aaron Parecki -- 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.
10. References
10.1. Normative References
[I-D.klrc-aiagent-auth]
Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B.,
Steele, N., and A. Parecki, "AI Agent Authentication and
Authorization", Work in Progress, Internet-Draft, draft-
klrc-aiagent-auth-03, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-
auth-03>.
[I-D.munoz-scitt-permit-profile]
Munoz, C., "A SCITT Profile for Pre-Execution AI Action
Authorization Records", Work in Progress, Internet-Draft,
draft-munoz-scitt-permit-profile-01, 27 June 2026,
<https://datatracker.ietf.org/doc/html/draft-munoz-scitt-
permit-profile-01>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119,
DOI 10.17487/RFC2119, March 1997,
<https://www.rfc-editor.org/rfc/rfc2119>.
[RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.
[RFC9052] Schaad, J., "CBOR Object Signing and Encryption (COSE):
Structures and Process", STD 96, RFC 9052,
DOI 10.17487/RFC9052, August 2022,
<https://www.rfc-editor.org/rfc/rfc9052>.
[RFC9421] Backman, A., Ed., Richer, J., Ed., and M. Sporny, "HTTP
Message Signatures", RFC 9421, DOI 10.17487/RFC9421,
February 2024, <https://www.rfc-editor.org/rfc/rfc9421>.
10.2. Informative References
Munoz Expires 19 January 2027 [Page 16]
Internet-Draft WIMSE Authorization Evidence July 2026
[I-D.emirdag-scitt-ai-agent-execution]
Emirdag, P., "AI Agent Execution Profile of SCITT", Work
in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-
execution-00, 13 April 2026,
<https://datatracker.ietf.org/doc/html/draft-emirdag-
scitt-ai-agent-execution-00>.
[I-D.ietf-oauth-transaction-tokens]
Tulshibagwale, A., Fletcher, G., and P. Kasselman,
"Transaction Tokens", Work in Progress, Internet-Draft,
draft-ietf-oauth-transaction-tokens-09, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-oauth-
transaction-tokens-09>.
[I-D.ietf-wimse-arch]
Salowey, J., Rosomakho, Y., and H. Tschofenig, "Workload
Identity in a Multi System Environment (WIMSE)
Architecture", Work in Progress, Internet-Draft, draft-
ietf-wimse-arch-08, 6 July 2026,
<https://datatracker.ietf.org/doc/html/draft-ietf-wimse-
arch-08>.
[I-D.ietf-wimse-identifier]
Rosomakho, Y. and J. Salowey, "Workload Identifier", Work
in Progress, Internet-Draft, draft-ietf-wimse-identifier-
03, 6 July 2026, <https://datatracker.ietf.org/doc/html/
draft-ietf-wimse-identifier-03>.
[I-D.veridom-omp]
Adebayo, T. and O. Apalowo, "Operating Model Protocol
(OMP) Core -- Version 02: Invariant 3 -- Verifiable
Delegation Binding", Work in Progress, Internet-Draft,
draft-veridom-omp-02, 13 May 2026,
<https://datatracker.ietf.org/doc/html/draft-veridom-omp-
02>.
[KEEL-PERMIT]
Keel API, Inc., "Keel Permit Specification", 2026,
<https://github.com/keelapi/keel-
permit/blob/1818c3e04eddf9a2ab6231486ca2cdb2d250ec74/spec/
permit-chain-v1.md>.
[RFC8693] Jones, M., Nadalin, A., Campbell, B., Ed., Bradley, J.,
and C. Mortimore, "OAuth 2.0 Token Exchange", RFC 8693,
DOI 10.17487/RFC8693, January 2020,
<https://www.rfc-editor.org/rfc/rfc8693>.
Munoz Expires 19 January 2027 [Page 17]
Internet-Draft WIMSE Authorization Evidence July 2026
[RFC9068] Bertocci, V., "JSON Web Token (JWT) Profile for OAuth 2.0
Access Tokens", RFC 9068, DOI 10.17487/RFC9068, October
2021, <https://www.rfc-editor.org/rfc/rfc9068>.
Appendix A. Open Issues for -02 and Beyond
This section is to be removed before publication as an RFC.
Open issues:
1. Whether to specify a Permit reference OAuth claim as a normative
addition or to leave private claim names as an implementation
pattern.
2. Whether to define the http_message_signature field in the Closure
Record normatively, including its exact serialization.
3. Whether to specify normative bridge event formats from Permit
lifecycle entries to SSF / CAEP / RISC signals.
4. The exact registration mechanism for a Permit reference claim
(IANA OAuth Parameters registry, private vendor claim, or both).
5. Whether to specify a SPIFFE-required mode, permit WIMSE workload
identifiers [I-D.ietf-wimse-identifier] as an alternative, or
keep subject typing open.
6. Whether WIMSE should define a mandatory minimal delegated-subject
evidence set for lineage-capable Permits, tied to the SCITT
profile's open question of binding the Authority Representation
into a signed binding version.
7. Whether runtime-token claim names used to reference Permits
should be registered or left deployment-specific.
8. Whether WIMSE should define an optional claim registry for
lineage evidence after the SCITT profile stabilizes.
Feedback on any of these is welcome on the WIMSE and SCITT mailing
lists.
Author's Address
Christian Munoz
Keel API, Inc.
Email: christian@keelapi.com
URI: https://keelapi.com
Munoz Expires 19 January 2027 [Page 18]