]> Tyche Institute

Tallinn Estonia anton.sokolov@tyche.institute

Security Remote ATtestation ProcedureS (RATS) attestation evidence AI agents accountability This document sketches a composition pattern in which an application-layer "action evidence package" (AEP) -- a signed action record that can be hash-linked to earlier records and that reports an action taken by an automated (for example, AI-agent) system, the authority under which it was taken, and its outcome -- is treated as Evidence in the sense of the RATS Architecture (RFC 9334) and bound to platform Evidence produced by a hardware root of trust. The intent is that a single Verifier, or a composition of Verifiers, can appraise both the platform state and the application-layer record together, and emit an Attestation Result that a Relying Party can use to reason about what an automated system reports it did and the appraised state of the platform associated with that record. The composition does not turn a self-reported action or outcome into an independently observed fact; it prevents the Relying Party from having to rely on an unbound operator-side log alone. This is an individual sketch intended to ask the working group whether the pattern is already covered by existing mechanisms or warrants a short document.

Introduction Records of automated decision-making are increasingly produced for accountability purposes: an action identifier, an authorising principal, inputs and tool calls, and an outcome, optionally hash-linked so that later modification is detectable. Such an action evidence package (AEP) is useful but has the standard self-report limitation: every field is asserted by the same software stack whose integrity is in question. The signature proves the record was produced by a key the runtime holds; it does not prove what the runtime was. The RATS Architecture separates the party that produces Evidence (Attester), the party that appraises it (Verifier), and the party that acts on the verdict (Relying Party). Binding an AEP to platform Evidence appraised under RATS anchors the self-report to an independently appraised platform state, but does not independently observe the action or its external effect. This document describes the composition and asks whether it is novel enough to specify.

Conventions and Definitions The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 when, and only when, they appear in all capitals, as shown here. This document uses RATS terminology as defined in : the roles Attester, Verifier, Relying Party, Endorser, and Reference Value Provider, and the conceptual messages Evidence, Endorsements, Reference Values, and Attestation Results.

Scope This document defines a composition pattern and a provisional claim vocabulary. It does not define an appraisal algorithm, mandate language, discovery protocol, transparency service, or authorisation policy. In particular, a Verifier decides how Evidence supports an Attestation Result, and a Relying Party decides whether that result and the referenced authority permit an action. The examples in this document do not turn an application authorisation decision into a RATS trustworthiness claim.

Named Entities and Trust Boundaries RATS roles are functions rather than deployment units. The following entities name the functions used in this composition. An implementation can co-locate them, but it MUST preserve the role and key boundaries in its evidence and policy records.

Action Principal

The person or organisation whose authority is referenced by the action. This is an application role, not a new RATS role.

Mandate Issuer

The entity that signs or otherwise authenticates the bounded authority. It can also be an Endorser only when it separately vouches for capabilities of the Attester in the sense of ; signing a mandate does not by itself produce a RATS Endorsement or appraise platform Evidence.

Agent Runtime Attester

The entity that produces the AEP Evidence. In the minimal deployment, it contains a software Attesting Environment implemented by the action recorder and a co-located runtime Target Environment whose behaviour is being reported. Co-location is permitted by but leaves the AEP as a self-report until it is bound to independently appraised platform Evidence.

Platform Attesting Environment

The TPM- or TEE-backed combination that collects Claims about the platform Target Environment, protects the attestation key, and produces platform Evidence. A TPM alone does not collect Claims; the measurement component that feeds it is part of the Attesting Environment. This environment binds the AEP digest or linking claim to measured state.

Verifier

The entity that appraises the AEP Evidence and platform Evidence against Appraisal Policy for Evidence, Reference Values, and Endorsements, and emits an Attestation Result.

AgentRuntimeEndorser

A legacy deployment label for a service that may appraise runtime Evidence, validate a mandate, and issue an application-layer statement binding the appraised runtime to that mandate. That statement is not a RATS Endorsement merely because of the deployment label, and the label is not a new RATS role. A deployment that combines Verifier, Endorser, and application binding functions MUST identify which output was produced under which function, key, and policy.

