[SCITT] Re: [EXTERNAL] Re: FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

[Dick Brooks <[e-mail]>]

Here is an example SAG-CTR API call to lookup the current “Trust Status” for a known product in JSON output (for automation) using the “public APIs”

https://softwareassuranceguardian.com/labellink/getTrustedProductLabel?ProductID=E6CC8B4801EC3408BB2FB481CA7A1FB1B775ACFC330B6E8CD996E5882ECF44FA

 

AND human readable html

 

https://softwareassuranceguardian.com/labellink/getTrustedProductLabel?ProductID=E6CC8B4801EC3408BB2FB481CA7A1FB1B775ACFC330B6E8CD996E5882ECF44FA <https://softwareassuranceguardian.com/labellink/getTrustedProductLabel?ProductID=E6CC8B4801EC3408BB2FB481CA7A1FB1B775ACFC330B6E8CD996E5882ECF44FA&html=1> &html=1

 

This will also give you the ability to check performance of these lookups, usually less than 500 ms

 

Thanks,

 

Dick Brooks

   

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

Lifetime IEEE Member

 <https://reliableenergyanalytics.com/products> 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]

 

 

From: Tokachi Kamimura, VSO <[e-mail]> 
Sent: Wednesday, January 7, 2026 8:49 AM
To: [e-mail]; Amaury Chamayou <[e-mail]>; [e-mail]
Subject: RE: [EXTERNAL] [SCITT] Re: FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

I think all three points are valid, and they don’t actually conflict.

SCITT receipts are excellent at proving *historical facts*:
that a statement was registered, under a given policy, at a given time.
They are not meant to be a real-time signal of current trust state.

For real-time or risk-based decisions, what matters is the *current view*:
revocations, compensating transactions, updated assessments, etc.
That naturally requires a lookup or a derived state — not just the original receipt.

>From an architectural perspective, this suggests a clean layering:

• SCITT + SCRAPI define the immutable, auditable history 
• Receipts bind artifacts and declarations to that history 
• Runtime trust decisions operate on a derived, fast state view 
• TEA / delivery mechanisms carry the evidence needed to make that decision 
• Relying parties choose freshness and policy thresholds

In that sense, SCITT is the trust *foundation*, not the trust *oracle*.
The dynamic trust signal is built on top, but remains accountable
because it can always be traced back to verifiable SCITT records.

That separation feels essential if we want both correctness and usability.

 

========
Tokachi Kamimura
Executive Director
VeritasChain Standards Organization (VSO)


The Flight Recorder for AI Systems
— Verify, Don’t Trust —

 

VeritasChain Standards Organization (VSO)
Non-profit, vendor-neutral technical standards body

Overview: https://veritaschain.org/overview/

 

Email: [e-mail] <mailto:[e-mail]>  
Website: https://veritaschain.org

ORCiD: https://orcid.org/0009-0002-0871-1627 <https://veritaschain.org>  
VCP Explorer (Demo): https://veritaschain.org/explorer/app/ 

LinkedIn: https://www.linkedin.com/in/tokachi/

Tokyo Office: Ebisu, Shibuya-ku, Tokyo 150-0021, Japan

2026年1月7日 22:43 +0900、Dick Brooks <[e-mail] <mailto:[e-mail]> >のメール:



I agree Amaury, the SCITT receipt tell that a “Trust Declaration” is/was once registered in a Trust Registry, but it does not provide updated/dynamic info, such as a dynamic “trust scores” that is needed in real-time risk-based decisions for Secure by Design and Secure by Default applications.

 

Also, the original receipt when the signed statement was “registered” would not indicate if a registry entry was later revoked with a compensating transaction, but a real-time lookup would provide the “current status”.

 

Thanks,

 

Dick Brooks

<image010.png>  <image011.png> <image012.png>

Active Member of the CISA Critical Manufacturing Sector, 

Sector Coordinating Council – A Public-Private Partnership

Lifetime IEEE Member

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

Risk always exists, but trust must be earned and awarded.™ 

https://businesscyberguardian.com/

Email: [e-mail] <mailto:[e-mail]> 

Tel: [phone]

 

 

From: Amaury Chamayou <[e-mail] <mailto:[e-mail]> >
Sent: Wednesday, January 7, 2026 8:29 AM
To: 'Tokachi Kamimura, VSO' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: Re: [EXTERNAL] [SCITT] Re: FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

An important property of SCITT Receipts is that they can be embedded in Signed Statements, and verified offline, in situations where online access is too slow or not possible.

 

