Original text:
The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which <del> depends on using a secure clock synchronization mechanism. </del>  The Verifier can check whether the Evidence is fresh when appraising it at time(RG) by checking "time(RG) - time(EG) < Threshold", where solution that uses nonces and thus does not require that any clocks are synchronized.  In this example solution, the Verifier can check whether the Evidence <del> is fresh at time(RG) by verifying that "time(RG) - time(NS) < </del>  Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to <del> correctly provide the delta time(EG)-time(VG), then it can determine recency by checking "time(RG)-time(NS) + time(EG)-time(VG) < Threshold". </del>  Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the <del> Attestation Result is fresh by checking "time(OP) - time(NS') + time(RR)-time(EG) < Threshold".  Although the Nonce2 and time(RR)- time(EG) values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. </del>  The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a <del> validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(NS') < time(RX)-time(RG)". </del>  15.3. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that <del> "time(OP) - time(NR) < Threshold". </del>  The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a <del> validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(ER) < time(RX)-time(RG)". </del> 

Reviewer comments:
Per offline discussion between Henk and Dave, trying this annotation to see if it helps Also try combining VG and AA into VC since nothing in doc uses AA, and any example could use either VG or AA, so combining makes any example work for both. Signed-off-by: Dave Thaler

Revised text:
The following example illustrates a hypothetical Passport Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party, which  <ins> depends on using a secure clock synchronization mechanism.  As a result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. </ins> The Verifier can check whether the Evidence is fresh when appraising it at time(RG) by checking "time(RG) - time(EG) < Threshold", where solution that uses nonces and thus does not require that any clocks are synchronized. <ins> 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. </ins> In this example solution, the Verifier can check whether the Evidence  <ins> is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < </ins> Threshold". The Verifier cannot, however, simply rely on a Nonce to determine whether the value of a claim is recent, since the claim value might have been generated long before the nonce was sent by the Verifier. However, if the Verifier decides that the Attester can be trusted to  <ins> correctly provide the delta "time(EG_a)-time(VG_a)", then it can determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < Threshold". </ins> Similarly if, based on an Attestation Result from a Verifier it trusts, the Relying Party decides that the Attester can be trusted to correctly provide time deltas, then it can determine whether the  <ins> Attestation Result is fresh by checking "time(OP_r)-time(NS_r) + time(RR_a)-time(EG_a) < Threshold".  Although the Nonce2 and "time(RR_a)-time(EG_a)" values cannot be inside the Attestation Result, they might be signed by the Attester such that the Attestation Result vouches for the Attester's signing capability. </ins> The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a  <ins> validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". </ins> 15.3. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that  <ins> "time(OP_r)-time(NR_r) < Threshold". </ins> The Relying Party must still be careful, however, to not allow continued use beyond the period for which it deems the Attestation Result to remain valid.  Thus, if the Attestation Result sends a  <ins> validity lifetime in terms of "time(RX_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- time(RG_v)". </ins>