Relying Party

The entity that consumes the Attestation Result and application authority and decides whether to accept the action or its record.

Audit Consumer

An auditor or audit service that correlates the AEP with interaction, delegation, authorisation-transition, and service-side records. This aligns with the consumer role in .

The deployment Trusted Computing Base (TCB) includes the action recorder and binding gate, the Platform Attesting Environment, the Verifier implementation and policies, the configured trust-anchor path for Endorsements and Reference Values, and the keys used to authenticate mandates and results. Artifact stores, mirrors, and transports need not be trusted for integrity when every consumed object is authenticated and freshness-checked. This TCB statement is deployment guidance; TCB is not introduced as a RATS architectural role.

The Action Evidence Package An AEP is an application-layer, signed action record. For the purposes of this document its salient properties are: (a) it reports an action, an authorising principal, and an outcome; (b) it can link to a predecessor for tamper-evidence, although a hash chain alone does not prevent truncation or equivocation; and (c) it is produced by the same software stack that performs the action. Property (c) is precisely why it benefits from composition with platform Evidence. More precisely, this document distinguishes the AEP Record from the AEP Evidence profile. The AEP Record can contain a richer event log. The AEP Evidence profile is an EAT Claims-Set that identifies one action and binds digests of the authority, canonical action, outcome, optional predecessor record, and platform Evidence. A conversation record such as or a distributed audit record such as can be carried as a submodule only when encoded as one of the submodule forms permitted by ; otherwise it can be referenced by a separately defined integrity-protected digest. It is not copied wholesale into every claim.

Provisional AEP EAT Claim Vocabulary The surrounding EAT Claims-Set can use the iat, exp, eat_nonce, and submods claims according to and the selected encoding. The following new application claims are expressed in CDDL and use provisional string labels for review. The CDDL deliberately does not restate the standard EAT claims: their labels and value types differ between CBOR and JSON, and a full profile must select and specify those encodings. This document does not request numeric claim keys or reserve an IANA code point. In particular, the text-labelled CDDL below is a vocabulary review aid and is not, by itself, a valid CBOR-encoded EAT profile: requires CBOR-encoded EAT claim keys to use integer labels. tstr, "aep_authority_ref" => digest-ref, "aep_action_digest" => digest-ref, "aep_outcome_digest" => digest-ref, ? "aep_previous_digest" => digest-ref, "aep_platform_evidence_ref" => digest-ref, ? "aep_audit_context" => audit-context } digest-ref = { "hash_alg" => "sha-256", "digest" => bstr } audit-context = tstr ]]> Each digest covers a deterministic byte string selected by the profile using the stated hash algorithm. The profile or vector MUST identify those exact bytes and any canonicalisation rule; hashing an ambiguous in-memory object or an unspecified JSON serialisation does not produce an interoperable binding. This revision does not define a complete EAT profile in the sense of Section 6.3 of : the encoding, serialisation, protection, and claims-requirement items listed there are not settled by the prototype reported here. Section 6.2 of states that the eat_profile claim MUST NOT be used to identify a partial profile, so this revision names none and presents the vocabulary with text labels only. Settling those items, and stating the CBOR and JSON encodings, is expected before any profile identifier or numeric label assignment is proposed.

aep_action_id

An identifier unique in the action producer's domain. It supports duplicate and replay detection but is not, by itself, proof of uniqueness.

aep_authority_ref

A digest of the exact mandate, grant, or other authority evaluated for this action.

aep_action_digest

A digest of the canonical action request as observed at the point where effect can occur.

aep_outcome_digest

A digest of the canonical outcome or effect record. A success assertion without independently observable effect evidence remains an application-layer claim.

aep_previous_digest

The digest of the preceding AEP Record when the producer maintains a hash chain.

aep_platform_evidence_ref

