A SCITT Profile for Pre-Execution AI Action Authorization Records
draft-munoz-scitt-permit-profile-01
This document is an Internet-Draft (I-D).
Anyone may submit an I-D to the IETF.
This I-D is not endorsed by the IETF and has no formal standing in the
IETF standards process.
| Document | Type | Active Internet-Draft (individual) | |
|---|---|---|---|
| Author | Christian Munoz | ||
| Last updated | 2026-07-19 | ||
| RFC stream | (None) | ||
| Intended RFC status | (None) | ||
| Formats | |||
| Stream | Stream state | (No stream defined) | |
| Consensus boilerplate | Unknown | ||
| RFC Editor Note | (None) | ||
| IESG | IESG state | I-D Exists | |
| Telechat date | (None) | ||
| Responsible AD | (None) | ||
| Send notices to | (None) |
draft-munoz-scitt-permit-profile-01
Network Working Group C. Munoz
Internet-Draft Keel API, Inc.
Intended status: Informational 18 July 2026
Expires: 19 January 2027
A SCITT Profile for Pre-Execution AI Action Authorization Records
draft-munoz-scitt-permit-profile-01
Abstract
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.
Status of This Memo
This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet-
Drafts is at https://datatracker.ietf.org/drafts/current/.
Munoz Expires 19 January 2027 [Page 1]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
This Internet-Draft will expire on 19 January 2027.
Copyright Notice
Copyright (c) 2026 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents (https://trustee.ietf.org/
license-info) in effect on the date of publication of this document.
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document. Code Components
extracted from this document must include Revised BSD License text as
described in Section 4.e of the Trust Legal Provisions and are
provided without warranty as described in the Revised BSD License.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Relationship to Existing Work . . . . . . . . . . . . . . 5
1.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5
2. Background: The Permit Object . . . . . . . . . . . . . . . . 6
3. The Permit Profile of SCITT . . . . . . . . . . . . . . . . . 7
3.1. Signed Statement . . . . . . . . . . . . . . . . . . . . 7
3.2. Paired Closure Record . . . . . . . . . . . . . . . . . . 8
3.3. Receipt . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Transparent Statement . . . . . . . . . . . . . . . . . . 10
3.5. Transparency Service Role . . . . . . . . . . . . . . . . 10
3.6. Verifier Behavior . . . . . . . . . . . . . . . . . . . . 11
3.7. Authority Lineage . . . . . . . . . . . . . . . . . . . . 12
4. Canonicalization . . . . . . . . . . . . . . . . . . . . . . 13
5. COSE_Sign1 Envelope Binding . . . . . . . . . . . . . . . . . 14
6. Composition with Adjacent Profiles . . . . . . . . . . . . . 15
6.1. Composition with AI Agent Authentication and
Authorization . . . . . . . . . . . . . . . . . . . . . . 15
6.2. Composition with SCITT AI Agent Execution . . . . . . . . 15
6.3. Composition with SCITT Refusal Events . . . . . . . . . . 16
6.4. Composition with OMP Human Authority Binding . . . . . . 16
6.5. Relationship to Execution-Boundary Trust Primitives . . . 17
7. Canonicalization and Receipt Choices . . . . . . . . . . . . 17
7.1. Linked-Chain vs. Merkle-Tree Receipts . . . . . . . . . . 18
7.2. Canonicalization . . . . . . . . . . . . . . . . . . . . 18
Munoz Expires 19 January 2027 [Page 2]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
8. Security Considerations . . . . . . . . . . . . . . . . . . . 19
8.1. Scope of Guarantees and Omission Attacks . . . . . . . . 19
8.2. Log Equivocation . . . . . . . . . . . . . . . . . . . . 20
8.3. Approval-Dispatch Divergence . . . . . . . . . . . . . . 20
8.4. Canonicalization Brittleness . . . . . . . . . . . . . . 21
8.5. Credential Containment . . . . . . . . . . . . . . . . . 21
8.6. Subject Identifier Privacy . . . . . . . . . . . . . . . 21
8.7. Hashes of Prompt Content . . . . . . . . . . . . . . . . 21
8.8. Authorization Lineage Ambiguity . . . . . . . . . . . . . 22
8.9. Attenuation Is Issuer-Enforced . . . . . . . . . . . . . 22
9. Privacy Considerations . . . . . . . . . . . . . . . . . . . 23
9.1. Sensitive Data in Wire Bodies . . . . . . . . . . . . . . 23
9.2. Cross-Border Considerations . . . . . . . . . . . . . . . 23
9.3. Logged Identifiers . . . . . . . . . . . . . . . . . . . 23
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 24
11. Implementation Status . . . . . . . . . . . . . . . . . . . . 25
12. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 26
13. References . . . . . . . . . . . . . . . . . . . . . . . . . 26
13.1. Normative References . . . . . . . . . . . . . . . . . . 26
13.2. Informative References . . . . . . . . . . . . . . . . . 27
Appendix A. Examples . . . . . . . . . . . . . . . . . . . . . . 29
A.1. Example Permit (informative) . . . . . . . . . . . . . . 29
A.2. Example Composition Reference (informative) . . . . . . . 30
Appendix B. Open Issues for -02 and Beyond . . . . . . . . . . . 30
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 31
1. Introduction
The SCITT architecture [RFC9943] 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.
Munoz Expires 19 January 2027 [Page 3]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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; Section 11 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.
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
Munoz Expires 19 January 2027 [Page 4]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
* 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
Munoz Expires 19 January 2027 [Page 5]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
2. 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
Munoz Expires 19 January 2027 [Page 6]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
* 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 Section 4)
* 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 [KEEL-PERMIT] 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.
3. The Permit Profile of SCITT
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).
Munoz Expires 19 January 2027 [Page 7]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
- 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
Munoz Expires 19 January 2027 [Page 8]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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
Munoz Expires 19 January 2027 [Page 9]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
* 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.
Munoz Expires 19 January 2027 [Page 10]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 11]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 12]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
4. 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 [KEEL-PERMIT] until
migrated into this document or an adopted companion specification.
The pipeline applies the following steps:
1. Strip volatile observability metadata keys from the payload (for
example, request IDs, trace IDs, span IDs, timestamps,
idempotency keys).
2. Strip sensitive credential keys from the payload (authorization
headers, API keys, provider-specific API-key headers, proxy-
authorization).
3. 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.
Munoz Expires 19 January 2027 [Page 13]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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 [RFC8785] 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.
5. COSE_Sign1 Envelope Binding
The reference Permit object specification in [KEEL-PERMIT] defines a
legacy evidence-record signature over the hexadecimal string
representation of SHA-256(canonical_json(payload)). The COSE_Sign1
envelope [RFC9052] 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
Munoz Expires 19 January 2027 [Page 14]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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 Section 3.1 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.
6. 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.
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.
Munoz Expires 19 January 2027 [Page 15]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 16]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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. 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.
Munoz Expires 19 January 2027 [Page 17]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 18]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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. Security Considerations
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.
Munoz Expires 19 January 2027 [Page 19]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 20]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 21]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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.
Munoz Expires 19 January 2027 [Page 22]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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. Privacy Considerations
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.
Munoz Expires 19 January 2027 [Page 23]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
10. IANA Considerations
This document requests the registration of a media type for the
Permit object, following the procedures of [RFC6838]: 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 Section 4.
* Security considerations: see Section 8 of this document.
* Interoperability considerations: see Section 4, Section 5, and
Section 7 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 [RFC6839]. 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
Munoz Expires 19 January 2027 [Page 24]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
* 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.
11. 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
[KEEL-PERMIT] 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.
Munoz Expires 19 January 2027 [Page 25]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
* Closure Records are produced best-effort: inline at response time,
with a deferred reconciliation sweep. The reference Issuer
therefore does not yet meet the Section 3.2 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 Appendix B).
* 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.
12. Acknowledgments
The author thanks the SCITT working group, the authors of
[I-D.emirdag-scitt-ai-agent-execution],
[I-D.kamimura-scitt-refusal-events], [I-D.klrc-aiagent-auth], and
[I-D.veridom-omp] for their work on adjacent profiles.
13. References
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>.
Munoz Expires 19 January 2027 [Page 26]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
[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>.
Munoz Expires 19 January 2027 [Page 27]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
[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>.
Munoz Expires 19 January 2027 [Page 28]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
[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>.
Appendix A. Examples
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"
}
Figure 1: Example Permit JSON
Munoz Expires 19 January 2027 [Page 29]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
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"
}
Figure 2: Example Permit with OMP authority_context reference
Appendix B. 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:
1. Whether to retain discussion of legacy evidence records, or to
make the next revision describe only SCITT-compatible Permit
Signed Statements.
2. Whether to require strict RFC 8785 JCS for all binding versions,
while preserving the stripping steps. Discussed in Section 7.
3. 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.
Munoz Expires 19 January 2027 [Page 30]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
4. 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.
5. 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.
6. 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.
7. IANA registration timing: in parallel with this draft, or after
WG adoption.
8. Whether to define a strict-mode profile that requires only
SCITT-compatible Permit Signed Statements and aligns
canonicalization with RFC 8785 strictly.
9. Whether Comparator Profiles should be registered through IANA,
an IETF-maintained registry, or implementation-defined profile
identifiers.
10. Whether a JSON Authority Representation profile should be
defined normatively here, or left as an informative example
until more implementations exist.
11. Several interoperability-critical elements are currently
represented by provisional reference material in [KEEL-PERMIT]:
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.
Author's Address
Christian Munoz
Keel API, Inc.
Email: christian@keelapi.com
Munoz Expires 19 January 2027 [Page 31]
Internet-Draft Pre-Exec AI Auth SCITT Profile July 2026
URI: https://keelapi.com
Munoz Expires 19 January 2027 [Page 32]