Change:
hardware or software environments that can be used to implement an Attesting Environment, for example: Trusted Execution Environments (TEEs), embedded Secure Elements (eSEs), Trusted Platform Modules <del> (TPMs), or BIOS firmware.  An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments. </del> <ins> (TPMs), or BIOS firmware. An arbitrary execution environment may not, by default, be capable of claims collection for a given Target Environment.  Execution environments that are designed specifically to be capable of claims collection are referred to in this document as Attesting Environments.  For example, a TPM doesn't actively collect claims itself, it instead requires another component to feed various values to the TPM.  Thus, an Attesting Environment in such a case would be the combination of the TPM together with whatever component is feeding it the measurements. </ins> 3.4.

Discussion:
Also improve wording of watchdog use case's discussion of TPMs. Signed-off-by: Dave Thaler
This section, as put, is kind of a big leap, no? I think the important part of this next level, is the introduction of a hardware root of trust like a TPM to eliminate the need to trust the device’s operating system software in reporting attestation results.
NAME How about "For strongest security,...." to avoid confusion with high level OS.
This also already fixed by existing text .
If a TPM is the Attesting environment, then in the case where this system had a TPM, this statement would not be true, no? In other words, shouldn’t this example be restricted to attestation without a TPM? (I think you can say something like “hardware root of trust for verification” or something if we should avoid naming technologies) In contrast, I think in a TPM system, the firmware initializes the Attesting Environment, the TPM is the attesting environment, and the same attesting environment is used by all layers.
For context, Guy's comment was on the first sentence in this paragraph: My understanding is that a TPM requires another entity to feed it measurements which the TPM measures, the TPM doesn't actively collect claims itself. Thus to me, the TPM is not the Attesting Environment. The Attesting Environment is the combination of the TPM + whatever is feeding it the measurements. Viewed that way, I believe the text is true as written.
Yes. We need text that captures that prominently and then also in that text start with "the composite of TPM &amp; root of trust for measurement" forms an Attesting Environment instead of "he TPM is not the Attesting Environment". Starting with the latter seems to produce reflexive and unnecessary knee-jerk reactions that we can also easily resolve, finally. Does that sound like a feasible approach?
Yes I like that.
section: ## Two Types of Environments of an Attester now includes text: ~ What else do you want to say? Why not? What’s the message you want to convey here? What would disqualify an execution environment from being capable of claims collection? How would you know if an Execution Environment is an Attesting Environment?
What does it mean to be capable of claims collection?