]> Keel API, Inc.

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

SCITT artificial intelligence AI agent authorization transparency COSE audit evidence accountability 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.

Introduction The SCITT architecture defines an abstract framework for the production, registration, and verification of signed statements made about supply-chain artifacts. Pre-execution authorization decisions for AI agent actions are a class of statement that fits within this architecture but that none of the currently active SCITT profile drafts addresses directly. This document defines such a profile. The profile's central artifact is a "Pre-Execution Authorization Record" (referred to throughout as a "Permit"), which is a signed statement that records (a) the policy that was evaluated, (b) the decision reached, (c) the subject of the decision, (d) the resource and action authorized, and (e) a commitment to the canonical bytes of the request body that will subsequently be dispatched. The pre-execution-to-dispatch cryptographic binding is the distinctive technical contribution of this profile. A Permit is not merely a record that an authorization decision was made; it is a commitment to a specific canonical request, such that any modification of the dispatched bytes between authorization and dispatch is detectable by any third party. As of 2026, several distinct categories of work are converging on runtime AI governance. These include governance capabilities native to application-delivery platforms, security and containment tooling for AI execution environments, enterprise organizational-governance frameworks for AI accountability, and cryptographic execution-trust primitives at the execution boundary. These categories operate at different layers and are largely complementary rather than mutually exclusive. This profile addresses a gap that none of those categories fills directly: the pre-execution decision record. A Permit is a signed, independently verifiable record of the authorization decision reached before an AI agent action is dispatched. This document offers the Permit as a candidate canonical decision artifact for AI execution. Canonical status is earned through profile adoption and interoperable implementation; it is not asserted here. Framing the Permit as a candidate, rather than as the established canonical artifact, preserves the openness expected of standards-track work.

Scope This profile specifies: The Permit object as a SCITT Signed Statement The COSE_Sign1 envelope binding for Permits and paired closure records The Receipt type used to demonstrate inclusion of a Permit in a hash-chain transparency log The canonicalization rules applied to request bytes for digest commitment Composition with the WIMSE pre-execution authorization profile , the SCITT AI agent execution profile , the SCITT refusal events profile , and the OMP human authority binding profile This profile does not specify: A policy language or evaluation engine A runtime, gateway, or proxy for emitting Permits An identity or RBAC model for subjects Live runtime API envelopes or network protocols Storage, indexing, or query semantics for Permits These remain implementation-defined.

Relationship to Existing Work A complete reference specification for the Permit object as deployed by the reference implementation is published at . This document profiles that specification for SCITT consumption. Implementations that conform to the Permit specification at also conform to this profile when they additionally satisfy the COSE_Sign1 envelope and receipt rules in this document.

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 the following SCITT terms as defined in : Signed Statement, Receipt, Transparent Statement, Issuer, Transparency Service, Verifier. Additional terms defined in this document:

Permit:

A Signed Statement of type application/permit-v1+json that records a pre-execution authorization decision and a commitment to the canonical request bytes that will subsequently be dispatched.

Closure Record:

A Signed Statement, paired with a Permit, that records the post-dispatch outcome of an authorized AI agent action, including digests of the bytes received from the provider and the bytes delivered to the client.

binding_request_hash:

A SHA-256 digest committed inside a Permit, computed over the canonical wire-body bytes of the request that will be dispatched. See .

dispatch_request_digest_v1:

A SHA-256 digest committed inside a Closure Record, equal to the corresponding Permit's binding_request_hash when no modification of the request body occurred between authorization and dispatch.

Authorized Request:

The canonical bytes committed by binding_request_hash.

Dispatched Request:

The canonical bytes committed by dispatch_request_digest_v1.