The linking digest for the platform Evidence or Attestation Result bound at record time.

aep_audit_context

An opaque, producer-scoped correlation handle that lets an Auditor relate this record to the surrounding Interaction, Delegation, and Authorization Transition Records. Its internal structure is deployment-defined: proposes its own context-propagation fields, and this document does not restate them. It is correlation context, not an authorisation decision, and it can be identifying; see .

The AEP Evidence Claims-Set MUST receive integrity protection that covers the action, authority, outcome, and platform references. This revision does not select the EAT protection mechanism or algorithms; a full profile must do so. A locator, if used to retrieve a detached object, is not a substitute for an integrity-protected digest.

Composition with RATS The composition treats the AEP as application-layer Evidence conveyed alongside platform Evidence:

1. The platform produces hardware-rooted Evidence (for example, a TPM quote over measured-boot registers, or a TEE attestation token), appraised against Reference Values (for example, conveyed as a Concise Reference Integrity Manifest ) and Endorsements by a Verifier.
2. The AEP Evidence profile is conveyed as a further Evidence item. Candidate conveyances are an EAT whose Claims-Set carries the AEP Evidence claims, or a Collection CMW -- the RATS Conceptual Message Wrapper -- that groups platform Evidence and the AEP Evidence into one message. EAT submodules can carry a nested Claims-Set, nested token, or Detached-Submodule-Digest; the last of these is a digest of a detached Claims-Set and is not a generic digest wrapper for an arbitrary AEP Record.
3. A Verifier -- or, following the layered Platform-Verifier / Workload-Verifier pattern of , a platform Verifier and an application Verifier in composition -- appraises both and emits an Attestation Result.

The binding between the two is load-bearing: the AEP, at record time, SHOULD incorporate a reference to a fresh platform appraisal (or to the platform Evidence and the nonce that scoped it), so that a later Relying Party can ask not only "what does the automated system report that it did, and under what authority?" but "and is that report bound to a platform whose state was independently attested within the same freshness window?". The Section 10 freshness mechanisms -- nonces, synchronised-clock timestamps, and Epoch IDs/handles -- apply unchanged. When the composition is modelled as Evidence for a composite or layered Attester in a single Collection CMW, Section 8.2 of requires the Evidence messages to be cryptographically bound together. The binding need not be an outer signature: it can be achieved through identifiers or linking claims, such as nonces, across the collection's items. An integrity-protected digest link from the AEP Evidence to the corresponding platform Evidence can contribute to that binding, but the collection designer must ensure that the complete set of items is protected against substitution as Section 8.2 requires.

Discovery and Bootstrap This composition does not assume zero-input discovery. Before it can accept an Endorsement, Reference Value, Verifier result, mandate, or AgentRuntimeEndorser output, a deployment has at least one local input: for example, a configured trust anchor, a configured signed trusted-list URI, or a provisioning channel. DNS, DHCP, Web discovery, and registries can distribute locators, but none creates authority without a configured acceptance rule. In one deployment pattern, the Relying Party starts from a configured URI for a signed trusted list. It authenticates the list to a locally configured root, checks list status, validity and service history, and uses the resulting entry to locate an AgentRuntimeEndorser. Authority therefore traces to the configured root and policy, not merely to possession of an endpoint key.

AR4SI Projection and Application Decision The composition has two outputs that must not be collapsed. First, a Verifier can emit an EAR containing an AR4SI trustworthiness vector for facets it actually appraised. Second, application policy computes Authorised, Unauthorised, or Indeterminate from the authority and action claims. The application decision is not an AR4SI tier. This document proposes no projection of its own. What follows is a report of the values one open-source Verifier returned when the platform-side experiment was exercised against it, as described in :

