[Audit] Re: [AUDIT] Proposal: TTTPS - Pre-ingestion Temporal Security & Agent State Audit Gate

["Mirja Kuehlewind (IETF)" <[e-mail]>]

Hi Heime,

Thanks for engaging in the mailing list and your input. Please be aware that at this point of time the audit list is focused on the charter discussion. This is probably also a good time to re-send a pointer to our mailing list guidelines:

https://mailarchive.ietf.org/arch/msg/audit/dkQouBqX89mM3MgaatQZPmjooe4/

Thanks!
Mirja



> On 22. Sep 2026, at 09:47, Heime.Jorgen <heime.jorgen=[e-mail]> wrote:
> 
> 
>  Dear AUDIT BOF Community,
> 
>   I would like to introduce a draft series concerning temporal evidence and
>   admission control for observable agent and service actions.
> 
>   Core specification:  draft-helmprotocol-tttps
> 
>   Confidence profile:  draft-helmprotocol-confidence
> 
>   Propagation-aware profile:  draft-helmprotocol-deepspace
> 
>   AUDIT architecture addresses the generation, propagation, correlation, and
>   verification of records describing user intent, delegation, authorization
>   changes, and agent or service actions. SCITT provides an optional transparency
>   and receipt layer for such records.
> 
>   TTTPS addresses a complementary question: whether an evidence-bearing action
>   record is fresh, context-bound, and acceptable before a receiving application
>   performs a state transition or accepts the record into its local processing
>   pipeline.
> 
>   The current TTTPS core defines a fixed 180-octet Proof-of-Time Record v2.
>   When TLS 1.3 is used, a separate holder binding proof is derived from the TLS
>   exporter and holder key. The binding proof is carried with the PoT record but
>   is not counted within the 180-octet record.
> 
>   The protocol does not define agent intent, delegation semantics, audit record
>   semantics, or transparency storage. Instead, a successful TTTPS verification
>   can be referenced by an AUDIT Action, Delegation, or Authorization Transition
>   Record. The resulting record may then be stored or registered through an
>   AUDIT-compatible audit service or SCITT transparency service.
> 
>   The companion profiles describe:
> 
>   - confidence and correlation evidence as an optional policy layer; and
>   - propagation-aware context handling for delayed or degraded environments.
> 
>   The profiles do not change the TTTPS core record unless an explicitly
>   negotiated profile is selected.
> 
>   We would appreciate feedback on:
> 
>   1. whether temporal admission evidence is relevant to the proposed AUDIT
>      architecture;
>   2. how such evidence should be referenced from AUDIT record types;
>   3. the appropriate boundary between TTTPS, RATS, WIMSE, OAuth, and SCITT; and
>   4. whether a separate AUDIT integration profile would be useful.
> 
>   Drafts:
> 
>   https://datatracker.ietf.org/doc/draft-helmprotocol-tttps/
>   https://datatracker.ietf.org/doc/draft-helmprotocol-confidence/
>   https://datatracker.ietf.org/doc/draft-helmprotocol-deepspace/
> 
>   Best regards,
>   Heime Jorgen
> _______________________________________________
> Audit mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]