[SCITT] Re: Question: Using SCITT-like transparency services for authority binding in AI decision records (draft-veridom-omp-01)

[Christian — Keel <[e-mail]>]

Hi Tolulope,



I’m Christian Munoz, founder of Keel. We published the Keel Permit spec

( http://github.com/keelapi/keel-permit ), a specification for pre-execution AI

action authorization records linked via canonical request digests

recorded both before and after dispatch. I've been drafting a SCITT

profile for it, so your post landed at a useful moment.



Brief responses to your three questions:



1) Publishing instrument or authority-state hashes to a SCITT-style

transparency service is a sane pattern. We've explored a related

construction in Keel using per-scope hash chains with signed checkpoints

anchored in audit-export bundles — linked-list record-hash + prev-hash

rather than a Merkle tree, which gives us append-only tamper-evidence

characteristics with different verification tradeoffs

(O(n)-from-checkpoint rather than O(log n) inclusion).



2) Mapping onto SCITT artifacts feels natural; in our profile draft the

Signed Statement / Receipt distinction maps to a (Permit,

chain-entry-segment) pair. One thing worth flagging since OMP anchors on

it: we don't currently claim strict RFC 8785 JCS compliance — our

canonicalization spec calls this out explicitly — and I'd be curious

about your experience with JCS in adversarial / cross-implementation

contexts.



3) For omission and equivocation: the strongest construct we've found

is independent commitment to the same canonical request bytes at two

points — pre-execution (the Permit) and post-dispatch (the closure

record). Matching digests across the two independently signed records

makes after-the-fact swap of the authorized artifact detectable at the

AI-action-authorization layer. Not a defense against log equivocation

per se, but it raises the attack cost.



A layer observation, since I think OMP and Permit may be operating at

different but composable layers:



OMP proves who could approve; Permit proves what was approved and
that it equals what was sent.



In a regulated AI-assisted decision both layers seem necessary. A thin

reference slot in a Permit pointing to an OMP-style authority_binding

artifact (URI + digest, no embedded semantics) would, I think, give

composition without either profile absorbing the other.



Happy to take any of this off-list if it's tangential.



Best,

Christian Munoz

Founder,

Keel API, Inc.

keelapi.com  ·  http://github.com/keelapi/keel-permit