• in the good state, the Verifier populated executables with the affirming value 2;
• when the selected PCR composite diverged from the provisioned Reference Value, it populated executables with 33, a warning-tier value, while returning an overall contraindicated status;
• when one byte inside the signed attestation structure was altered, it set 99 on every facet and returned contraindicated, recording a signature-verification problem;
• in Cases A and B the remaining facets carried the value 0. AR4SI defines that value as "No assertion": the Evidence was insufficient to make a conclusion. Although AR4SI describes an absent facet as not applicable to the submitted Evidence, it says that a Relying Party's appraisal policy should not distinguish value 0 from no Trustworthiness Claim; neither form makes a trustworthiness assertion.

No projection is proposed for the action axis either. Whether a composition of this kind warrants an additional trustworthiness claim, or is better reported through the application decision alone, is left as a question for the working group. AR4SI values are signed 8-bit integers grouped into none, affirming, warning, and contraindicated tiers. The exact method by which a Verifier derives them is out of scope, consistent with AR4SI. Freshness is also separate: an expired result or nonce mismatch can make an otherwise valid appraisal inapplicable without inventing an "expired" AR4SI tier.

Grounded Use Case: A Bounded Payment Action A person approves a mandate allowing an automated runtime to pay one named supplier up to a fixed amount before an expiry time. The runtime later submits a payment instruction to a service. At the point where the instruction can take effect, the recorder creates an AEP with: the mandate digest in aep_authority_ref; the canonical instruction digest in aep_action_digest; the service result digest in aep_outcome_digest; and the current platform Evidence reference in aep_platform_evidence_ref. For an authorised Auditor, the audit context can correlate the AEP with records identifying the person, runtime, parent approval event, and authorisation state in force. The Verifier appraises the runtime and platform Evidence and emits an EAR. The Relying Party separately checks that the mandate is valid, the supplier and amount are in scope, the action and outcome digests match the records it observed, the action identifier has not been consumed, and the EAR is applicable now. An Auditor can then correlate this AEP with the Interaction, Delegation, Authorization Transition, and service-side Action Records described by . The use case is grounded because each acceptance and refusal condition corresponds to an observable claim or adjacent record; it does not require disclosure of a model's internal reasoning.

Test Vectors An implementation experiment should publish positive and negative vectors for at least the following cases. The Verifier run described in exercises the platform-axis conditions of V2 and V3 and the good-state platform conditions of V1. It does not exercise V4: the run submitted no stale replay, and the unmodified reference scheme performed no nonce comparison, as records. The outcome-substitution case of V5, and V6 in its entirety, are specified here and are not claims about that run:

V1 — known instance and approved measurement

The attestation key and PCR composite match provisioned material, all AEP digests bind, and the nonce is fresh. The EAR is affirming for the supported facets; application authorisation is evaluated separately.

V2 — measurement substitution

The quote remains correctly signed but the PCR composite differs from the Reference Value. The exercised Verifier reports executables=33 in the warning tier and an overall contraindicated EAR status.

V3 — forged platform Evidence

One byte in the signed attestation structure is changed. Cryptographic validation fails and the result is contraindicated.

V4 — stale replay

A previously valid quote is submitted in a session with a different expected nonce. Evidence appraisal must fail closed even though the old signature and PCR value remain valid.

V5 — action or outcome substitution

The platform Evidence is retained while the canonical action or outcome object is changed. The changed object no longer matches the integrity-protected digest in the AEP Evidence; when the outcome digest also contributes to the signed platform Evidence, outcome substitution breaks that reverse binding as well. The Relying Party rejects the record.

V6 — authority substitution or replay

The action is paired with another mandate, or a consumed aep_action_id is reused. Platform appraisal can remain affirming, but application policy returns Unauthorised. This vector demonstrates why AR4SI and authorisation verdicts are separate.

Each vector must identify the exact input bytes, expected layer of rejection, expected EAR fields when an EAR is produced, and expected application decision. A single boolean "valid" result is insufficient for cross-implementation diagnosis.

