Draft: draft-ietf-rats-architecture

Commentary: 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 do n'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 ] [ 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 .
Paragraph (version A):
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
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.
Paragraph (version B):
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
opaque data.
Paragraph (version B):
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.
Paragraph (version A):
The resource access protocol between the Attester and Relying Party
includes Evidence rather than an Attestation Result, but that
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.
Paragraph (version B):
The resource access protocol between the Attester and Relying Party
includes Evidence rather than an Attestation Result, but that
Evidence is not processed by the Relying Party.
Paragraph (version B):
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.