Change:
Add time considerations into an appendix and reference it from the freshness section.
For readability, I have removed extraneous event times and only kept the ones used in the discussion after at least one diagram. My goal is to keep the discussion easy to understand and not include excess details or complexity that could be left to other docs.
NAME will look into additions around purple items. NAME to work on moving table to section 9 (freshness)

Discussion:
have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. <ins> A more detailed discussion with examples appears in time- considerations. </ins> 10. The conveyance of Evidence and the resulting Attestation Results

Special thanks go to Joerg Borchert, Nancy Cam-Winget, Jessica Fitzgerald-McKay, Thomas Fossati, Diego Lopez, Laurence Lundblade, Wei Pan, Paul Rowe, Hannes Tschofenig, Frank Xia, and David Wooten. <ins> 14. The table below defines a number of relevant events, with an ID that is used in subsequent diagrams.  The times of said events might be defined in terms of an absolute clock time such as Coordinated Universal Time, or might be defined relative to some other timestamp or timeticks counter. We now walk through a number of hypothetical examples of how a solution might be built.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. 14.1. 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 depends on using a secure clock synchronization mechanism. 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. 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. 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)". 14.2. The following example illustrates a hypothetical Passport Model 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 is fresh at time(RG) by verifying that "time(RG) - time(NS) < 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 correctly provide the delta time(EG)-time(VG), then it can determine recency by checking "time(RG)-time(NS) + time(EG)-time(VG) < Threshold". 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 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. 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 validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(NS') < time(RX)-time(RG)". 14.3. The following example illustrates a hypothetical Background-Check Model solution that uses timestamps and requires roughly synchronized clocks between the Attester, Verifier, and Relying Party. The time considerations in this example are equivalent to those discussed under Example 1 above. 14.4. The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any clocks are synchronized.  In this example solution, a nonce is generated by a Verifier at the request of a Relying Party, when the Relying Party needs to send one to an Attester. The Verifier can check whether the Evidence is fresh, and whether a claim value is recent, the same as in Example 2 above. However, unlike in Example 2, the Relying Party can use the Nonce to determine whether the Attestation Result is fresh, by verifying that "time(OP) - time(NR) < Threshold". 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 validity lifetime in terms of time(RX)-time(RG), then the Relying Party can check "time(OP) - time(ER) < time(RX)-time(RG)". </ins>