RATS Architecture and Attestation Evidence Formats

A remote party has to decide whether to trust a system it can't touch, can't open up, and can't watch run. RFC 9334, the document defining RATS (Remote Attestation Procedures), gives that party a structured way to get real evidence about a device's state. That's the whole subject of this piece, and it's worth taking slowly, because the architecture rewards patience more than it rewards speed-reading.

Trust in networked systems has, for decades, come down to three things: where a device sits on the network, what credentials it presents, or what it claims about itself. None of these tell you what's actually running on the machine right now. A laptop behind the right firewall segment gets treated as trustworthy because of where it sits, not because anyone checked its boot state. A device with a valid TLS certificate gets treated as legitimate, even though a certificate says nothing about whether its firmware got patched or its bootloader got tampered with somewhere along the way. This arrangement has worked, more or less, mostly because attackers had easier ways in for a long time. But as attacks move down the stack toward firmware, hypervisors, and boot chains, the gap between "who are you" and "what state are you in" starts to matter in a way it didn't a decade ago.

TEE-based key release, network access control for IoT fleets, confidential computing workloads in the cloud: all of these need to know something about the actual runtime state of a remote system, not just its identity. A compromised device can hold a perfectly valid certificate while running software that's been quietly modified underneath it. Identity and integrity are different questions, and for a long time the industry only had good tools for the first one.

RFC 9334, published January 2023 by the RATS Working Group with authors from Fraunhofer SIT, Microsoft, Intel, and Huawei, specifies a vocabulary: roles, message types, interaction patterns that let an Attester produce verifiable Evidence about itself, a Verifier appraise that Evidence, and a Relying Party act on the result. Everything else in the RATS ecosystem, the token formats, the manifest formats, the results vocabulary, builds on top of this architecture.

How RFC 9334 carves the problem into distinct roles

Six roles, and each one gets defined by what it produces and consumes rather than by what hardware or software happens to implement it. That distinction matters more than it sounds like it should.

The Attester generates Evidence about its own state: measurements, configuration data, telemetry, whatever it can honestly say about itself. The Verifier takes that Evidence and appraises it against policy, against Endorsements, against Reference Values, and produces Attestation Results. The Relying Party consumes those Results and makes the actual trust decision, whether that's granting network access, releasing a key, or letting a workload proceed. Behind the Verifier sit two supply roles: the Endorser, who supplies manufacturer or supply-chain credentials like device certificates, and the Reference Value Provider (RVP), who supplies the expected measurements the Verifier checks Evidence against. Rounding it out are the Verifier Owner and Relying Party Owner, the administrators setting appraisal policy on each side.

A single entity can hold multiple roles at once, and multiple entities can cooperate to implement a single role. The spec leaves this open on purpose, and honestly, this is the part that trips people up on a first read. A constrained IoT sensor might combine Attester and Endorser functions because there's no room on the device for a separate identity system. A multi-tenant cloud provider might split the Verifier role across several internal services, each handling a piece of the appraisal. An enterprise supply chain might have a manufacturer, a distributor, and an owner all contributing Endorsements for the same physical device. None of that breaks the architecture, since the architecture concerns what gets said and by whom, rather than topology.

Worth noting where the RATS Working Group actually drew its own boundary. Formats and protocols for Evidence, Attestation Results, Endorsements, and Reference Values sit in scope. Appraisal policy formats, meaning the actual rules a Verifier applies when it decides whether Evidence looks good, sit explicitly out of scope, left to implementers and other standards bodies to sort out. Narrower mandate than it looks at first glance. That narrowness is probably why the architecture has held steady while everything built on top of it keeps evolving.

The conceptual messages that flow between roles

Section 8 of RFC 9334 defines a set of Conceptual Messages, a fairly dry name for something doing a lot of quiet work underneath it. These are protocol-agnostic: they describe what a message means and what it's for, without touching wire format, encoding, or transport. The initial set covers Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies.

Evidence is the claims an Attester generates about its own runtime state: configuration data, measurements, telemetry, sometimes inferences drawn from those measurements. Endorsements are supply-chain assertions, usually from a manufacturer or distributor, backing up what an Attester says about itself. Reference Values are the expected measurements an RVP supplies, the known-good baseline the Verifier checks Evidence against. Attestation Results are the Verifier's output, a structured verdict the Relying Party can actually act on.

Defining all of this at the conceptual level, rather than picking a wire format and shipping it, lets the same architecture run over DTLS, CoAP, HTTP, or whatever transport a deployment already has in place, without redefining the trust model every single time. A constrained sensor network running CoAP and a data center running HTTP can both implement RATS without either one adopting the other's protocol stack.

There's an asymmetry buried in here that's easy to skim past. If Evidence conflicts with an RVP's Reference Values, say a compromised Attester produces claims that don't line up with what the RVP expects, those Reference Values don't get folded into the appraisal state as though they were confirmed. The architecture protects the Verifier's output from getting polluted by an Attester that's already lying to it. Small design choice. But it's the kind of thing that tells you whoever wrote this had already thought through adversarial conditions rather than bolting that thinking on afterward.

Two topological models for routing those messages: Passport and Background-Check