Background: The Permit Object A Permit is a JSON object that records the following information at minimum: An identifier and a project (tenancy) scope A decision: one of "allow", "deny", "challenge" A subject (subject_type plus subject_id) A resource (resource_provider and resource_model) and an action label A policy identifier and a policy version A request fingerprint (a SHA-256 derived from a stripped form of the request semantics; used for replay correlation, not for byte-level commitment) A binding_request_hash (the SHA-256 commitment to canonical request bytes; see ) A creation timestamp A Permit MAY additionally carry decision details, constraints, budgets, routing metadata, and post-execution accounting fields. These are descriptive and do not affect the cryptographic shape of the artifact. A complete normative specification of the Permit object is in .

The Permit Profile of SCITT

Signed Statement A Permit, when its reserved signature field is populated, is a Signed Statement in the sense of . The Signed Statement structure is a COSE_Sign1 envelope . The COSE_Sign1 structure MUST be constructed as follows: The payload is the canonical JSON serialization of the Permit object, encoded as UTF-8 bytes. The protected header MUST contain at minimum: The algorithm identifier (alg). Implementations MUST support EdDSA (alg -8) . Implementations MAY support ES256 (alg -7). A key identifier (kid) resolvable through the Issuer's published key manifest. A content type indicating the payload media type: application/permit-v1+json. The unprotected header MAY contain implementation-specific fields. These MUST NOT affect verification semantics. A Permit Signed Statement is the cryptographic commitment of the Issuer to the authorization decision recorded by the Permit object.

Paired Closure Record For Permits whose decision is "allow" and whose binding_request_hash is non-null, the Issuer MUST produce a paired Closure Record after the authorized request has been dispatched. The Closure Record is a separate Signed Statement that commits to: The dispatch_request_digest_v1: equal to the Permit's binding_request_hash The provider_response_digest_v1: a SHA-256 over the raw bytes received from the provider or tool The client_response_digest_v1: a SHA-256 over the raw bytes delivered to the client response writer Status, timing, and accounting fields The Closure Record's COSE_Sign1 envelope follows the same rules as the Permit's, with the content type application/closure-v2+json. A Permit and its paired Closure Record are cryptographically linked and jointly required for verification. Verifiers MUST check that the Closure Record's dispatch_request_digest_v1 equals the Permit's binding_request_hash. A mismatch indicates that the request authorized by the Permit was not the request that was dispatched; this is the canonical "approved-but-modified" tampering signature.

Receipt This profile uses a linked-chain Receipt format rather than a Merkle tree inclusion proof. The Transparency Service maintains a per-scope hash chain where each entry's record_hash incorporates the previous entry's record_hash, providing append-only tamper-evidence. A Receipt for a Permit consists of: The chain segment from a known signed checkpoint to (and including) the entry that records the Permit's identifier The signed checkpoint itself (a COSE_Sign1 over the latest record_hash, signed by the Transparency Service) Verification of a Receipt requires: Recomputing each entry's record_hash in the supplied segment per the chain entry algorithm specified in Verifying each entry's prev_hash equals the previous entry's record_hash Verifying the checkpoint signature against the Transparency Service's published key Verification time is O(n) in the size of the supplied chain segment, where n is the distance from the supplied checkpoint to the entry under verification. Implementations MAY publish checkpoints periodically to bound n. Discussion of the trade-offs between linked-chain Receipts and Merkle-tree Receipts appears in .

Transparent Statement A Transparent Statement, in the sense of , consists of a Permit (Signed Statement) accompanied by its Receipt and, for "allow" decisions, the paired Closure Record (a second Signed Statement) and its Receipt. The full delivery envelope for one or more Transparent Statements is an audit-export bundle, specified normatively in . Each record in the bundle contains the Permit, the Closure Record (when applicable), and the chain entries that constitute the Receipts.

Transparency Service Role The Issuer and the Transparency Service MAY be the same operator. The reference implementation in combines both roles; this is permitted by the SCITT architecture. Issuers operating in the dual role MUST document this in their published key manifest and Transparency Service operating specification, including the keys used for each role. Issuers MAY externalize the Transparency Service to a third party. In that case, the Permit Signed Statement is registered with the external Transparency Service, which returns a Receipt that the Issuer attaches to the Permit before delivering the Transparent Statement to a verifier.

