Change:
In all diagrams, valueGeneration should be replaced by produceClaims. The return type "claims" also indicates that claims are produced(/generated) somehow. Generated claims, e.g. could be Measured Boot data (TPM PCRs + the boot event log). BTW: I don't see a passage in the text that describes valueGeneration. See also .
Diagrams should be as close to UML as possible to improve understanding. That is (this applies to all diagrams): Actions should be verbs, not nouns ("generateValues" instead of "valueGeneration"). Returns of data should also be just arrows with data elements, i.e. nouns ("evidence --->" instead of "returnEvidence --->". Uni-Directional Remote Attestation: Handle Distributor should be at the top as an actor. It should be indicated that the "claimsDelta" value generation is a loop.
The text must be reworked. All above, the sequence in the diagram should be described entirely. This may also apply to the other models.
This should also be described in the text.

Discussion:
Streaming Remote Attestation Each section starts with a sequence diagram illustrating the <del> interactions between Attester and Verifier.  While the interaction models presented focus on the conveyance of Evidence, the intention </del> <ins> interactions between Attester and Verifier.  While the presented interaction models focus on the conveyance of Evidence, the intention </ins> of this document is in support of future work that applies the presented models to the conveyance of other Conceptual Messages, namely Attestation Results, Endorsements, Reference Values, or Appraisal Policies. All interaction models have a strong focus on the use of a handle to <del> incorporate a type of proof of freshness.  The ways these handles are processed is the most prominent difference between the three interaction models. </del> <ins> incorporate a type of proof of freshness and to prevent replay attacks.  The way these handles are processed is the most prominent difference between the three interaction models. </ins> 8.1. <del> This Challenge/Response Remote Attestation procedure is initiated by the Verifier, by sending a remote attestation request to the Attester.  A request includes a Handle, a list of Authentication Secret IDs, and a Claim Selection. </del> <ins> The Attester boots up and thereby produces claims about its boot state and its operational state.  Event Logs accompany the produced claims by providing an event trail of security-critical events of a system.  Claims are produced by all attesting Environments of an Attester system. The Challenge/Response remote attestation procedure is initiated by the Verifier by sending a remote attestation request to the Attester. A request includes a Handle, a list of Authentication Secret IDs, and a Claim Selection. </ins> In the Challenge/Response model, the handle is composed of qualifying <del> data in the form of a cryptographically strongly randomly generated, and therefore unpredictable, nonce.  The Verifier-generated nonce is intended to guarantee Evidence freshness. </del> <ins> data in the form of a practically infeasible to guess nonce, such as a cryptographically strong random number.  The Verifier-generated nonce is intended to guarantee Evidence freshness and to prevent replay attacks. </ins> The list of Authentication Secret IDs selects the attestation keys with which the Attester is requested to sign the Attestation Evidence.  Each selected key is uniquely associated with an Attesting Environment of the Attester.  As a result, a single Authentication Secret ID identifies a single Attesting Environment. <del> Analogously, a particular set of Evidence originating from a particular Attesting Environments in a composite device can be </del> <ins> Correspondingly, a particular set of Evidence originating from a particular Attesting Environment in a composite device can be </ins> requested via multiple Authentication Secret IDs.  Methods to acquire Authentication Secret IDs or mappings between Attesting Environments to Authentication Secret IDs are out-of-scope of this document. <del> The Claim Selection narrows down the set of Claims collected and used to create Evidence to those that the Verifier requires.  If the Claim Selection is omitted, then by default all Claims that are known and available on the Attester MUST be used to create corresponding Evidence.  For example when performing a boot integrity evaluation, a Verifier may only be requesting a particular subset of claims about the Attester, such as Evidence about BIOS and firmware the Attester booted up, and not include information about all currently running software. While it is crucial that Claims, the Handle, as well as the Attester </del> <ins> The Attester collects Claims based on the Claim Selection.  With the Claim Selection the Verifier defines the set of Claims it requires. Correspondingly, collected Claims can be a subset of the produced Claims.  This could be all available Claims, depending on the Claim Selection.  If the Claim Selection is omitted, then by default all Claims that are known and available on the Attester MUST be used to create corresponding Evidence.  For example, when performing a boot integrity evaluation, a Verifier may only be requesting a particular subset of claims about the Attester, such as Evidence about BIOS/UEFI and firmware that the Attester booted up, and not include information about all currently running software. With the Handle, the Authentication Secret IDs, and the collected Claims, the Attester produces signed Evidence.  That is, it digitally signs the Handle and the collected Claims with a cryptographic secret identified by the Authentication Secret ID.  This is done once per Attesting Environment which is identified by the particular Authentication Secret ID.  The Attester communicates the signed Evidence as well as all accompanying Event Logs back to the Verifier. While it is crucial that Claims, the Handle, and the Attester </ins> Identity information MUST be cryptographically bound to the signature <del> of Evidence, they may be presented in an encrypted form. Cryptographic blinding MAY be used at this point.  For further reference see section security-and-privacy-considerations. </del> <ins> of Evidence, they MAY be presented obfuscated, encrypted, or cryptographically blinded.  For further reference see section security-and-privacy-considerations. </ins> <del> As soon as the Verifier receives signed Evidence, it validates the signature, the Attester Identity, as well as the Nonce, and appraises </del> <ins> As soon as the Verifier receives the signed Evidence and Event Logs, it appraises the Evidence.  For this purpose, it validates the signature, the Attester Identity, and the Handle, and then appraises </ins> the Claims.  Appraisal procedures are application-specific and can be conducted via comparison of the Claims with corresponding Reference Claims, such as Reference Integrity Measurements.  The final output of the Verifier are Attestation Results.  Attestation Results <del> constitute new Claims Sets about an Attester's properties and characteristics that enables Relying Parties, for example, to assess an Attester's trustworthiness. </del> <ins> constitute new Claim Sets about the properties and characteristics of an Attester, which enables Relying Parties, for example, to assess an Attester's trustworthiness. </ins> 8.2. <ins> TODO: Describe Deltas </ins> Uni-Directional Remote Attestation procedures can be initiated both by the Attester and by the Verifier.  Initiation by the Attester can result in unsolicited pushes of Evidence to the Verifier.  Initiation by the Verifier always results in solicited pushes to the Verifier. The Uni-Directional model uses the same information elements as the Challenge/Response model.  In the sequence diagram above, the Attester initiates the conveyance of Evidence (comparable with a RESTful POST operation or the emission of a beacon).  While a request <del> of evidence from the Verifier would result in a sequence diagram more </del> <ins> of Evidence from the Verifier would result in a sequence diagram more </ins> similar to the Challenge/Response model (comparable with a RESTful <del> GET operation), the specific manner how handles are created and used always remains as the distinguishing quality of this model.  In the Uni-Directional model, handles are composed of trustable signed timestamps as shown in I-D.birkholz-rats-tuda, potentially including other qualifying data.  The handles are created by an external 3rd entity - the Handle Distributor - that includes a trustworthy source of time and takes on the role of a Time Stamping Authority (TSA, as initially defined in RFC3161).  Timstamps created from local clocks (absolute clocks using a global timescale, as well as relative clocks, such as tick-counters) of Attesters and Verifiers MUST be cryptographically bound to fresh Handles received from the Handle Distributor.  This binding provides a proof of synchronization that MUST be included in every evidence created.  Correspondingly, evidence created for conveyance via this model provides a proof that it was fresh at a certain point in time.  Effectively, this allows for series of evidence to be pushed to multiple Verifiers, simultaniously.  Methods to detect excessive time drift that would mandate a fresh Handle to be received by the Handle Distributor, as well as timing of handle distribution are out-of-scope of this document. </del> <ins> GET operation).  The specific manner how Handles are created and used always remains as the distinguishing quality of this model. In the Uni-Directional model, handles are composed of cryptographically signed trusted timestamps as shown in I-D.birkholz- rats-tuda, potentially including other qualifying data.  The Handles are created by an external 3rd entity - the Handle Distributor - which includes a trustworthy source of time, and takes on the role of a Time Stamping Authority (TSA, as initially defined in RFC3161). Timestamps created from local clocks (absolute clocks using a global timescale, as well as relative clocks, such as tick-counters) of Attesters and Verifiers MUST be cryptographically bound to fresh Handles received from the Handle Distributor.  This binding provides a proof of synchronization that MUST be included in all produced Evidence.  Correspondingly, conveyed Evidence in this model provides a proof that it was fresh at a certain point in time. While periodically pushing Evidence to the Verifier, the Attester only needs to generate and convey evidence generated from Claim values that have changed and new Event Logs entries since the previous conveyance.  This updates reflecting the differences are called "delta" in the sequence diagram above. Effectively, the Uni-Directional model allows for a series of Evidence to be pushed to multiple Verifiers simultaneously.  Methods to detect excessive time drift that would mandate a fresh Handle to be received by the Handle Distributor as well as timing of Handle distribution are out-of-scope of this document. </ins> 8.3. Streaming Remote Attestation procedures require the setup of subscription state.  Setting up subscription state between a Verifier <del> and an Attester is conducted via a subscribe operation.  This subscribe operation is used to convey the handles required for Evidence generation.  Effectively, this allows for series of evidence to be pushed to a Verifier similar to the Uni-Directional model. While a Handle Distributor is not required in this model, it is also limited to bi-lateral subscription relationships, in which each Verifier has to create and provide its individual handle.  Handles provided by a specific subscribing Verifier MUST be used in Evidence generation for that specific Verifier.  The Streaming model uses the same information elements as the Challenge/Response and the Uni- </del> <ins> and an Attester is conducted via a subscribe operation.  The subscribe operation is used to convey required Handles for producing Evidence.  Effectively, this allows for a series of Evidence to be pushed to a Verifier, similar to the Uni-Directional model.  While a Handle Distributor is not required in this model, it is also limited to bi-lateral subscription relationships in which each Verifier has to create and provide its individual Handle.  Handles provided by a specific subscribing Verifier MUST be used in Evidence generation for that specific Verifier.  The Streaming model uses the same information elements as the Challenge/Response and the Uni- </ins> Directional model.  Methods to detect excessive time drift that would mandate a refreshed Handle to be conveyed via another subscribe operation are out-of-scope of this document.

Confidentiality of exchanged attestation information may be desirable.  This requirement usually is present when communication takes place over insecure channels, such as the public Internet.  In <del> such cases, TLS may be uses as a suitable communication protocol that preserves confidentiality.  In private networks, such as carrier management networks, it must be evaluated whether or not the transport medium is considered confidential. </del> <ins> such cases, TLS may be used as a suitable communication protocol which provides confidentiality protection.  In private networks, such as carrier management networks, it must be evaluated whether or not the transport medium is considered confidential. </ins> 9.2. <del> In particular use cases mutual authentication may be desirable in </del> <ins> In particular use cases, mutual authentication may be desirable in </ins> such a way that a Verifier also needs to prove its identity to the Attester, instead of only the Attester proving its identity to the Verifier.