]> Keel API, Inc.

christian@keelapi.com https://keelapi.com

Security Network Working Group WIMSE SPIFFE AI agents authorization audit evidence permit This document specifies a companion profile to the AI Agent Authentication and Authorization draft , 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 . 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.

Introduction The AI Agent Authentication and Authorization draft 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 , 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.

Scope This profile specifies: How to populate Permit subject fields with SPIFFE URIs A crosswalk from Section 11 of to Permit fields Optional integration with HTTP Message Signatures 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 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 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 and the provisional reference material in Authority Representation formats, Comparator Profiles, or Authority Attenuation rules; those are defined by the SCITT profile or by other companion profiles

Relationship to Other Specifications This document is a companion to . That document defines a SCITT-compatible Permit Signed Statement and specifies the COSE_Sign1 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 . Deployments that use WIMSE workload identity may also consult the WIMSE architecture and workload identifier documents for the identity context this profile records.

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 when, and only when, they appear in all capitals, as shown here. This document uses terminology from : 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 : 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 as provisional reference material for one implementation of these concepts.

Background

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 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 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.

The Permit as Evidence Record A SCITT-compatible Permit Signed Statement, as specified in , 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. provides provisional reference material and an implementation source for the Permit object.

The WIMSE Authorization-Evidence Profile

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 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 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.

Audit Minimum Requirements Crosswalk The following table maps Section 11 of to Permit fields used by the provisional reference material in . Fields marked "optional composition" are not populated by the reference implementation today. Section 11 Requirement Permit Field authenticated agent identifier subject_type + subject_id (SPIFFE URI or WIMSE workload identifier) delegated subject decision_details.delegated_subject (optional composition) resource or tool being accessed resource_provider + resource_model + action_name action requested action_name + actions_json authorization decision decision (allow / deny / challenge) + decision_details timestamp created_at transaction or request correlation identifier idempotency_key + request_fingerprint posture assessment or risk state decision_details.code + routing metadata (policy/authority reason codes; the reference implementation does not compute a risk score) remediation or revocation events Permit and closure status transitions (e.g., permit.status evaluated / attested / completed / expired / revoked; closure_status; governed-request lifecycle) recorded as tamper-evident governance events 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.

HTTP Message Signature Integration Section 9.2.2 of describes signing of HTTP request components via HTTP Message Signatures . 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.

OAuth Access Token Composition OAuth access tokens issued under the model carry standard claims (client_id, sub, aud, scope) as described by the JWT profile for OAuth 2.0 access tokens , 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. 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 . 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.

Transaction Token Linkage Section 10.5 of discusses Transaction Tokens for downscoped per-call context; OAuth 2.0 Token Exchange 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.

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. 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 , 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.

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. State transitions emit governance-ledger entries with severity and outcome metadata. 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.

Composition with the SCITT Profile A SCITT-compatible Permit Signed Statement emitted under this WIMSE companion profile and signed under satisfies both: SCITT verifiers (via the COSE_Sign1 Signed Statement envelope and linked-chain Receipt) Section 11 audit minimum requirements, when the audit elements identified in 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 , 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. 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 and are not consumable by SCITT-aware verifiers as Transparent Statements.

Security Considerations

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.

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.

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.

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 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.

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.

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.

Privacy Considerations

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.

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.

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.

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.

Implementation Status This section is to be removed before publication as an RFC. A provisional reference Issuer implementation is published at 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 (); 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 (), the OAuth Permit-reference claim (), HTTP Message Signature integration (), Transaction Token linkage (), and the SSF / CAEP / RISC bridge () 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 .

Acknowledgments The author thanks the authors of -- 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 and for related work.

Concise Binary Object Representation (CBOR) is a data format designed for small code size and small message size. There is a need to be able to define basic security services for this data format. This document defines the CBOR Object Signing and Encryption (COSE) protocol. This specification describes how to create and process signatures, message authentication codes, and encryption using CBOR for serialization. This specification additionally describes how to represent cryptographic keys using CBOR. This document, along with RFC 9053, obsoletes RFC 8152. This document describes a mechanism for creating, encoding, and verifying digital signatures or message authentication codes over components of an HTTP message. This mechanism supports use cases where the full HTTP message may not be known to the signer and where the message may be transformed (e.g., by intermediaries) before reaching the verifier. This document also describes a means for requesting that a signature be applied to a subsequent HTTP message in an ongoing HTTP exchange. In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. This specification defines a protocol for an HTTP- and JSON-based Security Token Service (STS) by defining how to request and obtain security tokens from OAuth 2.0 authorization servers, including security tokens employing impersonation and delegation. This specification defines a profile for issuing OAuth 2.0 access tokens in JSON Web Token (JWT) format. Authorization servers and resource servers from different vendors can leverage this profile to issue and consume access tokens in an interoperable manner. Keel API, Inc.

Open Issues for -02 and Beyond This section is to be removed before publication as an RFC. Open issues: Whether to specify a Permit reference OAuth claim as a normative addition or to leave private claim names 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 lifecycle entries to SSF / CAEP / RISC signals. The exact registration mechanism for a Permit reference claim (IANA OAuth Parameters registry, private vendor claim, or both). Whether to specify a SPIFFE-required mode, permit WIMSE workload identifiers as an alternative, or keep subject typing open. 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. Whether runtime-token claim names used to reference Permits should be registered or left deployment-specific. 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.