Verifier Behavior A conforming Verifier MUST: Verify the COSE_Sign1 signature on the Permit against the Issuer's public key, resolved via the kid header. Verify the Receipt: recompute each chain entry's record_hash, verify prev_hash continuity within the supplied segment, verify the checkpoint signature. For Permits with decision "allow" and non-null binding_request_hash: verify the existence and validity of the paired Closure Record. Verify the Closure Record's COSE_Sign1 signature. Verify that the Closure Record's dispatch_request_digest_v1 equals the Permit's binding_request_hash. For Closure Records with status "closed": verify that provider_response_digest_v1 and client_response_digest_v1 are present and that they match the corresponding chain event payloads. A Verifier MUST emit a stable failure code on any integrity violation. The failure-code taxonomy specified in is the normative output of a conforming Verifier for this profile.

Canonicalization The binding_request_hash is computed over canonical bytes derived from the request payload via a documented canonicalization pipeline. The pipeline applies the following steps in order: Strip volatile observability metadata keys from the payload (request IDs, trace IDs, timestamps, idempotency keys). The normative list is in . Strip sensitive credential keys from the payload (authorization headers, API keys). The normative list is in . Canonicalize the resulting payload by sorting object keys lexicographically, removing insignificant whitespace, and encoding as UTF-8 bytes. The pre-canonicalization stripping steps are forensic-safety properties of this profile. Stripping volatile metadata makes the digest stable across retries and observability variation, supporting idempotency-correlated forensic analysis. Stripping sensitive credential keys prevents long-lived hashes from being credential brute-force targets. The canonicalization step in is JCS-inspired but does not currently claim strict JCS compliance. The documented deviations (number serialization edge cases, certain control-character escapes, Unicode normalization stance) are enumerated in . Implementations relying on cross-implementation byte-equivalence MUST validate against the published test vectors in . Future versions of this profile MAY align the canonicalization step with strict RFC 8785 JCS, while preserving the pre-canonicalization stripping steps as profile-specific input transformations. Such a migration would be accompanied by a new chain format version identifier; existing Permits and Receipts remain valid under the older canonicalization indefinitely.

COSE_Sign1 Envelope Binding The reference Permit object specification in signs over the hexadecimal string representation of SHA-256(canonical_json(payload)). The COSE_Sign1 envelope signs over a CBOR Sig_structure. These produce different signed bytes. This profile addresses the difference through a dual-signature envelope. Conforming Issuers MAY emit Permits in either of two modes: Mode A (legacy envelope only): The Permit carries the Ed25519 signature over hex(SHA-256(canonical_json(payload))) as defined in . The Permit is not directly consumable as a SCITT Signed Statement under this profile. Mode B (dual envelope): The Permit carries both the legacy signature and a COSE_Sign1 signature over the same canonical payload bytes. The COSE_Sign1 signature is the Signed Statement for SCITT purposes; the legacy signature provides backward compatibility with non-SCITT-aware Verifiers. Conforming Verifiers MUST accept Mode B Permits and verify the COSE_Sign1 signature. Verifiers MAY accept Mode A Permits in mixed-deployment environments where SCITT compatibility is not required. A future version of this profile MAY deprecate Mode A. This profile-00 does not.

Composition with Adjacent Profiles This profile composes with four adjacent IETF profiles, each addressed in a subsection below. Composition is one-directional in each case: this profile defines reference mechanisms by which a Permit may point to artifacts produced under the adjacent profile. This profile does not require modifications to any adjacent profile. A final subsection situates the profile against the broader category of execution-boundary cryptographic trust primitives.

