Change:
In this scenario, the trust model described in trustmodel can also be applied to an inside Verifier. <del> 3.6. </del> <ins> 3.3. </ins> An entity can take on multiple RATS roles (e.g., Attester, Verifier, Relying Party, etc.) at the same time.  Multiple entities can

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