Prototype Observations (Informative) The appraisal algorithms and evidence-scheme implementation are out of scope. The prototype is retained only to show that the named bindings and refusal cases can be exercised and to derive the minimal result report and test vectors above. A small emulated feasibility check (software TPM via swtpm, with a minimal Verifier stand-in) folds the hash of a synthetic AEP Record, which includes its outcome digest, together with a fresh nonce into an attestation-key-signed quote, with a model-artefact measurement in a platform register. It resolves the three platform-axis cases and shows that the old quote fails validation when checked against different expected AEP-derived qualifying data. This is a binding-sensitivity check, not an appraisal of the truth of the reported outcome or a complete implementation of the AEP Evidence Claims-Set. It is emulated and minimal; it demonstrates the cryptographic mechanism, not a hardware-rooted guarantee. Details are in .

Appraisal by an Open-Source RATS Verifier To compare the platform-side result vocabulary against a real Attestation Result rather than a stand-in, the TPM Evidence and its AEP-outcome-digest measurement were exercised against an instance of the open-source Project Veraison implementation of the RATS Verifier role, built and run locally. The run did not implement the provisional AEP Evidence Claims-Set, convey an AEP and platform Evidence in one Collection CMW, or ask the Verifier to appraise application authorisation. It is therefore a platform-side feasibility exercise, not an end-to-end implementation of the composition. This is an independent exercise of an open-source implementation; it is NOT a claim that the implementation, experiment, or AEP profile is conformant, and it does not imply endorsement or partnership with the Veraison project. The platform Attesting Environment used an emulated software TPM (swtpm), not a hardware root of trust. A fresh EC P-256 Attestation Key (AK) was created in the swtpm; the AEP outcome digest was measured into a Platform Configuration Register (PCR 4); and a genuine swtpm TPM quote was produced over PCRs 1-4 with the freshness nonce as qualifying data. The quote was packed into the Verifier reference TPM evidence wire format (NODE_ID || SIZE || TPMS_ATTEST || TPMT_SIGNATURE). A Concise Reference Integrity Manifest (CoRIM) was provisioned carrying two items keyed by a single instance identifier: the AK public key as a trust anchor, and the golden PCR composite digest as a Reference Value. The quote was then submitted through one challenge-response session per appraisal, and the Verifier returned a signed EAR. The verdicts below were read from the decoded EARs, which used the Verifier's own profile:

• Case A, good state with the AEP outcome digest measured into PCR 4: the Verifier returned ear.status "affirming".
• Case B, PCR 4 re-measured with a different outcome so the PCR composite digest diverges from the golden Reference Value: "contraindicated".
• Case D, one byte flipped inside TPMS_ATTEST so the quote signature no longer verifies against the AK: "contraindicated" (tampered platform Evidence, rejected).

Case A was independently re-verified outside the Verifier: the quote PCR digest equals the provisioned golden value, and the signature verifies against the AK public key. These are the two substantive appraisal checks independently repeated here, not an exhaustive description of the Verifier's parsing and trust-anchor processing. The results confirm the observed affirming/contraindicated distinction used by the test vectors; they do not show that the reference scheme emitted every AR4SI facet proposed in . Freshness is a separate condition, and the reference scheme used here did not enforce it, which motivates the freshness consideration below.

Security Considerations Composition does not dissolve trust assumptions; it relocates them. The platform axis depends on the provenance and protection of the Attesting Environment, applicable Endorsements or directly configured trust anchors, Reference Values, and the Verifier's independence. The AEP axis depends on the action recorder and its signing key. Platform Evidence grounds that key or recorder only when the deployment measures or otherwise binds them into the appraised state; the experiment reported here binds an outcome digest, not the AEP signing key or the truth of the reported effect. Binding an AEP to a platform appraisal is only as fresh as the weaker of the two freshness mechanisms. Attesting a specific model or workload version requires that artefact be measured into the attested state, which is a deployment commitment. If a composition claims the reverse output-binding exercised here, a forged AEP outcome presented under otherwise-valid platform Evidence MUST be detectable: the outcome digest must contribute to data covered by the platform Evidence's integrity protection. A one-way AEP reference to platform Evidence alone does not establish that property. The feasibility note and the appraisal in demonstrate the cryptographic binding in software-TPM emulation. Using a hardware TPM can strengthen key protection, but it still proves only that the supplied digest contributed to the quoted state; the truth of the action or external effect depends on the recorder and measurement path.