Composition with WIMSE AI Agent Authentication and Authorization The WIMSE draft specifies how an AI agent obtains an identity and a runtime authorization grant. That draft does not define a signed evidence record of the authorization decision. A Permit emitted by a WIMSE-authorized agent provides such a record. Issuers SHOULD set the Permit's subject_type to "spiffe" and subject_id to the agent's SPIFFE URI when the agent identity is established via WIMSE. The OAuth access token, when present at dispatch time, MAY be referenced through an extension claim in the Permit's decision_details, though this profile does not require it. A companion profile that specifies WIMSE-side integration in detail has been prepared as separate work.

Composition with SCITT AI Agent Execution The SCITT AI agent execution profile defines an AgentInteractionRecord (AIR) for post-execution evidence of agent actions. AIR's existing bridge fields (parent_record_id, workflow_id, trace_id, external_refs) carry the linkage to pre-execution authorization records. Issuers that emit both Permits and AIRs SHOULD populate the AIR's parent_record_id with the corresponding Permit's identifier. When a Closure Record paired with the Permit is also emitted, Issuers SHOULD additionally populate the AIR's external_refs with a reference to the Closure Record's identifier. The mapping makes the pre-execution authorization, the dispatch binding, and the post-execution material-action evidence into a continuous verifiable chain. This profile does not specify any modification to AIR.

Composition with SCITT Refusal Events The SCITT refusal events profile defines four event types (ATTEMPT, DENY, GENERATE, ERROR) for content-generation refusal at the AI system level. A Permit's decision field is more general than refusal-events' event-type field: a Permit decision of "deny" covers content refusal as a special case but also covers policy-level denial outside the content-safety context. Issuers that emit both refusal events and Permits SHOULD reference the corresponding Permit's identifier in the refusal event's external claims. The completeness invariant in composes naturally: every ATTEMPT has exactly one outcome, and the corresponding Permit captures the outcome's authorization context.

Composition with OMP Human Authority Binding The OMP profile defines a human-authority binding artifact that records whether a named Accountable Officer held valid delegated authority for a regulated AI-assisted decision. OMP's central artifact is the authority_binding object, with results BOUND, AUTHORITY_UNBOUND, or EXEMPT. A Permit MAY reference an OMP authority_binding artifact through an optional authority_context field carrying a URI and digest pointer. The reference is informational; this profile does not interpret OMP semantics within the Permit. Verifiers of this profile do not validate the referenced OMP artifact; they verify only that the reference is well-formed and that the digest matches if the artifact is retrieved. The composition pattern: in a regulated AI-assisted decision, the OMP authority_binding artifact records whether the human had authority; the Permit records what the AI was authorized to do. Both records are required for full evidentiary coverage; this profile delivers the AI-action-authorization layer and points to the human-authority layer.

Relationship to Execution-Boundary Trust Primitives Separately from the four adjacent profiles above, a broader category of cryptographic trust primitives operates at the execution boundary itself. Primitives in this category verify the authenticity of an individual execution payload, for example by checking a cryptographic signature over the bytes of a single request or response as that payload crosses the boundary. Such primitives operate at a different layer than the one this profile fills. A Permit is a pre-execution decision record: it captures the authorization decision reached before an AI agent action is dispatched, and this profile binds that decision to the canonical bytes of the dispatched request. An execution-boundary trust primitive instead attests to the authenticity of a payload at the boundary. The two layers compose: they are not the same slot. A deployment may emit a Permit as the pre-execution decision record and also apply an execution-boundary primitive to the payload, with each providing assurance the other does not. This profile neither specifies nor requires an execution-boundary trust primitive. The relationship is noted here as a layering observation, so that implementers positioning a Permit-emitting deployment alongside such a primitive recognize the pre-execution decision record and the execution-boundary authenticity check as distinct and composable layers.

Canonicalization and Receipt Choices The profile makes two implementation choices that diverge from the most common SCITT conventions to date: a JCS-inspired (rather than strict-JCS) canonicalization, and a linked-chain (rather than Merkle-tree) Receipt format. This section names the trade-offs.

