]> Keel API, Inc.

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

Security Network Working Group SCITT transparency AI agents authorization permit 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 authorized. When the paired Closure Record carries a dispatch digest, a Verifier can compare the authorized-request digest against the recorded dispatched-request digest; on the managed dispatch path the reference implementation additionally enforces this equality before the request is sent. This revision also introduces authorization-lineage vocabulary. It defines how a Verifier can determine whether the authority conveyed by a child Permit is equal to or narrower than the authority conveyed by its parent (attenuation), given a signed or chain-committed Authority Representation and a declared Comparator Profile. The Permit remains an evidence artifact; this profile specifies the evidence a Verifier needs to make that determination, not a delegation or policy protocol. 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 central mechanism this profile defines. 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. This revision extends the Permit model with authorization-lineage vocabulary. It specifies the evidence a Verifier would use to determine whether delegated authority was cryptographically bound to a parent, correctly derived, and attenuated (equal to or narrower than the parent) under a declared comparator profile. Whether that evidence is carried in the per-Permit Signed Statement, in an accompanying export, or in a transparency-log entry is a deployment and versioning question; describes what the reference implementation does today. 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 interoperable 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 open standardization.

Scope This profile specifies: The COSE_Sign1 encoding of the Permit object as a SCITT Signed Statement The COSE_Sign1 envelope binding for Permits and paired closure records A linked-chain Receipt construction used to demonstrate inclusion of a Permit in a hash-chain transparency log The canonicalization rules applied to request bytes for digest commitment The authorization-lineage requirements that allow a Verifier to determine whether child authority is equal to or narrower than the parent authority from which it descends Composition with the AI agent authentication and authorization draft , 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 provisional reference specification and implementation source for the Permit object is published at . This revision profiles the interoperable elements of that work for SCITT consumption. Future revisions are expected to incorporate these interoperability requirements directly into this document or another standards-track companion specification.

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.

Authority Representation:

A deterministic representation of the authority committed by a Permit, suitable for cryptographic binding and comparison by a Verifier.

Comparator Profile:

A named set of deterministic rules by which a Verifier compares two Authority Representations.

Authority Attenuation:

The property that delegated authority conveyed by a child Permit is demonstrably no broader than the authority committed by its parent Permit under the declared Comparator Profile.

Authority Lineage:

A verifiable parent/child Permit relationship in which each child Permit cryptographically identifies its parent, commits to its own Authority Representation, and can be checked for Authority Attenuation.

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 identifier 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 ) For child Permits, a parent Permit identifier and enough authority-lineage evidence for a Verifier to evaluate Authority Attenuation under the declared Comparator Profile A creation timestamp A Permit MAY additionally carry decision details, constraints, and other implementation-defined metadata. These are descriptive and do not affect the cryptographic shape of the artifact unless explicitly committed by this profile or by an identified extension. This revision references as a provisional reference specification and implementation source. Future revisions are expected to incorporate these interoperability requirements directly into this document or another standards-track companion specification.

The Permit Profile of SCITT

Signed Statement A SCITT-compatible Permit Signed Statement is a COSE_Sign1 envelope whose payload is the Permit object, and is a Signed Statement in the sense of . A Permit carrying only the legacy reserved signature field is not a SCITT Signed Statement under this profile (see ). 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. The alg identifiers above are requirements on a SCITT-conformant COSE_Sign1 encoding. The reference implementation does not yet emit COSE_Sign1; see and .

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 reference implementation does not yet fully meet this requirement (see ). The Closure Record is a separate Signed Statement that commits to: The dispatch_request_digest_v1: a SHA-256 over the canonical request body bytes placed on the wire at dispatch time. For an unmodified managed dispatch this equals 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. Until a closure-record media type is registered, deployments MAY use an implementation-specific content-type value documented in the Issuer's profile metadata; application/closure-v2+json is a candidate for a future registration (see ). 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 means the request recorded as authorized differs from the request recorded as dispatched. In the reference implementation the dispatched digest is copied from the authorized digest, so a mismatch indicates inconsistent or substituted signed evidence; managed-path approval-versus-dispatch divergence is instead rejected at dispatch, before the request is sent (see ). In the reference implementation the Closure Record is separately signed but is not a separately stored artifact: it is carried as fields on the Permit record and mirrored into a governance-ledger event. Its dispatch_request_digest_v1 is set equal to the Permit's binding_request_hash by copying the committed value (see ). The application/closure-v2+json media type is proposed by this profile; the reference implementation uses closure_v2 and closure_v3 as internal version identifiers rather than as media types.

