A SCITT Profile for Pre-Execution AI Action Authorization Records

1.1. Scope

This profile specifies:¶

• The COSE_Sign1 encoding of the Permit object as a SCITT Signed Statement¶

• The COSE_Sign1 [RFC9052] 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 [I-D.klrc-aiagent-auth], the SCITT AI agent execution profile [I-D.emirdag-scitt-ai-agent-execution], the SCITT refusal events profile [I-D.kamimura-scitt-refusal-events], and the OMP human authority binding profile [I-D.veridom-omp]¶

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

1.2. Relationship to Existing Work

A provisional reference specification and implementation source for the Permit object is published at [KEEL-PERMIT]. 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.¶

1.3. Terminology

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here.¶

This document uses the following SCITT terms as defined in [RFC9943]: 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 Section 4.¶

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

3.1. Signed Statement

A SCITT-compatible Permit Signed Statement is a COSE_Sign1 envelope [RFC9052] whose payload is the Permit object, and is a Signed Statement in the sense of [RFC9943]. A Permit carrying only the legacy reserved signature field is not a SCITT Signed Statement under this profile (see Section 5).¶

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) [RFC9053]. 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 Section 5 and Section 11.¶

3.2. 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 Section 11). 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 Section 10).¶

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 Section 8.3).¶

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 Section 8.3). 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.¶

3.3. 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 Section 7.¶

3.4. Transparent Statement

A Transparent Statement, in the sense of [RFC9943], 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. [KEEL-PERMIT] 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.¶

3.5. Transparency Service Role

The Issuer and the Transparency Service MAY be the same operator. The reference implementation in [KEEL-PERMIT] combines both roles; this is permitted by the SCITT architecture. Registration APIs such as those described in [I-D.ietf-scitt-scrapi] 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.¶

3.6. Verifier Behavior

A conforming Verifier MUST:¶

1. 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 Section 5 for the signature forms the reference implementation emits today.¶

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

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

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

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

3.7. 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 [RFC8785] 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 Section 11 and Section 8.9.¶

6.1. Composition with AI Agent Authentication and Authorization

The AI agent authentication and authorization draft [I-D.klrc-aiagent-auth] 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 [I-D.munoz-wimse-authorization-evidence] specifies WIMSE-side integration in detail, including delegated-subject evidence and runtime-token references.¶

6.2. Composition with SCITT AI Agent Execution

The SCITT AI agent execution profile [I-D.emirdag-scitt-ai-agent-execution] 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.¶

6.3. Composition with SCITT Refusal Events

The SCITT refusal events profile [I-D.kamimura-scitt-refusal-events] 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 [I-D.kamimura-scitt-refusal-events] composes naturally: the corresponding Permit captures the authorization context for the recorded outcome.¶

6.4. Composition with OMP Human Authority Binding

The OMP profile [I-D.veridom-omp] 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.¶

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

7.1. Linked-Chain vs. Merkle-Tree Receipts

The reference implementation in [KEEL-PERMIT] 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 [RFC9162] [RFC6962]) 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 [I-D.ietf-scitt-receipts-ccf-profile] illustrate one Merkle-tree receipt encoding that a future revision could profile as an alternative.¶

The SCITT architecture [RFC9943] 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.¶

7.2. Canonicalization

The canonicalization pipeline in Section 4 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 [RFC8785] are provisional reference material in [KEEL-PERMIT]; 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.¶

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

8.2. 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 [RFC3161], 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 Section 8.1.¶

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

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

8.5. Credential Containment

The sensitive-key stripping step in Section 4 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.¶

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

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

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

8.9. 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 Appendix B.¶

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

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

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

13.1. Normative References

[RFC2119]

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <https://www.rfc-editor.org/rfc/rfc2119>.

[RFC8174]

Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, May 2017, <https://www.rfc-editor.org/rfc/rfc8174>.

[RFC8785]

Rundgren, A., Jordan, B., and S. Erdtman, "JSON Canonicalization Scheme (JCS)", RFC 8785, DOI 10.17487/RFC8785, June 2020, <https://www.rfc-editor.org/rfc/rfc8785>.

[RFC9052]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Structures and Process", STD 96, RFC 9052, DOI 10.17487/RFC9052, August 2022, <https://www.rfc-editor.org/rfc/rfc9052>.

[RFC9053]

Schaad, J., "CBOR Object Signing and Encryption (COSE): Initial Algorithms", RFC 9053, DOI 10.17487/RFC9053, August 2022, <https://www.rfc-editor.org/rfc/rfc9053>.

[RFC9943]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., Deshpande, Y., and S. Lasker, "An Architecture for Trustworthy and Transparent Digital Supply Chains", RFC 9943, DOI 10.17487/RFC9943, June 2026, <https://www.rfc-editor.org/rfc/rfc9943>.

13.2. Informative References

[I-D.emirdag-scitt-ai-agent-execution]

Emirdag, P., "AI Agent Execution Profile of SCITT", Work in Progress, Internet-Draft, draft-emirdag-scitt-ai-agent-execution-00, 13 April 2026, <https://datatracker.ietf.org/doc/html/draft-emirdag-scitt-ai-agent-execution-00>.

[I-D.ietf-scitt-receipts-ccf-profile]

Birkholz, H., Delignat-Lavaud, A., Fournet, C., and A. Chamayou, "CCF Profile for COSE Receipts", Work in Progress, Internet-Draft, draft-ietf-scitt-receipts-ccf-profile-04, 24 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-receipts-ccf-profile-04>.