Section 5 lays out two principal ways to route these messages between roles. Neither one wins in some absolute sense; each fits a different set of deployment constraints, and a lot of real-world confusion about RATS traces back to someone forcing one model onto a use case that actually wanted the other.

In the Passport Model, the Attester sends Evidence directly to the Verifier. The Verifier appraises it and hands back Attestation Results, often packaged as a token, to the Attester. The Attester then carries that token around and presents it to the Relying Party whenever it needs to. The name fits well enough: the Attester holds its own credential, the way a passport holder carries a document issued once by a trusted authority and shows it at every border crossing afterward. This suits situations where the Attester can reach a Verifier on its own, device onboarding being the obvious example.

In the Background-Check Model, the flow bends the other way. The Attester sends Evidence to the Relying Party, and the Relying Party forwards it to the Verifier. The Verifier sends Attestation Results straight back to the Relying Party, not to the Attester, and the Relying Party never inspects raw Evidence on its own; it only ever sees the finished verdict. This fits cases where the Relying Party already has a standing relationship with a Verifier but the Attester doesn't. Server-side verification of a client-side TEE is the common case here.

RFC 9334 explicitly allows both models to run at the same time on the same device, for different purposes, and that's the part worth sitting with. A device might use the Passport Model to join a network, presenting its own attestation token at the door, then use the Background-Check Model minutes later to access confidential data on a server that never talks to it directly. TEEP, the Trusted Execution Environment Provisioning protocol, gives a concrete picture of Background-Check in practice: a Trusted Application Manager checks a TEE's state through remote attestation and, depending on what it finds, installs, updates, or removes applications to bring that TEE back into compliance.

How freshness is guaranteed across both models

Neither model means much if the messages inside it can get replayed. An Attestation Result or a piece of Evidence not tied to a specific moment in time can get captured by an attacker and reused later to impersonate a system that's since been compromised. This is the freshness problem, and Appendix A of RFC 9334 works through several solutions, mapped against each of the two models above.

In the Timestamp-Based Passport Model, Evidence carries a timestamp, and the Relying Party checks that it falls inside an acceptable window. In the Nonce-Based Passport Model, the Verifier issues a nonce the Attester has to fold into its Evidence, binding the resulting token to one specific challenge session rather than to a general point in time. There's also a Passport Model Based on Epoch ID, where a shared epoch identifier stands in for both timestamp and nonce, useful where clocks and state are already synchronized across the system. The Background-Check Model gets its own timestamp-based and nonce-based variants, working the same way except the Relying Party, not the Verifier, drives the challenge.

A separate draft on reference interaction models, published July 22, 2024, adds three conveying mechanisms with their own freshness properties. Challenge/Response uses a nonce issued by the Verifier or Relying Party to give freshness a cryptographic anchor. Uni-Directional skips the challenge step entirely and leans on timestamps or epoch IDs, simpler to run but dependent on clocks staying in sync across the system. Streaming has Evidence flowing continuously, with freshness coming from the cadence of the stream itself rather than any single challenge-response round trip.

One thing worth clearing up, because it confuses people: "remote" in RATS doesn't require actual network distance. If the Verifier is running right next to the Attester, same board, even the same chip package, the Evidence exchange can be entirely local, and the freshness mechanisms still apply exactly the same way. Remote here describes a relationship of trust, not a distance on a map.

EAT: the token format that carries Evidence and Results

RFC 9334 gives you the vocabulary. A token format arrives separately: the Entity Attestation Token, published as RFC 9711 in April 2025. EAT is the main standardized token format across the RATS ecosystem right now, and it's worth being precise about what kind of thing it actually is, because "token format" undersells it a little.

EAT is a framework, encompassing more than a single token definition. It's built on top of CBOR Web Token (CWT) and JSON Web Token (JWT), extended with attestation-specific claims and a type system defined in CDDL, the Concise Data Definition Language. Because the claims get defined once in CDDL, the same definition can drive either a CBOR/CWT serialization or a JSON/JWT one, whichever fits the deployment. Security wrapping comes from COSE on the CBOR side and JOSE on the JSON side, both well-worn signing and encryption standards already doing this job elsewhere.

EAT's claims lean directly on RATS Architecture language. Evidence, in EAT terms, is exactly what RFC 9334 says it is: a set of claims, configuration data, measurements, telemetry, sometimes inferences, that an Attester produces for a Verifier to appraise. Nonce handling reflects the freshness discussion from the architecture document too. In the CBOR encoding, a nonce is a byte string between 8 and 64 bytes, or an array of them; in JSON, a nonce is a text string between 8 and 88 characters, or an array. Small detail, but it shows how directly EAT was built to serve the architecture rather than invent its own competing vocabulary.

EAT also supports submodules, nesting claims sets and even whole tokens inside other tokens. Matters a lot for compound devices: a system with multiple security subsystems, say a main processor and a separate secure enclave, can express attestation evidence from each component nested inside one outer token, rather than needing an entirely separate channel per subsystem. The profile mechanism is what keeps EAT a single format instead of splintering into a dozen incompatible dialects: a TEE attestation profile, an IoT onboarding profile, a network equipment profile, each pins down which claims are required and how they're encoded, without forking the base spec.