Receipt This revision describes 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. The linked-chain construction is included to describe the reference implementation and the intended integrity property; the exact transport encoding remains provisional in this revision. In the reference implementation, an entry's record_hash commits the entry's identity fields and the predecessor's record_hash, establishing append-only linkage; entry payloads are covered by a separate periodic integrity-digest layer rather than by record_hash itself. A conforming Transparency Service MUST integrity-protect entry payloads either by including a digest of the payload in record_hash or by covering the payload digest in a signed checkpoint or integrity-digest structure whose covered fields, hash algorithm, and verification procedure are specified by the selected Receipt profile. 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. In the reference implementation this is an Ed25519 signature over a composite hash formed from every per-scope chain head (each scope's latest sequence number and record_hash), rather than over a single entry. A COSE_Sign1 checkpoint is a possible future encoding; this profile does not require a specific checkpoint signature encoding. Verification of a linked-chain Receipt requires: Recomputing each entry's record_hash in the supplied segment using the declared chain-entry algorithm 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. A delivery envelope for one or more Transparent Statements may be an audit-export bundle. defines one such bundle format as a reference implementation artifact. Bundle formats are not normative in this revision; Verifiers need only receive the Signed Statements and Receipt material required by this profile.

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. Registration APIs such as those described in are out of scope for this profile. 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 Issuer's signature on the Permit against the Issuer's public key, resolved via the key identifier. For a SCITT-compatible Permit this is the COSE_Sign1 signature; see for the signature forms the reference implementation emits today. Verify any Receipt required by the selected receipt construction. For the linked-chain construction described in this revision: recompute each chain entry's record_hash, verify prev_hash continuity within the supplied segment, and 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 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 response bytes or the payload digests in a specified, integrity-protected chain-entry payload format. For child Permits: verify the parent Permit reference; obtain the child and parent Authority Representations from the Signed Statement or from referenced signed or chain-committed evidence; identify the declared Comparator Profile; and determine whether the child Authority Representation is equal to or narrower than the parent Authority Representation over the fields the Comparator Profile publishes. A Verifier MUST emit a stable failure code or a defined non-success verdict on any integrity or authority-lineage violation. A Verifier MAY emit structured claims describing parent binding, child authority commitment, and Authority Attenuation. Future revisions may define an interoperable claim registry for these claims.

Authority Lineage A Permit may be issued as a child of another Permit. Parent/child linkage alone is not sufficient for interoperability: a chain is useful only when an independent Verifier can determine whether the authority committed by each child is equal to or narrower than the authority committed by its parent. This profile therefore defines Authority Lineage as a verification problem. It does not define a policy language, authorization engine, RBAC model, storage schema, or runtime delegation protocol. A child Permit that participates in Authority Lineage MUST: Cryptographically identify its parent Permit. Commit to its own Authority Representation, signed or chain-committed. Identify or reference the Comparator Profile under which its Authority Representation is to be compared with the parent Authority Representation. Include or reference enough evidence for a Verifier to obtain the parent Authority Representation and evaluate Authority Attenuation. A Comparator Profile specifies deterministic comparison rules for one or more Authority Representation formats. Comparator Profiles are extensible and may be defined for different representations, such as JSON, CBOR, token claims, or other signed/referenced authority material. When an Authority Representation is JSON, implementations SHOULD use RFC 8785 canonicalization before hashing or signing compared authority material. A Verifier implementing the declared Comparator Profile MUST determine whether the Authority Representation committed by a child Permit is equal to or narrower than that committed by its parent Permit. If the available evidence is insufficient to make this determination, the Verifier MUST NOT report successful Authority Attenuation. A Verifier can reproduce Authority Attenuation only over the fields enumerated by the declared Comparator Profile. Where an Issuer enforces additional authority fields at issuance, the coverage of independent verification is correspondingly partial. Issuers SHOULD publish the full set of authority fields they enforce, so that a Verifier can determine the coverage of any attenuation verdict. In the reference implementation the current maximum signed binding version signs an authority-chain digest and the subject; Authority Attenuation is enforced at issuance and independently re-verified over exported, chain-committed evidence using a Comparator Profile whose published field set is currently narrower than the field set the Issuer enforces. See and .