Linked-Chain vs. Merkle-Tree Receipts The reference implementation in uses a per-scope linked-list hash chain. Each entry's record_hash incorporates the previous entry's record_hash. Tamper-evidence is established by recomputing the chain segment and verifying continuity. Merkle-tree-based transparency logs (as exemplified by Certificate Transparency ) produce O(log n) inclusion proofs. The linked-chain construction produces O(n) inclusion proofs where n is the distance from the supplied checkpoint to the entry under verification. The SCITT architecture does not mandate Merkle-tree-based receipts. It mandates the integrity property: append-only, tamper-evident, verifiable inclusion. Both constructions satisfy that property. The trade-offs: The linked-chain construction is structurally simpler and matches the reference implementation as deployed today. Inclusion proofs are larger and verification is linear in chain segment size. Periodic checkpoints bound this size. Migration to a Merkle-tree-based transparency log is a separate consideration not addressed in this profile.

Canonicalization The canonicalization pipeline in composes volatile-key stripping and sensitive-key stripping with a JCS-inspired serialization. The stripping steps are forensic-safety properties of this profile and MUST NOT be omitted. The serialization step's deviations from strict RFC 8785 JCS are enumerated in . Implementations producing or consuming Permits across language boundaries MUST validate against the published test vectors. A future revision of this profile MAY adopt strict RFC 8785 JCS for the serialization step, while preserving the stripping steps. Such a transition would be accompanied by a new chain format version identifier; legacy Permits remain valid under the older serialization indefinitely.

Security Considerations

Omission Attacks A Verifier consuming a Transparent Statement learns only about events that appear in the supplied chain. Events that were never recorded are not detectable by this profile in isolation. Architectural deployments that route all AI dispatch through a Permit-emitting layer reduce the risk of unlogged events; architectural review of the deployment is required.

Log Equivocation A Transparency Service operator may, in principle, present different chain views to different Verifiers. This profile does not by itself defend against log equivocation. Deployments requiring such defense SHOULD anchor checkpoints via independent witnesses (RFC 3161 timestamp tokens , externally-anchored notary services, or multi-witness anchoring patterns).

Approval-Dispatch Divergence The two-sided byte binding between Permit.binding_request_hash and the paired Closure Record's dispatch_request_digest_v1 is the canonical defense against modification of the request body between authorization and dispatch. Verifiers MUST check this equality. Equality across two independently signed records (Permit and Closure Record) makes after-the-fact substitution of the authorized artifact detectable: an attacker who modifies the Permit must re-sign it, and an attacker who modifies the Closure Record must re-sign it, and any modification creates a verifiable mismatch.

Canonicalization Brittleness Byte-level canonicalization is sensitive to floating-point representation, number serialization, and Unicode handling. This profile addresses brittleness by: Documenting the canonicalization rules explicitly (, ) Requiring volatile-key and sensitive-key stripping before canonicalization Recommending cross-implementation test vectors Implementations relying on cross-language byte-equivalence MUST validate against the published test vectors.

Credential Containment The sensitive-key stripping step in removes common credential headers (authorization, apikey, x-api-key, and provider-specific variants) from the payload before canonicalization. This prevents long-lived hashes from being credential brute-force targets. Implementations MUST NOT skip the stripping step. The stripping step is a forensic-safety property of this profile, not an optimization.

Subject Identifier Privacy When subject_type is "spiffe" and subject_id is a SPIFFE URI, the subject is identified by trust domain and workload path. When subject_type identifies a human user, the subject_id may directly or indirectly identify a person. Issuers SHOULD consider whether the subject_id requires pseudonymization for the audience consuming the Transparent Statement.

Hashes of Prompt Content Hashes of LLM prompts can be subject to dictionary attacks if the prompt space is small and predictable. The request_fingerprint defined in is computed over a stripped, canonical form, not the raw prompt; it is intended for replay correlation, not for prompt-content confidentiality. The binding_request_hash is computed over canonical request bytes (after stripping) and similarly does not commit the raw prompt. Issuers deploying this profile in contexts where prompt-content confidentiality matters MAY supplement the digests defined here with salted or HMAC-based commitments.