CoRIM: the format that supplies Reference Values and Endorsements to the Verifier

EAT tells you what the Attester says about itself. CoRIM tells you what the manufacturer, or whoever supplies reference values, says the Attester ought to look like. The Verifier needs both sides to do its job, and CoRIM, the Concise Reference Integrity Manifest, carries the second one.

As of October 2025, CoRIM is active as draft-ietf-rats-corim-09 on the IETF Standards Track, specifying Endorsements and Reference Values in CBOR. It's built around CoMID triples, Concise Module Identifier structures, essentially structured assertions about an Attesting or Target Environment and its security-relevant features. Reference Values triples carry the expected measurements a Verifier matches Evidence against, the known-good baseline. Endorsed Values triples cover properties of an environment that wouldn't show up in Evidence at all, certified features a device carries from the factory, for instance. Device Identity triples carry cryptographic credentials, an IDevID being the standard example, that uniquely identify a specific device. The triple set isn't fixed either; new triple types can get added for domain-specific needs, testing data or certification records among them.

The same conflict-handling logic from RFC 9334 shows up again here, and it's not an accident. If a compromised Attester produces Evidence that contradicts what an RVP says through CoRIM, those RVP claims don't get folded into the appraisal state as though confirmed. Same design principle, applied one layer down: the architecture assumed Evidence and Reference Values might disagree someday, and it has an answer ready for when they do.

In practice, CoRIM is how a manufacturer's or distributor's authoritative knowledge about a device reaches the Verifier without passing through the Attester itself. That's not a small point. If the only source of truth about what a device should look like came from the device, a compromised device could just lie about its own baseline too, and the whole appraisal collapses into circular reasoning. CoRIM keeps that knowledge with the Endorser and the RVP, sitting outside the Attester's reach entirely.

AR4SI and EAR: standardizing what the Verifier sends back

EAT gives you the envelope for a token. Standardizing what actually goes inside an Attestation Result is a separate piece, still getting worked out through a couple of active Internet-Drafts rather than a finished RFC.

AR4SI, Attestation Results for Secure Interactions, is active as draft-ietf-rats-ar4si-09 as of August 2025. It specifies three required pieces inside an Attestation Result: Identity Evidence for the Attester, answering who's actually being attested; a Trustworthiness Vector, a structured, multi-dimensional appraisal of the Attester's state rather than a single up-or-down verdict; and a Verifier Proof-of-Freshness, confirming the appraisal is current rather than stale data from an earlier session. AR4SI also defines a Relying Party Proof-of-Freshness, bound to the result through the Attesting Environment's signature, tying a given result to one specific Relying Party interaction so it can't float free and get reused somewhere else.

EAR, EAT Attestation Results, is the companion draft mapping AR4SI's vocabulary into actual EAT claims. Matters because it means the Relying Party ends up with a signed token, the same kind of object it would get from any other EAT-based exchange, rather than some bespoke data structure with its own parsing rules to learn.

Why does the Trustworthiness Vector matter this much? A binary pass or fail throws away nearly everything useful about a device's actual state. A device might have a fully patched bootloader but an out-of-date application layer sitting on top of it; a Trustworthiness Vector lets the Verifier say so across multiple dimensions at once, and lets the Relying Party's own policy, set by the Relying Party Owner, decide which dimensions actually matter and at what threshold. One Relying Party might tolerate a slightly stale application layer as long as the boot chain checks out; another won't touch it. The vector gives both of them room to set their own bar. This part of the stack is still moving, worth saying plainly: RFC 9334 and RFC 9711 are published standards, but AR4SI and EAR remain drafts, and anyone building against them today has to treat the Results vocabulary as something that can still shift underneath them before it settles.

CMW: the wrapper that lets these formats move across different protocols

One thing left to tie together. EAT, CoRIM, and the AR4SI/EAR results vocabulary are all different formats, built at different times, for different pieces of the RATS puzzle. Something needs to let them travel across whatever protocol a given deployment actually runs, without each one needing its own bespoke handling bolted on separately.

That's the job of CMW, the Conceptual Messages Wrapper, currently progressing as draft-ietf-rats-msg-wrap-22, last updated December 2025, and not yet an RFC. CMW gives any RATS Conceptual Message, Evidence, Endorsements, Reference Values, Attestation Results, a common encapsulation structure, so a system handling one type of message doesn't need entirely separate plumbing for the others. It's the connective layer that makes the rest of this architecture practical to implement in a real system, tying together formats that otherwise merely share a common ancestor in RFC 9334.

An architecture document defining roles and message meanings, a family of formats giving those messages concrete shape, and a wrapper letting all of it move across whatever wire a deployment happens to use: none of these pieces do much on their own. This kind of trust-by-design thinking shows up in AI too, in tools like Confidant AI, a private AI assistant built so user data is never collected or monetized. The interlocking is the actual standard, and it's worth remembering that RATS is still a moving target in places (AR4SI, EAR, and CMW are all drafts as of this writing), which means anyone building on this today is building on a foundation that's mostly, but not entirely, poured.