Code change:
Here's a first attempt to combine terminology sections, and trust model. Includes new terms Endorser and Appraisal Policy per recent discussion. Signed-off-by: Dave Thaler
Done
Done. (But if you have feedback on a sentence like this in the future, please attach the comment directly to the code line under the "Files changed" tab, to make it easy to find which phrase you're referring to.)
Done
Updated. How about now?
I would like to discuss the possibility of combining the terms "Endorsement" and "Attestation Result". Just like we have an Appraisal Policy for a verifier and an Appraisal Policy for a relying party, some might view an Attestation Result as an Endorsement for use by the relying party. I'm ok either way, but wanted to discuss this in our next call to see if others think it would help or confuse things.
I still believe my original definition of Attestation is good, I haven't seen any comments here about what the problem was. For comparison, URL says it's "The process of validating the integrity of a computing device such as a server needed for trusted computing.". I'm also ok with that definition.
I’m OK with that wording for introducing the concept. It may break down if the terminology for ‘device’ and ‘trusted computing’ become overly specified / specific.
The word 'health' is generally being used where other words such as 'trustworthiness', or 'state' could be used. I'm concerned that 'health' might not easily be synonymous with 'trust'. It also seems to bias the architecture toward NEA (RFC5209) which IMO does not define attestation.

Related discussion:
text: 2. <ins> The document defines the term "Remote Attestation" as follows: A process by which one entity (the "Attester") provides evidence about its identity and state to another remote entity (the "Relying Party"), which then assesses the Attester's trustworthiness for the Relying Party's own purposes. This document then uses the following terms: Appraisal Policy for Evidence: A set of rules that direct how a verifier evaluates the validity of information about an Attester. Compare /security policy/ in [RFC4949]. Appraisal Policy for Attestation Result: A set of rules that direct how a Relying Party evaluates the validity of information about an Attester.  Compare /security policy/ in [RFC4949]. Attestation Result: The evaluation results generated by a Verifier, typically including information about an Attester, where the Verifier vouches for the validity of the results. Attester: An entity whose attributes must be evaluated in order to determine whether the entity is considered trustworthy, such as when deciding whether the entity is authorized to perform some operation. Endorsement: A secure statement that some entity (typically a manufacturer) vouches for the integrity of an Attester's signing capability. Endorser: An entity that creates Endorsements that can be used to help evaluate trustworthiness of Attesters. Evidence: A set of information about an Attester that is to be evaluated by a Verifier. Relying Party: An entity that depends on the validity of information about another entity, typically for purposes of authorization.  Compare /relying party/ in [RFC4949]. Relying Party Owner: An entity, such as an administrator, that is authorized to configure Appraisal Policy for Attestation Results in a Relying Party. Verifier: An entity that evaluates the validity of Evidence about an Attester. Verifier Owner: An entity, such as an administrator, that is authorized to configure Appraisal Policy for Evidence in a Verifier. [EDITORIAL NOTE] The term Attestation and Remote Attestation are not defined in this document, at this time.  This document will include pointers to industry uses of the terms, in an attempt to gain consensus around the term, and be consistent with the charter text defining this term. </ins> 3. 4. <ins> dataflow depicts the data that flows between different roles, independent of protocol or use case. An Attester creates Evidence that is conveyed to a Verifier. The Verifier uses the Evidence, and any Endorsements from Endorsers, by applying an Evidence Appraisal Policy to assess the trustworthiness of the Attester, and generates Attestation Results for use by Relying Parties.  The Evidence Appraisal Policy might be obtained from an Endorser along with the Endorsements, or might be obtained via some other mechanism such as being configured in the Verifier by an administrator. The Relying Party uses Attestation Results by applying its own Appraisal Policy to make application-specific decisions such as authorization decisions.  The Attestation Result Appraisal Policy might, for example, be configured in the Relying Party by an administrator. </ins> 5. 6. <ins> An Attester consists of at least one Attesting Environment and Attested Environment.  In some implementations, the Attesting and Attested Environments might be combined.  Other implementations might have multiple Attesting and Attested Environments. </ins> 7. <ins> The scope of this document is scenarios for which a Relying Party trusts a Verifier that can evaluate the trustworthiness of information about an Attester.  Such trust might come by the Relying Party trusting the Verifier (or its public key) directly, or might come by trusting an entity (e.g., a Certificate Authority) that is in the Verifier's certificate chain.  The Relying Party might implicitly trust a Verifier (such as in the Verifying Relying Party combination).  Or, for a stronger level of security, the Relying Party might require that the Verifier itself provide information about itself that the Relying Party can use to evaluate the trustworthiness of the Verifier before accepting its Attestation Results. In solutions following the background-check model, the Attester is assumed to trust the Verifier (again, whether directly or indirectly via a Certificate Authority that it trusts), since the Attester relies on an Attestation Result it obtains from the Verifier, in order to access resources. The Verifier trusts (or more specifically, the Verifier's security policy is written in a way that configures the Verifier to trust) a manufacturer, or the manufacturer's hardware, so as to be able to evaluate the trustworthiness of that manufacturer's devices.  In solutions with weaker security, a Verifier might be configured to implicitly trust firmware or even software (e.g., a hypervisor). That is, it might evaluate the trustworthiness of an application component, or operating system component or service, under the assumption that information provided about it by the lower-layer hypervisor or firmware is true.  A stronger level of security comes when information can be vouched for by hardware or by ROM code, especially if such hardware is physically resistant to hardware tampering.  The component that is implicitly trusted is often referred to as a Root of Trust. </ins> 8. 9. <ins> 10. </ins> The conveyance of Evidence and the resulting Attestation Results reveal a great deal of information about the internal state of a device.  In many cases, the whole point of the Attestation process is