]> Keel API, Inc.

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

WIMSE SPIFFE OAuth artificial intelligence AI agent authorization audit evidence accountability 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) 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 .

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

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-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 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 and the SCITT profile in

Relationship to Other Specifications This document is a companion to . 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 .

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 and : Permit, Closure Record, binding_request_hash, dispatch_request_digest_v1, Signed Statement, Receipt, Transparent Statement.

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 enumerates the minimum fields an audit event MUST 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 attestation 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 Permit, as specified in and , 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.

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: subject_type MUST be set to "spiffe". subject_id MUST be the agent's SPIFFE URI, in the format spiffe://{trust-domain}/{path}. Implementations MAY also populate a delegated subject identifier in the Permit's decision_details.delegated_subject field when the agent is acting on behalf of another principal. The format of delegated_subject SHOULD identify the trust domain and identifier of the delegated principal. When the agent's WIT is presented at authorization time, the WIT's serial number or thumbprint MAY be recorded in decision_details.credential_thumbprint as additional binding context. This is descriptive metadata; 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 specified in : Section 11 Requirement Permit Field authenticated agent identifier subject_type + subject_id (SPIFFE URI) delegated subject decision_details.delegated_subject 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 attestation or risk state decision_details.code + routing remediation or revocation events status lifecycle (evaluated, bound, dispatched, closed, expired, revoked) + chain entries A Permit emitted by a conforming Issuer is intended to satisfy the currently enumerated Section 11 audit minimum requirements without additional structural extension.

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's http_message_signature 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 in .

OAuth Access Token Composition OAuth access tokens issued under the model carry standard claims (client_id, sub, aud, scope) 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 a claim named permit_id whose value is the Permit's id (a UUID). 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. The permit_id claim MUST NOT be treated as a substitute for Permit verification. Verifiers requiring strong evidence 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. Profile-specific claim registration for permit_id is out of scope for this document. Implementations MAY use a private claim under the issuer's namespace until registration is sought.

Transaction Token Linkage Section 10.4 of permits Transaction Tokens (RFC 8693 ) for downscoped per-call context. 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.

Permit Chains for Multi-Step Authorization 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 multi-step agent workflows or delegated authority, where one authorization decision leads to a sequence of dependent actions across tools, services, or models. The Permit Chains construction specified in extends a single Permit into an ordered, hash-linked sequence of Permits, each committing to the preceding Permit's identifier and digest. WIMSE-style runtime authorization composes with both forms: a single Permit is sufficient evidence for a single authorized action, and a Permit Chain is the natural extension for multi-step or delegated authority, binding the per-step Permits into one verifiable record of the whole authorized sequence. The SPIFFE subject typing, audit minimum requirements crosswalk, HTTP Message Signature integration, and OAuth access token composition guidance in this document applies per-Permit, and therefore applies without modification to each Permit in a chain. This document does not specify the Permit Chain construction itself; that specification is in .

Lifecycle State and Eventing Bridge The Permit object carries a status lifecycle (): evaluated bound dispatched closed expired revoked State transitions emit chain entries with severity and outcome metadata. expects authorization-state changes (revocation, suspension, attestation degradation) to propagate as Shared Signals Framework (SSF), Continuous Access Evaluation Profile (CAEP), or Risk Incident Sharing (RISC) signals. A bridge from Permit chain events to SSF / CAEP / RISC signals SHOULD be provided by deployments requiring real-time authorization-state propagation. The bridge transforms a chain 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. A future revision of this profile MAY specify normative bridge event formats once production deployments demonstrate stable patterns.

Composition with the SCITT Profile A Permit emitted under this WIMSE companion profile and signed under satisfies both: SCITT verifiers (via the COSE_Sign1 Signed Statement envelope and chain-entry Receipt) 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 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.

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

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 (); 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.

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

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

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

Implementation Status This section is to be removed before publication as an RFC. A reference Issuer implementation is published at 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.

Acknowledgments The author thanks the authors of — 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 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. Defakto Security AWS Zscaler Ping Identity Open AI This document proposes a model for authentication and authorization of AI agent interactions. It leverages existing standards such as the Workload Identity in Multi-System Environments (WIMSE) architecture and OAuth 2.0 family of specifications. Rather than defining new protocols, this document describes how existing and widely deployed standards can be applied or extended to establish agent authentication and authorization. By doing so, it aims to provide a framework within which to use existing standards, identify gaps and guide future standardization efforts for agent authentication and authorization. Keel API, Inc. This document specifies a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for pre-execution authorization records of AI agent actions. The profile defines a Signed Statement type, the "Pre-Execution Authorization Record" (also called a Permit), that records a policy-evaluated decision to allow, deny, or challenge an AI agent action before that action is dispatched to a model provider, tool, or service. The profile cryptographically binds the authorization decision to the canonical bytes of the request that is subsequently dispatched, enabling independently verifiable "authorized request equals dispatched request" assertions. The profile composes with adjacent profiles for human-authority binding, post-execution material-action evidence, and content-refusal events, referenced rather than replicated. 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. This document describes the format of a request sent to a Time Stamping Authority (TSA) and of the response that is returned. It also establishes several security-relevant requirements for TSA operation, with regards to processing requests to generate responses. [STANDARDS-TRACK] Fraunhofer SIT Microsoft Research Microsoft Research ARM Traceability in supply chains is a growing security concern. While verifiable data structures have addressed specific issues, such as equivocation over digital certificates, they lack a universal architecture for all supply chains. This document defines such an architecture for single-issuer signed statement transparency. It ensures extensibility, interoperability between different transparency services, and compliance with various auditing procedures and regulatory requirements. VERIDIC Inc. This document defines a SCITT (Supply Chain Integrity, Transparency, and Trust) profile for creating independently verifiable, tamper- evident records of autonomous AI agent actions. The profile defines the AgentInteractionRecord (AIR) as the COSE_Sign1 signed statement payload for material agent actions; maps SCITT roles to the agent execution context, with the Agent Operator as Issuer and an independent Evidence Custodian as Transparency Service; specifies Registration Policy requirements including hash chain integrity, temporal ordering, and sequence completeness; defines a redaction receipt mechanism for privacy-preserving evidence custody; and provides compliance mappings to EU AI Act Articles 12 and 19, DORA, NIST AI RMF, MAS AI Risk Management Guidelines, PCI DSS v4.0, and MiFID II. Veridom Ltd Veridom Ltd This document obsoletes draft-veridom-omp-00. The Operating Model Protocol (OMP) defines a deterministic routing and tamper-evident evidence architecture for consequential AI decisions. This document specifies OMP Core version 01, which adds Invariant 3: Verifiable Delegation Binding. Every ASSISTED or ESCALATED routing state must bind the Named Accountable Officer to a verifiable DelegationInstrument at the time of decision. When valid binding cannot be established, the system records AUTHORITY_UNBOUND -- a sealed, positive evidentiary state. This update is additive and backward-compatible with OMP Core version 00. Keel API, Inc.

Open Issues for -01 and Beyond 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.