Canonicalization The binding_request_hash is computed over canonical bytes derived from the request payload via a documented canonicalization pipeline. This revision defines the canonicalization pipeline at the level needed to describe the digest commitment. Exact field lists and test vectors are provisional reference material in until migrated into this document or an adopted companion specification. The pipeline applies the following steps: Strip volatile observability metadata keys from the payload (for example, request IDs, trace IDs, span IDs, timestamps, idempotency keys). Strip sensitive credential keys from the payload (authorization headers, API keys, provider-specific API-key headers, proxy-authorization). Canonicalize the resulting payload by sorting object keys, removing insignificant whitespace, and encoding as UTF-8 bytes. In the reference implementation steps 1 and 2 are a single key-removal pass over the union of the volatile-key and credential-key sets; the result is identical to applying them in sequence. 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 reduces the risk that long-lived hashes become credential brute-force targets for the stripped key set. The reference implementation provides two serializations, selected by binding version. Binding versions v1 through v4 use a JCS-inspired serialization (lexicographic key sort, minimal separators, UTF-8) that does not claim strict RFC 8785 conformance. Binding versions v5 through v7 use a strict RFC 8785 (JCS) implementation via a published library. The default and production-deployed binding version is deployment configuration and is not fixed by this profile. Implementations relying on cross-implementation byte-equivalence SHOULD validate against published test vectors for the declared binding version. A future revision of this profile may require strict RFC 8785 JCS for all serializations, 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 defines a legacy evidence-record signature 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. Only the COSE_Sign1 form is a SCITT Signed Statement under this profile. Issuers may emit either legacy evidence records or SCITT-compatible Permit Signed Statements: Legacy evidence record: The Permit carries the legacy Ed25519 signature over hex(SHA-256(canonical_json(payload))). The Permit is not a SCITT Signed Statement under this profile. SCITT-compatible Permit Signed Statement: The Permit carries a COSE_Sign1 signature over the canonical payload bytes. It MAY also carry the legacy signature for backward compatibility with non-SCITT-aware Verifiers. Conforming Verifiers MUST verify the COSE_Sign1 signature for SCITT-compatible Permit Signed Statements. Verifiers MAY accept legacy evidence records in mixed-deployment environments, but such acceptance is outside SCITT conformance for this profile. The reference implementation signs the UTF-8 bytes of the hexadecimal SHA-256 digest of the canonical payload using Ed25519. Two hexadecimal conventions coexist and are not interchangeable: permit binding signs the bare lowercase hex digest, while compliance exports and checkpoints sign the "sha256:"-prefixed form. Implementations that verify legacy evidence-record signatures, compliance exports, or checkpoints MUST use the hexadecimal convention defined for the surface being verified. No COSE_Sign1 envelope is emitted today; the alg -8 and alg -7 identifiers in are requirements on a future SCITT-conformant encoding, not descriptions of the current output. A future version of this profile may remove discussion of the legacy evidence-record signature. This profile does not.

