Change:
fix appendix to actually be back matter.
One editorial matter that got introduced somewhere after -15, please make this a proper appendix. It's currently " 16. Appendix A: Time Considerations", that is, Section 16 with word "appendix" in the title. Perhaps this is a rendering issue.

Discussion:
Peter Loscocco contributed critical review feedback as part of the weekly design team meetings that added precision and depth to several sections. <del> 16. freshness discussed various issues and requirements around freshness of evidence, and summarized three approaches that might be used by different solutions to address them.  This appendix provides more details with examples to help illustrate potential approaches, to inform those creating specific solutions. 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 the Coordinated Universal Time timescale, or might be defined relative to some other timestamp or timeticks counter, such as a clock resetting its epoch each time it is powered on. Using the table above, a number of hypothetical examples of how a solution might be built are illustrated below.  This list is not intended to be complete, but is just representative enough to highlight various timing considerations. All times are relative to the local clocks, indicated by an "_a" (Attester), "_v" (Verifier), or "_r" (Relying Party) suffix. Times with an appended Prime (') indicate a second instance of the same event. How and if clocks are synchronized depends upon the model. In the figures below, curly braces indicate containment.  For example, the notation Evidence{foo} indicates that 'foo' is contained in the Evidence and is thus covered by its signature. 16.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.  As a result, the receiver of a conceptual message containing a timestamp can directly compare it to its own clock and timestamps. 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. 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".  The threshold is decided by the Appraisal Policy for Evidence, and again needs to take into account the maximum permitted clock skew between the Verifier and the Attester. The Attester does not consume the Attestation Result, but might cache it. 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)". 16.2. The following example illustrates a hypothetical Passport Model solution that uses nonces instead of timestamps.  Compared to the timestamp-based example, it requires an extra round trip to retrieve a nonce, and requires that the Verifier and Relying Party track state to remember the nonce for some period of time. The advantage is that it does not require that any clocks are synchronized.  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. In this example solution, the Verifier can check whether the Evidence is fresh at "time(RG_v)" by verifying that "time(RG_v)-time(NS_v) < 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_a)-time(VG_a)", then it can determine recency by checking "time(RG_v)-time(NS_v) + time(EG_a)- time(VG_a) < 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_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. 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_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(NS_r) < time(RX_v)- time(RG_v)". 16.3. The example in fig-epochid-passport illustrates a hypothetical Passport Model solution that uses epoch IDs instead of nonces or timestamps. The Epoch ID Distributor broadcasts epoch ID "I" which starts a new epoch "E" for a protocol participant upon reception at "time(IR)". The Attester generates Evidence incorporating epoch ID "I" and conveys it to the Verifier. The Verifier appraises that the received epoch ID "I" is "fresh" according to the definition provided in epochfreshness whereby retries are required in the case of mismatching epoch IDs, and generates an Attestation Result.  The Attestation Result is conveyed to the Attester. After the transmission of epoch ID "I'" a new epoch "E'" is established when "I'" is received by each protocol participant.  The Attester relays the Attestation Result obtained during epoch "E" (associated with epoch ID "I") to the Relying Party using the epoch ID for the current epoch "I'".  If the Relying Party had not yet received "I'", then the Attestation Result would be rejected, but in this example, it is received. In the illustrated scenario, the epoch ID for relaying an Attestation Result to the Relying Party is current, while a previous epoch ID was used to generate Verifier evaluated evidence.  This indicates that at least one epoch transition has occurred, and the Attestation Results may only be as fresh as the previous epoch.  If the Relying Party remembers the previous epoch ID "I" during an epoch window as discussed in epochfreshness, and the message is received during that window, the Attestation Result is accepted as fresh, and otherwise it is rejected as stale. 16.4. 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 Attester conveys Evidence to the Relying Party, which treats it as opaque and simply forwards it on to the Verifier. The time considerations in this example are equivalent to those discussed under Example 1 above. 16.5. 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_r)-time(NR_r) < 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_v)-time(RG_v)", then the Relying Party can check "time(OP_r)-time(ER_r) < time(RX_v)- time(RG_v)". </del>