Draft: draft-ietf-rats-architecture

Commentary: This pull request puts _ X on all time points . Please review for accuracy . 
 I am neutral / okay with consistently adding suffixes to every event label
Paragraph (version B):
All times are relative to the local clocks, indicated by an "a"
(Attester), "v" (Verifier), or "r" (Relying Party) suffix.
Paragraph (version B):
How and if clocks are synchronized depends upon the model.
Paragraph (version A):
The Verifier can check whether the Evidence is fresh when appraising
it at time(RG) by checking "time(RG) - time(EG) < Threshold", where
the Verifier's threshold is large enough to account for the maximum
permitted clock skew between the Verifier and the Attester.
Paragraph (version A):
If time(VG) is also included in the Evidence along with the claim
value generated at that time, and the Verifier decides that it can
trust the time(VG) value, the Verifier can also determine whether the
claim value is recent by checking "time(RG) - time(VG) < Threshold",
again where the threshold is large enough to account for the maximum
permitted clock skew between the Verifier and the Attester.
Paragraph (version A):
The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA) by checking "time(RA) - time(RG) <
Threshold", where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying
Party and the Verifier.  The result might then be used for some time
(e.g., throughout the lifetime of a connection established at
time(RA)).  The Relying Party must be careful, however, to not allow
continued use beyond the period for which it deems the Attestation
Result to remain fresh enough.  Thus, it might allow use (at
time(OP)) as long as "time(OP) - time(RG) < Threshold".  However, if
the Attestation Result contains an expiry time time(RX) then it could
explicitly check "time(OP) < time(RX)".
Paragraph (version B):
The Verifier can check whether the Evidence is fresh when appraising
it at time(RG_v) by checking "time(RG_v) - time(EG_a) < Threshold",
where the Verifier's threshold is large enough to account for the
maximum permitted clock skew between the Verifier and the Attester.
Paragraph (version B):
If time(VG_a) is also included in the Evidence along with the claim
value generated at that time, and the Verifier decides that it can
trust the time(VG_a) value, the Verifier can also determine whether
the claim value is recent by checking "time(RG_v) - time(VG_a) <
Threshold", again where the threshold is large enough to account for
the maximum permitted clock skew between the Verifier and the
Attester.
Paragraph (version B):
The Relying Party can check whether the Attestation Result is fresh
when appraising it at time(RA_r) by checking "time(RA_r) - time(RG_v)
< Threshold", where the Relying Party's threshold is large enough to
account for the maximum permitted clock skew between the Relying
Party and the Verifier.  The result might then be used for some time
(e.g., throughout the lifetime of a connection established at
time(RA_r)).  The Relying Party must be careful, however, to not
allow continued use beyond the period for which it deems the
Attestation Result to remain fresh enough.  Thus, it might allow use
(at time(OP_r)) as long as "time(OP_r) - time(RG_v) < Threshold".
However, if the Attestation Result contains an expiry time time(RX_v)
then it could explicitly check "time(OP_r) < time(RX_v)".
Paragraph (version A):
As a result, the receiver of a conceptual message containing a
timestamp cannot directly compare it to its own clock or timestamps.
Thus we use a suffix (a for Attester, v for verifier, and r for
Relying Party) on the IDs below indicating which clock generated
them, since times from different clocks cannot be compared.  Only the
delta between two events from the sender can be used by the receiver.
Paragraph (version B):
As a result, the receiver of a conceptual message containing a
timestamp cannot directly compare it to its own clock or timestamps.
Thus we use a suffix ("a" for Attester, "v" for Verifier, and "r" for
Relying Party) on the IDs below indicating which clock generated
them, since times from different clocks cannot be compared.  Only the
delta between two events from the sender can be used by the receiver.
Paragraph (version A):
In this example, Evidence generation based on received handles always
uses the current (most recent) handle.  As handles are distributed
over the network, all involved entities receive a fresh handle at
roughly the same time.  The time that represents this event is named
Handle received: time(HR).  Due to distribution over the network,
there is some jitter with respect to time(HR) for each involved
entity.  To compensate for this jitter, there is a small period of
overlap (a specified offset) in which both a current handle and
corresponding former handle are valid in Evidence appraisal:
"validity-duration = time(HR') + offset - time(HR)".  The offset is
typically based on a network's round trip time.  Analogously, the
generation of valid Evidence is only possible, if the age of the
handle used is lower than the validity-duration: "time(HR) - time(EG)
< validity-duration".
Paragraph (version A):
From the point of view of a Verifier, the generation of valid
Evidence is only possible, if the age of the handle used in the
Evidence generation is younger than the duration of the distribution
interval - "(time(HD')-time(HD)) - (time(HR)-time(EG)) < validity-
duration".
Paragraph (version B):
In this example, Evidence generation based on received handles always
uses the current (most recent) handle.  As handles are distributed
over the network, all involved entities receive a fresh handle at
roughly the same time.  Due to distribution over the network, there
is some jitter with respect to the time the Handle is received,
time(HR), for each involved entity.  To compensate for this jitter,
there is a small period of overlap (a specified offset) in which both
a current handle and corresponding former handle are valid in
Evidence appraisal: "validity-duration = time(HR'_v) + offset -
time(HR_v)".  The offset is typically based on a network's round trip
time.  Analogously, the generation of valid Evidence is only
possible, if the age of the handle used is lower than the validity-
duration: "time(HR_v) - time(EG_a) < validity-duration".
Paragraph (version B):
From the point of view of a Verifier, the generation of valid
Evidence is only possible, if the age of the handle used in the
Evidence generation is younger than the duration of the distribution
interval - "(time(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) <
validity-duration".