Change:
related to There is something foundational I am not following about this section. The interactions described here do not conform behaviors described in the terminology in Section 4 or the high-level reference architecture of Figure 1. I'm not sure how to reconcile this discrepancy. Minimally, these discrepancies in Figure 5 and 6 are not consistent with the roles defined in Section 4. [restated here but same feedback on -13] -- Figure 5. Shows the Attester consuming Attestation Results -- Figure 5. Shows the Attester producing Attestation Results -- Figure 6: Shows Relying party consuming Evidence -- Figure 6: Shows the Relying Party producing/passing Evidence The introductory text states that "[t]he discussion that follows is for illustrative purposes only and does not constrain the interactions between RATS roles to the presented patterns." I don't follow what is being illustrated in the context of RATS. What is the takeaway for implementers or designers from this section? [Author's response] URL [Roman's response on -15] The above github comment addressed a few issues from the -13 review, but not this one.
Reply by email: "The Attester does not consume the Attestation Result, but might cache it. "
The text explains the intent correctly regardless of how the lines are drawn. I can convince myself that it is correct draw the line through the box (or not). The important clarifying point should be that the end-to-end message flow as described in the conceptual architecture is preserved through the various topology models that may exist. Second point is there can be a large variety of topology models (aka hybrids) but none of these hybrids changes the expectation of end-to-end message flow.
also helps.

Discussion:
In this model, an Attester conveys Evidence to a Verifier, which compares the Evidence against its appraisal policy.  The Verifier then gives back an Attestation Result which the Attester treats as <del> opaque data.  The Attester does not consume the Attestation Result, but might cache it.  The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy. </del> <ins> opaque data. The Attester does not consume the Attestation Result, but might cache it.  The Attester can then present the Attestation Result (and possibly additional Claims) to a Relying Party, which then compares this information against its own appraisal policy.  The Attester may also present the same Attestation Result to other Relying Parties. </ins> Three ways in which the process may fail include:

The resource access protocol between the Attester and Relying Party includes Evidence rather than an Attestation Result, but that <del> Evidence is not processed by the Relying Party.  Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. </del> <ins> Evidence is not processed by the Relying Party. Since the Evidence is merely forwarded on to a trusted Verifier, any serialization format can be used for Evidence because the Relying Party does not need a parser for it.  The only requirement is that the Evidence can be _encapsulated in_ the format required by the resource access protocol between the Attester and Relying Party. </ins> However, like in the Passport model, an Attestation Result is still consumed by the Relying Party.  Code footprint and attack surface