This makes Transparent Statements very broadly applicable, without online access to a single point of failure service, and lets Relying Parties decide for themselves how fresh Statements must be in order to be acceptable.

 

I expected usage of SCITT will often be similar to CT today, where the SCTs are included in the certificate, and browsers maintain a policy for which CT Logs/SCT issuers they trust, but do not contact the CT logs online every time they establish a connection.

 

Amaury

 

  _____  

From: Dick Brooks <[e-mail] <mailto:[e-mail]> >
Sent: 07 January 2026 13:20
To: 'Tokachi Kamimura, VSO' <[e-mail] <mailto:[e-mail]> >; [e-mail] <mailto:[e-mail]>  <[e-mail] <mailto:[e-mail]> >
Subject: [EXTERNAL] [SCITT] Re: FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

Tokachi,

 

I believe we are 100% in alignment.

 

Now we need to focus our energies on SCRAPI to complete the picture and make Trust Registries part of critical digital infrastructure that people rely on and trust.

 

Thanks,

 

Dick Brooks

<image007.png>  <image008.png> <image009.png>

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Lifetime IEEE Member

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

Risk always exists, but trust must be earned and awarded.™

https://businesscyberguardian.com/

Email: [e-mail] <mailto:[e-mail]> 

Tel: [phone]

 

 

From: Tokachi Kamimura, VSO <[e-mail] <mailto:[e-mail]> >
Sent: Wednesday, January 7, 2026 8:08 AM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: RE: [SCITT] FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

Thanks Dick — this resonates a lot.

I think you’ve identified a critical architectural boundary that often gets
missed in trust registry discussions.

There are really two very different paths here:
- a *public query path* that must be fast, scalable, and usable in real time
- and a *registration / evidence path* that can be slower, stricter, and policy-heavy

Trying to force both through the same VDS execution path is where performance
and adoption break down.

Your approach — a fast cache lookup for Trust Declarations that is
*independently verifiable* against SCITT VDS controls — feels like the right
separation of concerns.

In other words:
speed belongs at the edge,
integrity belongs in the ledger,
and trust comes from being able to prove that the two are cryptographically linked.

If public trust queries can’t be answered in sub-second time,
they simply won’t be used — no matter how correct the backend is.

 

========
Tokachi Kamimura
Executive Director
VeritasChain Standards Organization (VSO)


The Flight Recorder for AI Systems
— Verify, Don’t Trust —

 

VeritasChain Standards Organization (VSO)
Non-profit, vendor-neutral technical standards body

Overview: https://veritaschain.org/overview/

 

Email: [e-mail] <mailto:[e-mail]> 
Website: https://veritaschain.org <https://veritaschain.org/> 

ORCiD: https://orcid.org/0009-0002-0871-1627
VCP Explorer (Demo): https://veritaschain.org/explorer/app/

LinkedIn: https://www.linkedin.com/in/tokachi/

Tokyo Office: Ebisu, Shibuya-ku, Tokyo 150-0021, Japan

2026年1月7日 21:46 +0900、Dick Brooks <[e-mail]>のメール:

Tokachi,

 

Thanks for sharing your insights. I believe we are 100% aligned in our views on SCITT.

 

SCITT gives a registry auditability, which verifies and confirms integrity, resulting in credibility and public trust in a Registry.

Public trust is a critical success factor for a Trust Registry.

 

One key point we’ve discovered; SCITT performance can be an issue due to the VDS integrity controls.

A public query against a Trust Registry to answer the question “Is this *thing* trusted in the Trust Registry” MUST be scalable and provide sub-second response in order to be practical for Secure by Design and Secure by Default implementations in the real world.

 

This is a critical success factor for Trust Registry implementations following SCITT. We built a “fast cache data store lookup for Trust Declarations” that doesn’t operate against the SCITT VDS inside SAG-CTR to meet this need, BUT is verifiable and auditable using the SCITT VDS controls. The registration of Trust Declarations is a much slower process and does not impact public use of the Trust Registry.

 

I’ll let the list know if the FCC responds.

 

Thanks,

 

Dick Brooks

<image002.png>  <image004.png> <image006.png>

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Lifetime IEEE Member

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

Risk always exists, but trust must be earned and awarded.™

https://businesscyberguardian.com/

Email: [e-mail] <mailto:[e-mail]> 

Tel: [phone]

 

 

From: Tokachi Kamimura, VSO <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, January 6, 2026 7:44 PM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: RE: [SCITT] FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

Thanks Dick — this is a very clear and important distinction.

 

