[Rats] Re: [Use Case] RATS for Hardware-Enforced State Management in Autonomous Agents (AIGA)

[Edward Aylward <[e-mail]>]

Hi Michael,

Thank you for the quick feedback.

Re: Architecture (RFC 9334) This is excellent confirmation. I have reviewed
Figure 1 in RFC 9334, and it maps perfectly to the AIGA proposal:

Attester: The AI Agent (Hardware Enclave).

Verifier: The Governance Node.

Relying Party: The Network Peer (consuming the token). I will update the
draft to explicitly cite RFC 9334 Section 3 as the architectural basis for
the "Silicon Kill Switch" in Section 5.1.

Re: Operational State (Boolean vs. Dates) Your suggestion to use temporal
claims (Last-Activated / Last-Deactivated) rather than a binary state is
interesting. It aligns well with the "Attestation Heartbeat" model I
proposed, where the token inherently expires every 60 seconds (functioning
like a short-lived exp claim).

However, my concern with only using dates is the lack of "Termination
Reason" transparency. In a governance context, if an Agent is killed, the
Relying Party might need to know why (e.g., "Terminated by Authority" vs.
"Routine Expiration").

Question: Would it be appropriate to define a hybrid approach within the
EAT profile?

Standard Claims: Use iat (Issued At) and exp (Expiration) to handle the
60-second liveness window (per your date suggestion).

Custom Claim: A specific aiga_status claim (e.g., active, suspended,
revoked) to allow the Relying Party to distinguish between a "stale" agent
and a "banned" agent?

I want to ensure we stay compliant with standard CWT/EAT practices while
preserving that audit trail.


          Respectfully,

*          Edward R. Aylward II*          [e-mail]
          702.684.4607 <7026844607>


On Wed, Jan 14, 2026 at 9:19 AM Michael Richardson <[e-mail]>
wrote:

>
> Edward Aylward <[e-mail]> wrote:
>     > My Questions for the WG:
>     > 1. Does the RATS architecture support a model where the "Relying
> Party"
>     > (the network peer) is distinct from the "Verifier" (the Governance
> Node) in
>     > a real-time loop?
>
> Explicitely, see figure 1 of RFC9334.
>
>     > 2. Are there existing EAT claims (CWT/JWT) best suited for
> representing
>     > "Operational State" (e.g., Active vs. Terminated), or would this
> require a
>     > custom profile?
>
> Seems like a specific claim would be worthwhile.
> I would not make it an on/off.
>
> I would make it a date:
>   Agent-Last-Activated: YYYY-MM-DD
>   Agent-Last-Deactivated: YYYY-MM-DD
>
> it would work like notBefore/notAfter in certificates.
>
>     > I would appreciate any guidance on whether this use case fits within
> the
>     > current RATS charter or if there are existing profiles I should
> reference
>     > to align Section 5.1 with standard practices.
>
>
> --
> Michael Richardson <[e-mail]>   . o O ( IPv6 IøT consulting )
>            Sandelman Software Works Inc, Ottawa and Worldwide
>
>
>
>
>