Discuss the overlap and comparison with IETF's RATS framework

Hi folks, I work on confidential VMs and am trying to get an internally built binary that we run in production to have a fully transparent verifiable remote attestation that matches binary digest all the way back to a public source repository at some commit hash. That's what I really like about in-toto and SLSA.

What I'm trying to understand is how to integrate the software attestation of in-toto with a whole target environment the way that the Internet Engineering Task Force (IETF) Remote ATtestation procedureS (RATS) framework is seeking to do. Where RATS refers to integrity manifests with Reference Values and Endorsements, I see a lot of connections to in-toto and opportunities for in-toto's richness to improve the attestation framework as a bit of combination of all that. Furthermore claims in an entity attestation token (EAT) appear to be synonymous with in-toto's notion of a predicate. The difference is really the IANA number assignment to claims, whereas in-toto has claims defined by URI to the schema.

RATS synthesizes multiple software integrity manifests and hardware integrity manifests with a trusted policy evaluator that issues attestation tokens (EATs). working group for "reference integrity manifests" called CoRIM https://datatracker.ietf.org/doc/html/draft-ietf-rats-corim-03 is seeking to do.

It seems that where CoRIM has tags for software identity that go so far as file digests and version number claims, in-toto's SLSA predicate has more fine-grained evidence that links Reference Values to software identities where software identity isn't a name and version but the culmination of all of the code, how the code is produced and securely stored and built.

Do you see this standard merging with RATS's favored formats of EAT (JWT or CWT) and CoRIM, or existing separately as an alternative carrier format within the RATS framework?

Start by comparing the RATS, EAT, and CoRIM references in the issue with the existing in-toto and SLSA specification documents. Define whether integration should use EAT or CoRIM, remain a separate carrier format, or require a broader standard change; done means documenting a clear comparison and agreed direction.

Written by the indexing model from the issue text.