Change:
Owner, and/or are programmed into the Relying Party.  This procedure is called the appraisal of Attestation Results. <del> 3.1. The Verifier, when appraising Evidence, or the Relying Party, when appraising Attestation Results, checks the values of some Claims against constraints specified in its appraisal policy.  Examples of such constraints checking include: comparison for equality against a Reference Value, or a check for being in a range bounded by Reference Values, or membership in a set of Reference Values, or a check against values in other Claims. The actual data format and semantics of any Appraisal Policy is implementation specific. 3.2. Reference Values used in appraisal procedures come from a Reference Value Provider and are then used by the appraisal policy. The actual data format and semantics of any Reference Values are specific to Claims and implementations.  This architecture document does not define any general purpose format for Reference Values or general means for comparison. 3.3. </del> <ins> See messages for further discussion of the conceptual messages shown in dataflow.  ## Two Types of Environments of an Attester </ins> As shown in twotypes-env, an Attester consists of at least one Attesting Environment and at least one Target Environment.  In some

Discussion:
This is about the text that describes layered attestation and Figure 3, the one with environments A, B and C. I think the critical point about layered attestation (if I understand it) is that the remote Verifier must evaluate the evidence for target environment B with a positive result as a precondition to evaluating the evidence for C. This critical point isn't mentioned in the text. The other possibility is Attesting Environment A is also the Verifier for the evidence from target environment B. There are two roles in the same box, Attester and Verifier. This seems to be implied by the paragraph after Figure 3. The paragraph that starts "Attesting Environment A... has to ensure the integrity of the boot loader (Target Environment B)". However, figure 3 only shows a remote Verifier. A third possibility is A does ensure integrity of B, but it's not Attestation. It is just typical staged boot that is being described. It is not layered attestation. I think we should distinguish staged boot from local Attestation Verification. It doesn't seem right to claim that all staged boot is local Attestation Verification and thus RATS applies to all staged boot. In the cases where A does locally ensure the integrity of B either via staged boot or a local Verifier, then the remote verifier can actually trust the evidence about C without first evaluating the evidence from B. Or, all three of the above could be intended. There is nothing wrong with implementations that do any of these or combinations of them. I think the text should decide which of the three it is going after here and be clear about them.
Agreedtrust relations between different layers should be clarified. It seems that the concept of trust chain could be used to describe this trust and attestation relations in different layers.
I think the intent of the text is the first approach, i.e., the one for which Laurence says:
In the first approach, if A is the BIOS (root of trust ?), and B is the bootloader, I'm not sure if bootloader has the ability to communicate with remote verifier via network or other methods.
Typically the evidence is provided to some service or application running in or on top of the kernel, that can send the evidence to the verifier or relying party.
I understand and agree with your opinion. But that means the fiuge 3 may be inaccurate.

The arrow mark orignated from B and pointed to verifier may mislead readers. And the integrity and confidentiality of evidence also need to be protected carefully. : )
Rather than adjust the diagram to show conveyance of bootloader has no network stack, instead, we shall add note to the effect that the diagram is a conceptual flow of how the trust is conveyed, not how the data is "physically" transmitted.
See PR for EAT claims for layered attestation. URL This PR supports types of layered attestation: 1) the Verifier decided on the trust and 2) the Device / root / lower layer attesting environment decides.
NAME to validate that this was done.
Maybe closed in URL
Seems to have found consensus for WGLC