Privacy Considerations

Sensitive Data in Wire Bodies The bytes committed by binding_request_hash and dispatch_request_digest_v1 are the canonical bytes of the request, after stripping volatile and sensitive keys. Implementations MUST verify that no sensitive data outside the stripped key set is present in the request body before computing the hash.

Cross-Border Considerations When Permits and the artifacts they reference cross jurisdictional boundaries, the data minimization properties of the profile (no raw prompt, no raw credential, no raw provider response) apply. Issuers SHOULD nevertheless consider whether the structured fields of the Permit (subject identifiers, policy identifiers, resource identifiers) contain regulated data that requires additional handling.

Logged Identifiers Subject identifiers, policy identifiers, and request fingerprints in the Permit may, in aggregate, support re-identification of end-users or correlation across requests. Issuers SHOULD apply appropriate access controls to the Transparency Service log and audit-export bundles.

IANA Considerations This document requests the registration of a media type for the Permit object: application/permit-v1+json. The proposed registration template: Type name: application Subtype name: permit-v1+json Required parameters: none Optional parameters: none Encoding considerations: 8bit. JSON; UTF-8 encoded; see for canonicalization rules used in hash-input contexts. Security considerations: see of this document. Interoperability considerations: see . Published specification: this document and . Applications that use this media type: SCITT-aware verifiers, AI governance evidence systems, audit log processors. Fragment identifier considerations: as per RFC 6838 for +json structured syntax suffix. Person and email address to contact for further information: Christian Munoz christian@keelapi.com Intended usage: COMMON Restrictions on usage: none Author/Change controller: IETF Provisional registration: no A future revision of this profile MAY request additional registrations for the closure record media type (application/closure-v2+json) and for COSE header parameters specific to this profile.

Implementation Status This section is to be removed before publication as an RFC. A reference Issuer implementation, a reference Verifier implementation (pip-installable as keel-verifier), and a complete Permit specification (including JSON schemas, canonical-JSON rules, chain entry algorithm, and an audit-export bundle format) are published at under the Apache License 2.0. The specification is at version 1.0.0 as of this writing. The implementation does not currently emit COSE_Sign1 envelopes; adding the dual-signature envelope described in this profile is work in progress. A 14-framework control mapping artifact (CCPA, CPPA ADMT, EU AI Act, GDPR Art 17, AICPA SOC 2, NIST AI RMF, ISO/IEC 42001:2023, OWASP LLM Top 10 (2025), MITRE ATLAS, OWASP API Security Top 10 (2023), OWASP ASVS v5.0.0, FedRAMP / NIST SP 800-53 Rev 5, CIS Controls v8.1, PCI DSS v4.0.1) is also published in the same repository.