Evidence Freshness and Result Applicability Are Separate The platform-side appraisal above surfaced a freshness observation worth recording for implementers. A challenge-response transport supplies a session nonce, and the EAT freshness mechanisms of RFC 9711 are available; but whether the nonce is actually enforced depends on the Verifier appraisal scheme, not on the transport. In the unmodified reference TPM scheme exercised here, the appraisal performed quote-signature and PCR-reference checks, but it did not compare the nonce the Attester bound into the quote qualifying data (the ExtraData field of TPMS_ATTEST) against the session expected nonce. As a result, a replayed or stale quote, correctly signed over a matching PCR state, could still be appraised as affirming. The unmodified run applied no freshness check at any layer: neither the reference scheme nor the surrounding experiment compared the bound nonce against the session expected nonce. Evidence freshness belongs in the Verifier's Appraisal Policy for Evidence. The idiomatic remedy has two small, separable pieces and applies generally to any scheme whose Evidence carries an attester-bound nonce in signed qualifying data: (1) the appraisal scheme surfaces the attester-bound qualifying data (here, TPMS_ATTEST.ExtraData) as an extracted claim, so that an appraisal policy has a value to compare; and (2) the appraisal policy compares that claim against the expected nonce retained for the session and returns a contraindicated verdict when they differ. If a deployment cannot perform that comparison inside the Verifier, the outer application must fail closed and record the compensating check rather than silently treating the otherwise-affirming result as fresh. This is an observation about a community-maintained reference scheme, not a deployed production trust service. The Relying Party has a separate freshness decision after the Verifier issues an Attestation Result. At the moment it performs an operation, it decides whether that result remains applicable under its Appraisal Policy for Attestation Results and its application policy. This includes any result expiry or local maximum age, binding to the exact AEP, action and request context, and single-use or consumed state where the application requires it. A historical record can remain cryptographically valid while no longer authorising a replay. The effective freshness of an AEP/platform composition is therefore bounded by the weaker of the Evidence-appraisal window and the result/action-applicability window.

Privacy Considerations The actor, on-behalf-of party, trace identifiers, action, mandate, outcome, platform identity, and timing can be identifying or commercially sensitive even when represented only by digests. Stable identifiers can enable correlation across actions and administrative domains. A producer SHOULD disclose only claims needed by the Relying Party, use context-scoped identifiers where global correlation is unnecessary, and place sensitive conversation or audit records in access-controlled detached objects rather than inline submodules. Digesting low-entropy fields does not anonymise them. A party that can guess a supplier, amount, tool name, or mandate text can test the guess against a disclosed digest. Profiles therefore need explicit disclosure, retention, and salt/keyed-commitment decisions. An Auditor's need to reconstruct a record does not imply that every Relying Party should receive the underlying conversation or authority object.

IANA Considerations This document has no IANA actions. (If a future revision requests registered EAT claim labels for the provisional vocabulary, or registers a media type that would identify an AEP carried as a Record CMW or as an entry of a Collection CMW , the corresponding registrations would appear here.)