Composition with Adjacent Profiles This profile composes with four adjacent efforts, 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 AI Agent Authentication and Authorization The AI agent authentication and authorization 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 such an 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 SPIFFE/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. The companion WIMSE authorization-evidence profile specifies WIMSE-side integration in detail, including delegated-subject evidence and runtime-token references.

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: the corresponding Permit captures the authorization context for the recorded outcome.

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 This revision documents two implementation choices that diverge from the most common SCITT conventions to date: a JCS-inspired (rather than strict-JCS) canonicalization for legacy binding versions, and a linked-chain (rather than Merkle-tree) Receipt construction. This section names the trade-offs and identifies the places where future revisions need stricter interoperable definitions.

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. COSE-based receipt profiles such as illustrate one Merkle-tree receipt encoding that a future revision could profile as an alternative. 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 simple and matches the provisional reference implementation. 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 version-selected serialization. The stripping steps are forensic-safety properties of this profile and MUST NOT be omitted. For legacy binding versions the serialization is JCS-inspired and its deviations from strict RFC 8785 JCS are provisional reference material in ; for binding versions v5 through v7 the reference implementation uses a strict RFC 8785 library. Implementations producing or consuming Permits across language boundaries SHOULD validate against published test vectors for the declared binding version. A future revision of this profile may require strict RFC 8785 JCS for all serializations, 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

Scope of Guarantees and Omission Attacks The guarantees of this profile are bounded by where the Permit-emitting layer sits. On the managed dispatch path the reference implementation enforces the authorization decision before dispatch; in decision-only issuance mode the profile supplies an issuer-signed record of the authorization decision and of the dispatch digest reported by the caller, and does not enforce dispatch of only the authorized bytes nor guarantee that every executed action was recorded. 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. This profile provides integrity and tamper-evidence for what is recorded; it does not by itself prove that every executed action was recorded. That completeness gap is relocated, not closed, by the transparency log, and can only be mitigated (never fully closed) by reconciliation against independent execution records. The reference implementation prevents dispatch of a denied request only for traffic that transits its managed proxy or execute datapath, where permit issuance precedes dispatch and a deny (or any stage error) is fail-closed. On the decision-only issuance surface, the caller dispatches the request with its own credential; the profile then records a caller-reported outcome unless the caller returns a signed Closure Record. The reference implementation classifies this honestly with a graded receipt-verification status (independently_verifiable / tamper_evident_incomplete / caller_report_unverified / unverified). This profile is not a network access control and does not prevent an agent from reaching a provider by a path the Issuer never sees; architectural review of the deployment is required to bound the omission surface.

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). In the reference implementation, periodic integrity checkpoints are timestamped with RFC 3161 tokens from a plan-tiered set of Time-Stamping Authorities (the base tier uses a free TSA plus one commercial TSA; higher tiers use two accredited commercial TSAs; customer-managed TSAs are available at the top tier) and are additionally published to an external object store. These witnesses cover the checkpoint composite hash at its publication cadence, not each individual Permit or Receipt; anchoring strengthens witness independence, not per-record granularity, and does not by itself defend against the unlogged events of .

Approval-Dispatch Divergence The equality between Permit.binding_request_hash and the paired Closure Record's dispatch_request_digest_v1 is the primary evidence-level check for divergence between the request recorded as authorized and the request recorded as dispatched. Verifiers MUST check this equality. In the reference implementation the Closure Record's dispatch_request_digest_v1 is set equal to the Permit's binding_request_hash by copying the committed value, not by re-measuring the dispatched bytes at closure time. The independent check that the bytes placed on the wire equal the authorized bytes is performed at dispatch, where a mismatch is rejected before the request is sent; this runtime check is enforced but is not itself a second signed record. The two independently signed records (Permit and Closure Record) therefore make after-the-fact substitution of either signed artifact detectable, and the runtime seal makes an authorized-versus-dispatched divergence non-dispatchable on the managed path. A Verifier that holds only the two Signed Statements can detect substitution of a recorded artifact, but cannot by itself confirm that the bytes actually dispatched equalled the authorized bytes; that assurance comes from the managed-path runtime check.

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 SHOULD validate against published test vectors for the declared binding version.