[I-D.ietf-scitt-scrapi]

Birkholz, H., Geater, J., and A. Delignat-Lavaud, "SCITT Reference APIs", Work in Progress, Internet-Draft, draft-ietf-scitt-scrapi-11, 26 June 2026, <https://datatracker.ietf.org/doc/html/draft-ietf-scitt-scrapi-11>.

[I-D.kamimura-scitt-refusal-events]

Kamimura, T., "Verifiable AI Refusal Events using SCITT", Work in Progress, Internet-Draft, draft-kamimura-scitt-refusal-events-02, 30 January 2026, <https://datatracker.ietf.org/doc/html/draft-kamimura-scitt-refusal-events-02>.

[I-D.klrc-aiagent-auth]

Kasselman, P., Lombardo, J., Rosomakho, Y., Campbell, B., Steele, N., and A. Parecki, "AI Agent Authentication and Authorization", Work in Progress, Internet-Draft, draft-klrc-aiagent-auth-03, 6 July 2026, <https://datatracker.ietf.org/doc/html/draft-klrc-aiagent-auth-03>.

[I-D.munoz-wimse-authorization-evidence]

Munoz, C., "Signed Authorization-Evidence Records for WIMSE-Authorized AI Agent Actions", Work in Progress, Internet-Draft, draft-munoz-wimse-authorization-evidence-01, 27 June 2026, <https://datatracker.ietf.org/doc/html/draft-munoz-wimse-authorization-evidence-01>.

[I-D.veridom-omp]

Adebayo, T. and O. Apalowo, "Operating Model Protocol (OMP) Core -- Version 02: Invariant 3 -- Verifiable Delegation Binding", Work in Progress, Internet-Draft, draft-veridom-omp-02, 13 May 2026, <https://datatracker.ietf.org/doc/html/draft-veridom-omp-02>.

[KEEL-PERMIT]

Keel API, Inc., "Keel Permit Specification", 2026, <https://github.com/keelapi/keel-permit/blob/1818c3e04eddf9a2ab6231486ca2cdb2d250ec74/spec/permit-chain-v1.md>.

[RFC3161]

Adams, C., Cain, P., Pinkas, D., and R. Zuccherato, "Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP)", RFC 3161, DOI 10.17487/RFC3161, August 2001, <https://www.rfc-editor.org/rfc/rfc3161>.

[RFC6838]

Freed, N., Klensin, J., and T. Hansen, "Media Type Specifications and Registration Procedures", BCP 13, RFC 6838, DOI 10.17487/RFC6838, January 2013, <https://www.rfc-editor.org/rfc/rfc6838>.

[RFC6839]

Hansen, T. and A. Melnikov, "Additional Media Type Structured Syntax Suffixes", RFC 6839, DOI 10.17487/RFC6839, January 2013, <https://www.rfc-editor.org/rfc/rfc6839>.

[RFC6962]

Laurie, B., Langley, A., and E. Kasper, "Certificate Transparency", RFC 6962, DOI 10.17487/RFC6962, June 2013, <https://www.rfc-editor.org/rfc/rfc6962>.

[RFC9162]

Laurie, B., Messeri, E., and R. Stradling, "Certificate Transparency Version 2.0", RFC 9162, DOI 10.17487/RFC9162, December 2021, <https://www.rfc-editor.org/rfc/rfc9162>.

A.1. Example Permit (informative)

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

{
  "id": "9c8b7a6e-5d4c-3b2a-1f0e-d9c8b7a6e5d4",
  "project_id": "0a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d",
  "decision": "allow",
  "reason": "policy-eval-pass",
  "actions_json": [],
  "subject_type": "spiffe",
  "subject_id": "spiffe://example.org/agent/x123",
  "action_name": "chat.completions.create",
  "resource_provider": "example-llm",
  "resource_model": "example-model-1",
  "estimated_input_tokens": 1024,
  "estimated_output_tokens": 512,
  "request_fingerprint":
    "3b8d6e0e7f4c2a1d5b9e0c3a7f1d4e6b8a2c5f0d3e6b9a1c4f7d0a3e6b9c2f5d",
  "idempotency_key": "req-2026-05-14-abc",
  "policy_id": "default-allow-policy",
  "policy_version": "v3",
  "created_at": "2026-05-14T10:15:30Z",
  "binding_request_hash":
    "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2"
}

A.2. Example Composition Reference (informative)

A Permit referencing an OMP authority_binding artifact:¶

{
  "id": "9c8b7a6e-5d4c-3b2a-1f0e-d9c8b7a6e5d4",
  "decision": "allow",
  "subject_type": "spiffe",
  "subject_id": "spiffe://bank.example/agent/loan-decision",
  "action_name": "loan.decision.assess",
  "resource_provider": "internal-llm",
  "resource_model": "loan-model-3",
  "decision_details": {
    "decision": "allow",
    "code": "policy.allow",
    "authority_context": {
      "uri":
       "https://example.bank/authority/officer-12345/2026-05-14",
      "digest":
       "sha256:b7d1c0e5a4f6b2d3c8e9a0f1b4c5d6e7f8a9b0c1d2e3f4a5",
      "signed_by": "bank.example.authority.root.2026"
    }
  },
  "binding_request_hash":
    "a1b2c3d4e5f6a7b8c9d0e1f2a3b4c5d6e7f8a9b0c1d2e3f4a5b6c7d8e9f0a1b2"
}