[SCITT] Re: Last Call Review regarding extension of trust model to invocation context

[Jennifer Bryan <[e-mail]>]

Dear Dick,

Thank you for the thoughtful response and for pointing to Section 5.1.1. That was helpful, and I agree that SCITT clearly contemplates policy enforcement prior to registration through Registration Policies.

The distinction I am trying to highlight is slightly different. It is not whether authorization checks occur before a signed statement is accepted, but whether the authorization context and outcome of those checks are captured and bound in a way that remains portable and independently verifiable after the fact.

As I read the current model, SCITT provides strong guarantees that a statement was accepted under a given set of policies at registration time. What seems less clear is whether a downstream party, relying only on the artifact or receipt, can determine what authorization existed at the time the artifact was produced, without relying on the transparency service’s local enforcement.

That difference between enforcement and verifiable evidence is the gap I was trying to point to. In environments with dynamic or automated generation, that distinction can become important when consumers need to assess not only what was recorded, but whether creation was demonstrably authorized in a way that can be evaluated independently.

I agree that the architecture and SCRAPI work closely together, and my suggestion is simply that it may be worth considering how that authorization context at creation could be represented in a way that travels with the artifact and can be verified across systems.

Thank you again for the engagement. I appreciate the perspective from implementation.

Sincerely,

Jennifer J. Bryan, MD, FAAFP  
Founder, Quiet Signal Technologies LLC


> On Apr 10, 2026, at 8:34 AM, Dick Brooks <[e-mail]> wrote:
> 
> Jennifer,
> 
> Thanks for the feedback.
> 
> Regarding you comment " The drafts do not appear to define a mechanism for representing or verifying authorization context at the time of invocation. This includes whether a given actor, system, or credential was permitted to produce the artifact at the moment of generation and under what scope or constraints."
> 
> We define detailed expectations within the "Registration Policies" required by the SCITT Architecture In our SAG-CTR Trust Registry implementation that has been proposed to serve as the US Cyber Trust Mark Label Registry.
> " Registration Policies refer to additional checks over and above the Mandatory Registration Checks that are performed before a Signed Statement is registered to the Verifiable Data Structure."
> 
> SCITT Registration Polices application and use: https://www.ietf.org/archive/id/draft-ietf-scitt-architecture-22.html#section-5.1.1
> 
> These SCITT Registration Policies provide the type of content I think you are asking for. SCITT Transparency Services Registration Policies are enforced before any attempt to place a signed statement into the SCITT ledger, using SCRAPI.
> The SCITT Architecture and SCRAPI work in conjunction and should be considered two required parts of a Trust Registry/Transparency Service implementation.
> 
> Just my .02 from the implementation trenches.
> 
> Thanks,
> 
> Dick Brooks
> 
> Active Member of the CISA Critical Manufacturing Sector,
> Sector Coordinating Council – A Public-Private Partnership
> Lifetime IEEE Member
> Never trust software, always verify and report! ™
> Risk always exists, but trust must be earned and awarded.™
> https://businesscyberguardian.com/
> Email: [e-mail]
> Tel: [phone]
> 
> 
> -----Original Message-----
> From: Jennifer Bryan <jbryan522=[e-mail]>
> Sent: Thursday, April 9, 2026 10:09 PM
> To: [e-mail]
> Subject: [SCITT] Last Call Review regarding extension of trust model to invocation context
> 
> Dear colleagues,
> 
> The current SCITT architecture and associated drafts, including the reference APIs and receipt structures, provide a strong model for registering statements and producing verifiable receipts that support post hoc provenance and inclusion proofs.
> 
> However, as currently written, the trust model is implicitly anchored at the point of statement registration rather than at the point of artifact generation. This creates a structural gap in scenarios where the trustworthiness of the artifact depends not only on its inclusion in a transparency service but on the conditions under which it was originally produced.
> 
> The drafts do not appear to define a mechanism for representing or verifying authorization context at the time of invocation. This includes whether a given actor, system, or credential was permitted to produce the artifact at the moment of generation and under what scope or constraints.
> 
> This distinction becomes increasingly important in environments where artifacts are generated dynamically by automated systems, where multiple actors or roles may invoke the same underlying capability, and where downstream consumers must be able to distinguish between outputs that are merely recorded versus those that were validly authorized at creation.
> 
> Without a way to bind invocation context to the resulting statement or receipt, SCITT provides strong guarantees about what was recorded but limited guarantees about whether the recorded action was permissible or valid at the time it occurred.
> 
> It may be useful to consider whether the model should be extended to support representation of invocation time authorization context as part of the signed statement or associated metadata, cryptographic binding of that context to the resulting artifact or receipt, and verifiability of that context by third parties independently of the original system.
> 
> This could be introduced in a way that remains implementation agnostic, for example through optional fields, extensible metadata, or profile level constraints, while enabling higher assurance use cases that depend on more than post hoc provenance.
> 
> Framing this specifically in the architecture may help ensure that SCITT can support not only transparency and integrity but also validity of action at the point of creation, which is increasingly a first order requirement in automated and distributed systems.
> 
> This is intended as a complement to the existing model rather than a replacement, extending the trust boundary upstream without constraining implementation approaches.
> 
> Thank you for the opportunity to contribute and please don’t hesitate to reach out if I may be of assistance.
> 
> Sincerely,
> 
> Jennifer J. Bryan, MD, FAAFP
> Founder, Quiet Signal Technologies LLC
> 
> --
> SCITT mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
>