Credential Containment The sensitive-key stripping step in removes common credential headers (authorization, apikey, x-api-key, provider-specific API-key headers, and proxy-authorization) from the payload before canonicalization. This reduces the risk that long-lived hashes become credential brute-force targets for the stripped key set. 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 and structured request bodies can be subject to dictionary attacks if the input space is small, predictable, or low entropy. The request_fingerprint is computed over a stripped, canonical form and is intended for replay correlation, not for prompt-content confidentiality. The binding_request_hash is computed over canonical request bytes after stripping; it does not reveal the raw request by itself, but it can still allow confirmation attacks against guessed request bodies. Issuers deploying this profile in contexts where prompt-content confidentiality or resistance to confirmation attacks is material SHOULD supplement the digests defined here with salted or keyed (HMAC) commitments, and SHOULD document the associated salt or key management.

Authorization Lineage Ambiguity Authority Lineage is only meaningful when the parent Permit, child Permit, Authority Representations, and declared Comparator Profile are all available to the Verifier. A child Permit that merely names a parent Permit, without committing to comparable authority material, does not establish Authority Attenuation. Comparator ambiguity is a privilege-amplification risk. If two conforming Verifiers can reach different conclusions about whether a child Authority Representation is equal to or narrower than its parent, the Comparator Profile is not sufficiently deterministic for interoperable verification. Implementations SHOULD publish test vectors for each Comparator Profile they use. If a Verifier cannot obtain the parent Permit, cannot verify the child's Authority Representation commitment, cannot identify the declared Comparator Profile, or cannot execute that Comparator Profile over the supplied evidence, it MUST NOT report successful Authority Attenuation.