I strongly agree with your core point:
static trust marks behave like a one-time test, not like a living signal.
They create the *appearance* of safety, but not an observable, time-evolving
representation of risk.

 

The analogy to a credit score is exactly right.
Trust in software is inherently dynamic and should reflect
ground-truth conditions as they change — vulnerabilities, behavior, and context.

 

I also think your description of SAC-GTR is a good example of how this can work
*without turning trust into a subjective assertion*:
verifiable evidence, signed statements, explicit policies,
and a gatekeeper that enforces entrance criteria.

 

Where I see SCITT fitting is as the neutral substrate underneath this.
SCITT itself shouldn’t define “good” or “bad” trust —
but it gives us a way to publish evidence, policies, and rejection rules
in a form that others can independently verify.

 

In other words, the real power comes from:
SCITT + clearly defined registration policies + evidence-driven admission logic.

 

On the UL point, I agree completely.
When a centralized trust mark loses credibility,
the gap isn’t another authority — it’s verifiable, policy-enforced trust.
It’s encouraging to hear you’ve raised this with the FCC.

 

This feels like exactly the right moment to move from
static labels to continuously verifiable trust signals.

 

========
Tokachi Kamimura
Executive Director
VeritasChain Standards Organization (VSO)


The Flight Recorder for AI Systems
— Verify, Don’t Trust —

 

VeritasChain Standards Organization (VSO)
Non-profit, vendor-neutral technical standards body

Overview: https://veritaschain.org/overview/

 

Email: [e-mail] <mailto:[e-mail]> 
Website: https://veritaschain.org <https://veritaschain.org/> 

ORCiD: https://orcid.org/0009-0002-0871-1627
VCP Explorer (Demo): https://veritaschain.org/explorer/app/

LinkedIn: https://www.linkedin.com/in/tokachi/

Tokyo Office: Ebisu, Shibuya-ku, Tokyo 150-0021, Japan

Jan 7, 2026, 09:31 +0900, Dick Brooks <[e-mail] <mailto:[e-mail]> >:

Tokachi,

 

The US Cyber Trust Mark that UL administered is simply a “test” that is passed once and done, like a driver’s license. It does not reflect the “current state of security for a product”

 

Trust in software products is far more dynamic and can change from  one moment to the next, based on “ground truth” conditions over time, i.e. a new vulnerability will have a negative impact on a trust score. This is why the US Cyber Trust Mark gives a false sense of security; it’s not a real time trust score, like a credit score (FICO).

 

In the case with SAG-CTR a trusted party must submit a “risk assessment evidence file” (verifiable evidence/Signed Statement and payload) covering 7 risk categories and also include a statistically calculated “Trust Score” called SAGScore into a “Truest Queue”.

 

A Trust Declaration (Signed Statement) from a trusted party containing the risk assessment evidence file in the payload will be REJECTED if the “Signed Statement” and payload (Trust Declaration), fails to pass the “entrance examination described by the SAG-CTR Registration Policy requirements, enforced by the SAG-CTR Gatekeeper, as shown in this diagram, https://www.linkedin.com/posts/richard-dick-brooks-8078241_visual-model-of-an-ietf-scitt-community-product-activity-7409615006587056128-hVtU/?utm_source=share <https://www.linkedin.com/posts/richard-dick-brooks-8078241_visual-model-of-an-ietf-scitt-community-product-activity-7409615006587056128-hVtU/?utm_source=share&utm_medium=member_desktop&rcm=ACoAAABMsYcB3I6zhtjaqBqVcePEOQqxsZNzj5E> &utm_medium=member_desktop&rcm=ACoAAABMsYcB3I6zhtjaqBqVcePEOQqxsZNzj5E

 

I agree, SCITT by itself does not impose any expectations beyond the SCITT protocol and SCRAPI. However, each Transparency Service is free to enforce Registration Policies that constrain what “signed statement materials” and payloads may be placed in “their” Trust Registry/Transparency Service VDS.

 

I agree, the UL decision paves the way for a SCITT Trust Registry to fill the gap. I’ve reached out to the FCC on this very point.

 

 

Thanks,

 

Dick Brooks

<image007.png>  <image008.png> <image009.png>

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Lifetime IEEE Member

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

Risk always exists, but trust must be earned and awarded.™

https://businesscyberguardian.com/

Email: [e-mail] <mailto:[e-mail]> 

Tel: [phone]

 

 

From: Tokachi Kamimura, VSO <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, January 6, 2026 6:56 PM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: RE: [SCITT] FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

Completely agree.