References Normative References In many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. RFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings. In network protocol exchanges, it is often useful for one end of a communication to know whether the other end is in an intended operating state. This document provides an architectural overview of the entities involved that make such tests possible through the process of generating, conveying, and evaluating evidentiary Claims. It provides a model that is neutral toward processor architectures, the content of Claims, and protocols. An Entity Attestation Token (EAT) provides an attested claims set that describes the state and characteristics of an entity, a device such as a smartphone, an Internet of Things (IoT) device, network equipment, or such. This claims set is used by a relying party, server, or service to determine the type and degree of trust placed in the entity. An EAT is either a CBOR Web Token (CWT) or a JSON Web Token (JWT) with attestation-oriented claims. The conceptual messages introduced by the Remote ATtestation procedureS (RATS) architecture (RFC 9334) are protocol-agnostic data units that are conveyed between RATS roles during RATS interactions. Conceptual messages describe the meaning and function of such data units within RATS data flows without specifying a wire format, encoding, transport mechanism, or processing details. The initial set of conceptual messages is defined in Section 8 of RFC 9334 and includes Evidence, Attestation Results, Endorsements, Reference Values, and Appraisal Policies. This document introduces the Conceptual Message Wrapper (CMW) that provides a common structure to encapsulate these messages. It defines a dedicated Concise Binary Object Representation (CBOR) tag, corresponding JSON Web Token (JWT) and CBOR Web Token (CWT) claims, and an X.509 extension. Together, these mechanisms allow CMWs to be used in CBOR-based protocols, web APIs using JWTs and CWTs, and PKIX artifacts such as X.509 certificates. Additionally, this document defines media types and CoAP Content-Formats that may be used to identify CMWs when transported over protocols such as HTTP, MIME, and CoAP. The goal is to improve the interoperability and flexibility of remote attestation protocols. Introducing a shared message format such as CMW enables consistent support for different attestation message types, enables the evolution of message serialization formats without breaking compatibility, and avoids the need to redefine how messages are handled within each protocol. Informative References Cisco Systems Fraunhofer SIT MIT Linaro Intel This document defines reusable Attestation Result information elements. When these elements are offered to Relying Parties as Evidence, different aspects of Attester trustworthiness can be evaluated. Additionally, where the Relying Party is interfacing with a heterogeneous mix of Attesting Environment and Verifier types, consistent policies can be applied to subsequent information exchange between each Attester and the Relying Party. This document also defines two serialisations of the proposed information model, utilising CBOR and JSON. Linaro Cisco Arm Limited Fraunhofer SIT This document defines the EAT Attestation Result (EAR) message format. EAR is used by a verifier to encode the result of the appraisal over an attester's evidence. It embeds an AR4SI's "trustworthiness vector" to present a normalized view of the evaluation results, thus easing the task of defining and computing authorization policies by relying parties. Alongside the trustworthiness vector, EAR provides contextual information bound to the appraisal process. This allows a relying party (or an auditor) to reconstruct the frame of reference in which the trustworthiness vector was originally computed. EAR supports simple devices with one attester as well as composite devices that are made of multiple attesters, allowing the state of each attester to be separately examined. EAR can also accommodate registered and unregistered extensions. It can be serialized and protected using either CWT or JWT. Fraunhofer SIT Linaro arm Independent Huawei Technologies Remote Attestation Procedures (RATS) enable Relying Parties to assess the trustworthiness of a remote Attester and therefore to decide whether or not to engage in secure interactions with it. Evidence about trustworthiness can be rather complex and it is deemed unrealistic that every Relying Party is capable of the appraisal of Evidence. Therefore that burden is typically offloaded to a Verifier. In order to conduct Evidence appraisal, a Verifier requires not only fresh Evidence from an Attester, but also trusted Endorsements and Reference Values from Endorsers and Reference Value Providers, such as manufacturers, distributors, or device owners. This document specifies the information elements for representing Endorsements and Reference Values in CBOR format. Arm Ltd Huawei Technologies France S.A.S.U. Huawei Technologies France S.A.S.U. Fraunhofer SIT IETF RATS Architecture, defines the key role of a Verifier. In a complex system, this role needs to be performed by multiple Verfiers coordinating together to assess the full trustworthiness of an Attester. This document focuses on various topological patterns for a multiple Verifier system. It only covers the architectural aspects introduced by the Multi Verifier concept, which is neutral with regard to specific wire formats, encoding, transport mechanisms, or processing details.

Acknowledgements Thanks to the Veraison community for the discussion that prompted this sketch.