Attenuation Is Issuer-Enforced In the reference implementation, Authority Attenuation is enforced at issuance: the Issuer refuses to mint a child Permit whose Authority Representation broadens its parent's, and records the denial in its tamper-evident event log. The current maximum signed binding version additionally signs an authority-chain digest and the subject, binding each Permit to its lineage and subject identity. A separate verifier package independently re-evaluates child-to-parent authority and delegation-denial correctness over exported, chain-committed evidence. Two limits bound independent attenuation verification. First, the comparison operates over exported, chain-committed evidence and the published Comparator Profile, not over a per-Permit signed authority envelope. Second, the published Comparator Profile currently enumerates a subset of the authority-envelope fields the Issuer actually enforces; until the published profile matches the enforced field set, an independent Verifier can reproduce attenuation only over the published fields. (A separate verifier claim adjudicates exported authority-chain evidence under its own field semantics; the coverage limitation described here applies to the published Comparator Profile path.) Both gaps are tracked in .

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. The stripping step removes a fixed set of credential and volatile keys; it does not detect arbitrary sensitive content elsewhere in the body. Issuers SHOULD apply a data-hygiene control (an opacity or erasure gate) so that sensitive values outside the stripped key set do not enter the committed bytes, and SHOULD classify derived fields by whether they are observed, estimated, or inferred rather than presenting them as undifferentiated fact.

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, following the procedures of : application/permit-v1+json. The proposed registration template: Type name: application Subtype name: permit-v1+json Required parameters: N/A Optional parameters: N/A Encoding considerations: binary. JSON; UTF-8 encoded. Hash-input canonicalization considerations are described in . Security considerations: see of this document. Interoperability considerations: see , , and of this document. Published specification: this document. Applications that use this media type: SCITT-aware verifiers, authorization-evidence log processors, and audit-export consumers. Fragment identifier considerations: The syntax and semantics are as specified for application/json and for the +json structured syntax suffix . This media type defines no additional fragment identifier semantics. Additional information: Deprecated alias names: N/A Magic number(s): N/A File extension(s): N/A Macintosh file type code(s): N/A Person and email address to contact for further information: Christian Munoz christian@keelapi.com Intended usage: COMMON Restrictions on usage: N/A Author: Christian Munoz Change controller: Christian Munoz, until publication as an IETF-stream RFC; the IESG thereafter. Provisional registration: yes 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 (keel-api), a separate reference Verifier distributed as the keel-verifier package, and a Permit specification are published under open-source licenses. The following reflects the reference implementation as of this revision: Signatures are Ed25519 over a hexadecimal SHA-256 digest string. COSE_Sign1 envelopes are not emitted; adding them is work in progress. A published key manifest with append-only rotation history is implemented. Canonicalization is version-branched: JCS-inspired for binding versions v1 through v4, and strict RFC 8785 (via a published library) for v5 through v7. The maximum signed binding version is v7; v7 signs the v6 field set plus an authority-chain digest, the subject identifier and type, and quota, account, and organization identifiers, so the per-Permit binding commits to the authority-chain digest and the subject. The binding_request_hash is sealed at dispatch time to the canonical bytes of the request placed on the wire, and a mismatch is rejected before dispatch. The per-scope linked chain (record_hash/prev_hash linkage), composite signed checkpoints, RFC 3161 multi-TSA anchoring, external checkpoint publication, and a separate integrity-digest layer over entry payloads are implemented. Closure Records are produced best-effort: inline at response time, with a deferred reconciliation sweep. The reference Issuer therefore does not yet meet the closure requirement: Permits that never reach usage reporting are not currently closed or flagged by that sweep. Closure completeness is work in progress. Authority lineage: parent/child linkage, a canonical Authority Representation and its hash, a versioned Comparator Profile registry, and issuance-time attenuation enforcement (with one feature-flagged layer) are implemented, and v7 signs the authority-chain digest and subject. The keel-verifier package verifies v7 bindings and can compare child-to-parent authority and check delegation-denial correctness over exported, chain-committed evidence. The published comparator registry currently covers a subset of the authority-envelope fields the Issuer enforces; aligning them is work in progress (see ). The reference Verifier is distributed as a separate package and is under active revision; verifier output formats are not yet stable across versions. Governance-control mappings are also available in the reference repository as implementation documentation. They are out of scope for this protocol profile.

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

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. 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. Traceability in supply chains is a growing security concern. While Verifiable Data Structures (VDSs) 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 and interoperability between different transparency services as well as compliance with various auditing procedures and regulatory requirements. 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 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] This document defines procedures for the specification and registration of media types for use in HTTP, MIME, and other Internet protocols. This memo documents an Internet Best Current Practice. A content media type name sometimes includes partitioned meta- information distinguished by a structured syntax to permit noting an attribute of the media as a suffix to the name. This document defines several structured syntax suffixes for use with media type registrations. In particular, it defines and registers the "+json", "+ber", "+der", "+fastinfoset", "+wbxml" and "+zip" structured syntax suffixes, and provides a media type structured syntax suffix registration form for the "+xml" structured syntax suffix. This document is not an Internet Standards Track specification; it is published for informational purposes. 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 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. 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 -02 and Beyond This section is to be removed before publication as an RFC. The following issues are open as of this -01 revision: Whether to retain discussion of legacy evidence records, or to make the next revision describe only SCITT-compatible Permit Signed Statements. Whether to require strict RFC 8785 JCS for all binding versions, while preserving the stripping steps. Discussed in . The exact normative format of the linked-chain Receipt: field layout, checkpoint signature binding (including whether the checkpoint commits a composite of all per-scope chain heads or a single head), and 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. Aligning the published Comparator Profile field set with the larger authority-envelope field set the Issuer enforces, so that independent attenuation verification reproduces the full enforced comparison rather than a published subset; and whether to sign the full Authority Representation (not only the authority-chain digest) into a future binding version. A closure-completeness backstop for Permits that are authorized and dispatched but never reach usage reporting, which the current deferred reconciler does not close or flag. IANA registration timing: in parallel with this draft, or after WG adoption. Whether to define a strict-mode profile that requires only SCITT-compatible Permit Signed Statements and aligns canonicalization with RFC 8785 strictly. Whether Comparator Profiles should be registered through IANA, an IETF-maintained registry, or implementation-defined profile identifiers. Whether a JSON Authority Representation profile should be defined normatively here, or left as an informative example until more implementations exist. Several interoperability-critical elements are currently represented by provisional reference material in : 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. A future revision is expected to incorporate these interoperability requirements directly into this document or another standards-track 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.