Change:
might, for example, be configured in the Relying Party by an administrator. <ins> 4.1. A Composite Attester is an entity composed of multiple sub-entities such that its trustworthiness has to be determined by evaluating all these sub-entities.  Each sub-entity has at least one Attesting Environment collecting the claims from at least one Target Environment, then this sub-entity generates Evidence about its trustworthiness.  Therefore each sub-entity can be called an Attester.  Among these Attesters, there may be only some, which can be called Lead Attesters, that have the communication functionality with the Verifier.  Other Attesters don't have this ability, but they are connected to the Lead Attesters via internal links or network connections, and they are evaluated via the Lead Attester's help. For example, a carrier-grade router is a composite device consisting of a chassis and multiple slots.  The trustworthiness of the router depends on all its slots' trustworthiness.  Each slot has an Attesting Environment such as a TPM or TEE collecting the claims of its boot process, then it generates Evidence from the claims to prove its trustworthiness.  Among these slots, only a main slot can communicate with the Verifier while other slots cannot.  But other slots can communicate with the main slot by the links between them inside the router.  So the main slot collects the Evidence of other slots, produces the final Evidence of the whole router and conveys the final Evidence to the Verifier.  Therefore the router is a Composite Attester, each slot is an Attester and the main slot is the Lead Attester. Another example is a multi-chassis router which is composed of multiple single carrier-grade routers.  The multi-chassis router provides higher throughput by interconnecting multiple routers and simpler management by being logically treated as one router.  Among these routers, there is only one main router that connects to the Verifier.  Other routers are only connected to the main router by the network cables, and therefore they are managed and verified via this main router.  So, in this case, the multi-chassis router is the Composite Attester, each router is an Attester and the main router is the Lead Attester. composite depicts the data that flows between the Composite Attester and Verifier for the remote attestation. In the Composite Attester, each Attester generates its own Evidence by its Attesting Environments collecting the claims from its Target Environments.  The Lead Attester collects the Evidence of all other Attesters and then generates the Evidence of the whole Composite Attester. Inside the Lead Attester, there may be an optional Verifying Environment.  The Verifying Environment can verify the collected Evidence of other Attesters to evaluate their trustworthiness. Therefore, there are two situations when the Lead Attester generates the final Evidence. One situation is that the Lead Attester has no Verifying Environment. In this situation, the Lead Attester just collects the Evidence of other Attesters but doesn't verify them.  It may just string all these Evidence into a whole one, or it may reorganize these Evidence with a new structure and sign this final Evidence.  Then it conveys the final Evidence to the Verifier and the Verifier evaluates the Composite Attester's, including the Lead Attester's and other Attesters', trustworthiness. The other situation is that the Lead Attester has a Verifying Environment.  After collecting the Evidence of other Attesters, the Lead Attester verifies these Evidence by using the Endorsements and Appraisal Policies, which are got from the Verifier or some reliable parties, for evaluating these Attesters' trustworthiness.  Then the Lead Attester makes the verification results as claims which are the input to the final Evidence of the whole Composite Attester.  Then the Lead Attester conveys the final Attestation Evidence to the Verifier on behalf of the Composite Attester.  Before receiving the Endorsements and Appraisal Policies for other Attesters, to increase the security, the Lead Attester may first generate Evidence about its trustworthiness and convey this Evidence to the Verifier for evaluating. </ins> 5. There are multiple possible models for communication between an

Discussion:
This is a preliminary description of the remote attestation of composite attester
will introduce some new terms that can be used to explain this better.
There was confusion as to whether or not ‘leader’ and ‘subordinate’ were synonyms for ‘attesting environment’ and ‘attested environment’ or whether they were synonymous with ‘component’ and ‘sub-component’ (aka module and sub-module --> “submods”).
Ned suggests that the term Measure be added to connect the Attested Environment and Attesting Environment. There may be multiple Attested Environments that can measured by a single Attesting Environment (such as when there is a TPM, SGX, DICE).
There may be multiple Attested Environments that can measured by multiple Attesting Environment (DICE == TCG standard for generating layered claim sets).
Discussion about combining the two environments together leads to comments about having measuring code in ROM, and then this leads to discussion about having a Manufacturing Certificate. Issuing a manufacturing certificate is an operational way to keep the attesting environment separate from the attested environment.
"attesting" and "attested" are too alliteratively similar. "measure" is the process. "measuring environment"... discussed. "surveyor" is suggested. MW: implies that they are actively "going out" and doing it.
URL
Pretty sure "measurement" is taken to mean hashing some bytes of memory, a file or such for later comparison to expected values. Lots of claims are not of that nature, so I'm not so much in favor of this term.
I find that "Claim" is also widely mentioned/used but not yet defined in Terminology. This term may also need to be considered to be introduced in Terminology. Usage examples: The “attester” produces a set of “claims” about a “target”. The claims are known as “attestation evidence”. (From Laurence's email) Claim: A statement about the construction, composition, validation or behavior of an Entity that affects trustworthiness. Evidence, Reference Values and Attestation Results are expressions that consists of one or more Claims. (From draft-birkholz-rats-architecture) The evidence is typically a set of claims about its software and hardware platform.

(From the abstract of the current arch draft)
Laurence Lundblade wrote: I believe that the term measurement was used rather than the term "hash"(ing), because not all evidence is in the form of a hash.
The term "claim" is somewhat inherited from JWT/CWT, but agree we need a definition here in RATS. Seems more like "claim: is an individual chunk of data about a target; the attestation evidence and attestation result is primarily made up of claims". Still don't like the term measurement. I don't think a SW Version, HW Version a GPS location, a public key, most of COSWID and such are measurements.
+1 “Claim” inherits baggage from elsewhere. There has been several threads about alternatives (e.g. “assertions”) as well. Given people are OK with its use, terminology section should include a definition. Arch also determined it is correct to use “assertion” generically to describe interactions between Roles. Claim has more specific context but it needs a definition so we can be on the same page about what that context is.
TCG use of the term ‘measure’ isn’t limited to hashing. The RIV draft / architecture / use case is heavily focused on inspecting SW/FW modules using hashing so it can come across as though that is the only interpretation. The important relevance is that ‘measuring’ is something that happens before ‘attesting’ (signing). Measuring could happen by an environment that is different from the ‘attesting environment’. However, the trust model semantics equate them as being equal, therefore for convenience and simplicity it is OK to avoid introducing another term.
The terms "collect" and "record" are also suggested. --> "record the values of claims"... "audit log" --> "collect the values of claims" HB: Claims are name/value pairs.. but not only this way. Are this way in JWT/CWT, but not in certificates. DT: Certificates are extension ID and and value, why isn't it the same? So, it's the "name" part which is wrong, so maybe it is ID/value pair? We should have a definition of claim, in the generic sense. The semantic meaning may be implied. We can not always find names without colliding, and we can't always invent new names.