Acknowledgments The author thanks the SCITT working group, the authors of , , , and for their work on adjacent profiles.

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. 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 a set of algorithms that can be used with the CBOR Object Signing and Encryption (COSE) protocol (RFC 9052). This document, along with RFC 9052, obsoletes RFC 8152. Cryptographic operations like hashing and signing need the data to be expressed in an invariant format so that the operations are reliably repeatable. One way to address this is to create a canonical representation of the data. Canonicalization also permits data to be exchanged in its original form on the "wire" while cryptographic operations performed on the canonicalized counterpart of the data in the producer and consumer endpoints generate consistent results. This document describes the JSON Canonicalization Scheme (JCS). This specification defines how to create a canonical representation of JSON data by building on the strict serialization methods for JSON primitives defined by ECMAScript, constraining JSON data to the Internet JSON (I-JSON) subset, and by using deterministic property sorting. 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. Fraunhofer SIT Bowball Technologies Ltd Microsoft Research This document describes a REST API that supports the normative requirements of the Supply Chain Integrity, Transparency, and Trust (SCITT) Architecture. 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 document describes an experimental protocol for publicly logging the existence of Transport Layer Security (TLS) certificates as they are issued or observed, in a manner that allows anyone to audit certificate authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. 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 version 2.0 of the Certificate Transparency (CT) protocol for publicly logging the existence of Transport Layer Security (TLS) server certificates as they are issued or observed, in a manner that allows anyone to audit certification authority (CA) activity and notice the issuance of suspect certificates as well as to audit the certificate logs themselves. The intent is that eventually clients would refuse to honor certificates that do not appear in a log, effectively forcing CAs to add all issued certificates to the logs. This document obsoletes RFC 6962. It also specifies a new TLS extension that is used to send various CT log artifacts. Logs are network services that implement the protocol operations for submissions and queries that are defined in this document. 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. 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. VeritasChain Standards Organization This document defines a claim set for recording AI content refusal events. The claim set specifies the semantic content and correlation rules for refusal audit trails, independent of any particular serialization format. The claims are designed to be carried within SCITT Signed Statements and verified using SCITT Receipts. This specification addresses claim semantics and verification requirements; it does not mandate a specific encoding. A CDDL definition is provided for CBOR-based implementations, and equivalent JSON representations are shown in an appendix for illustration. This specification provides auditability of logged refusal decisions. It does not define content moderation policies, classification criteria, or what AI systems should refuse. 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. Veridom Ltd Veridom Ltd This -01 version of the Operating Model Protocol (OMP) Core specification introduces Invariant 3: Verifiable Delegation Binding. OMP version -00 establishes two invariants: (1) deterministic routing and (2) immutable trail. These invariants are necessary but not sufficient for adversarial evidentiary defensibility. A tamper- evident record of an unauthorised decision is still an unauthorised decision. This amendment adds Invariant 3, which closes the gap between record existence and authority validity by requiring that every ASSISTED or ESCALATED routing state bind the Named Accountable Officer field to a verifiable DelegationInstrument object at the moment of decision. When no valid binding can be established, the system sets authority_binding_result to AUTHORITY_UNBOUND -- a sealed, positive evidentiary declaration of the absence, not a silent failure. The routing_state is preserved; execution_permission is set to BLOCKED. Three axes are orthogonal: routing_state, authority_binding_result, and execution_permission. This amendment is additive and non-breaking. All twelve existing OMP profile drafts inherit Invariant 3 from the core specification. AUTONOMOUS routing states are exempt unless a profile-specific Watchtower gate requires binding. Keel API, Inc.

Examples

Example Permit (informative) The following is an informative example of a Permit object in its JSON form, before COSE_Sign1 wrapping:

Example Composition Reference (informative) A Permit referencing an OMP authority_binding artifact:

Open Issues for -01 and Beyond This section is to be removed before publication as an RFC. The following issues are open as of this -00 revision: Whether to retain the dual-signature transition pattern (Mode A plus Mode B) or to deprecate Mode A in a future revision. Whether to migrate the canonicalization step to strict RFC 8785 JCS, while preserving the stripping steps. Discussed in . The exact normative format of the linked-chain Receipt: field layout, checkpoint signature binding, partial-segment encoding for transport. Whether the COSE Sign1 protected header should carry chain integrity claims directly (sequence_number, prev_hash, record_hash) as an alternative to relying on a separate Receipt. IANA registration timing: in parallel with this draft, or after WG adoption. Whether to define a strict-mode profile-02 that requires Mode B only and aligns canonicalization with RFC 8785 strictly. Several normative elements are currently specified in rather than in this document: the Permit object's complete field-level specification, the canonical-JSON rules and their deviations from RFC 8785, the chain-entry record_hash algorithm, the Verifier failure-code taxonomy, and the audit-export bundle format. This externalization is intentional for this -00 revision. A future revision is expected to migrate these elements into this document, or into an adopted companion specification, so that the profile is interoperable without dependence on an external document. Feedback on any of these is welcome on the SCITT mailing list.