What worries me is that “trustworthiness” is being inferred from
policy statements or brand signals, rather than from verifiable evidence.
Once recommendations are driven by loose or implicit policies,
users have no reliable way to distinguish rigor from appearance.

The UL situation really highlights this gap.
When trust marks lose legitimacy, what’s missing isn’t another label,
but a neutral, verifiable trust substrate.

That’s where SCITT feels different to me:
it doesn’t ask anyone to *assert* trustworthiness —
it enables others to independently verify it.

Filling that gap left by UL with an open, IETF-based mechanism
seems not only timely, but necessary.

 

========
Tokachi Kamimura
Executive Director
VeritasChain Standards Organization (VSO)


The Flight Recorder for AI Systems
— Verify, Don’t Trust —

 

VeritasChain Standards Organization (VSO)
Non-profit, vendor-neutral technical standards body

Overview: https://veritaschain.org/overview/

 

Email: [e-mail] <mailto:[e-mail]> 
Website: https://veritaschain.org <https://veritaschain.org/> 

ORCiD: https://orcid.org/0009-0002-0871-1627
Press & Global Coverage: https://veritaschain.org/media/
VCP Explorer (Demo): https://veritaschain.org/explorer/app/

LinkedIn: https://www.linkedin.com/in/tokachi/

Tokyo Office: Ebisu, Shibuya-ku, Tokyo 150-0021, Japan

2026年1月7日 2:57 +0900、Dick Brooks <[e-mail] <mailto:[e-mail]> >のメール:

100% agree Tokachi.

 

People that trust their IDE’s to offer “trustworthy advice/recommendations” may find that these recommendations are based on “loose policies” lacking rigor.

 

This is why an IETF SCITT Trust Registry is so vitally important, NOW, to help parties identify trustworthy products.

 

A major shift in product trustworthiness infrastructure took place in the US today; UL has withdrawn from the US Cyber Trust Mark Program due to foreign influence concerns.

IMO, this paves the way for an IETF SCITT solution to “fill the gap left by UL”.

 

https://www.nextgov.com/cybersecurity/2026/01/ul-solutions-withdraws-lead-admin-fcc-cyber-label-program-amid-probe-china-ties/410448/?oref=ng-home-top-story

 

Thanks,

 

Dick Brooks

<image007.png>  <image008.png> <image009.png>

Active Member of the CISA Critical Manufacturing Sector,

Sector Coordinating Council – A Public-Private Partnership

Lifetime IEEE Member

 <https://reliableenergyanalytics.com/products> Never trust software, always verify and report! ™

Risk always exists, but trust must be earned and awarded.™

https://businesscyberguardian.com/

Email: [e-mail] <mailto:[e-mail]> 

Tel: [phone]

 

 

From: Tokachi Kamimura, VSO <[e-mail] <mailto:[e-mail]> >
Sent: Tuesday, January 6, 2026 12:46 PM
To: [e-mail] <mailto:[e-mail]> ; [e-mail] <mailto:[e-mail]> 
Subject: Re: [SCITT] FYI: Use Case example of SCITT trust check for VS Code to avoid untrusted VS Code extensions

 

This is a great illustration.

What stands out to me is that the failure isn’t developer behavior at all —
it’s the lack of verifiable evidence around *automated recommendations*.

Once an IDE recommends an extension, that recommendation effectively becomes
a delegated decision. Without a verifiable decision trail, trust collapses
into a single opaque control point.

Using SCITT as a pre-recommendation trust signal makes a lot of sense here.
It turns “trust me” into something that can actually be verified.

 

========
Tokachi Kamimura
Executive Director
VeritasChain Standards Organization (VSO)


The Flight Recorder for AI Systems
— Verify, Don’t Trust —

 

VeritasChain Standards Organization (VSO)
Non-profit, vendor-neutral technical standards body

Overview: https://veritaschain.org/overview/

 

Email: [e-mail] <mailto:[e-mail]> 
Website: https://veritaschain.org <https://veritaschain.org/> 

ORCiD: https://orcid.org/0009-0002-0871-1627
Press & Global Coverage: https://veritaschain.org/media/
VCP Explorer (Demo): https://veritaschain.org/explorer/app/

LinkedIn: https://www.linkedin.com/in/tokachi/

Tokyo Office: Ebisu, Shibuya-ku, Tokyo 150-0021, Japan

2026年1月7日 2:46 +0900、[e-mail] <mailto:[e-mail]%E3%81%AE%E3%83%A1%E3%83%BC%E3%83%AB> のメール <mailto:[e-mail]%E3%81%AE%E3%83%A1%E3%83%BC%E3%83%AB> :

Dick Brooks