Change:
10. <del> It is important to prevent replay attacks where an attacker replays old Evidence or an old Attestation Result that is no longer correct. To do so, some mechanism of ensuring that the Evidence and Attestation Results are fresh, meaning that there is some degree of assurance that they still reflect the latest state of the Attester, and that any Attestation Results were generated using the latest Evidence and Appraisal Policy for Evidence.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, might change immediately after the Evidence or Attestation Results were generated.  The goal is merely to narrow the time window to something the Verifier (for Evidence) or Relying Party (for an Attestation Result) is willing to accept. There are two common approaches to providing some assurance of freshness.  The first approach is that a nonce is generated by a remote entity (e.g., the Verifier for Evidence, or the Relying Party for an Attestation Result), and the nonce is then signed and included along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed after the nonce was generated. A second approach is to rely on synchronized clocks, and include a signed timestamp (e.g., using I-D.birkholz-rats-tuda) along with the claims in the Evidence or Attestation Result, so that the remote entity knows that the claims were signed at that time, as long as it has some assurance that the timestamp is correct.  This typically requires additional claims about the signer's time synchronization mechanism in order to provide such assurance. In either approach, it is important to note that the actual values in claims might have been generated long before the claims are signed. If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values might have been generated at boot, and then used in claims as long as the signer can guarantee that they cannot have changed since boot. </del> <ins> A remote entity (Verifier or Relying Party) may need to learn the point in time (i.e., the "epoch") an Evidence or Attestation Result has been produced.  This is essential in deciding whether the included Claims and their values can be considered fresh, meaning they still reflect the latest state of the Attester, and that any Attestation Result was generated using the latest Appraisal Policy for Evidence. Freshness is assessed based on a policy defined by the consuming entity, Verifier or Relying Party, that compares the estimated epoch against an "expiry" threshold defined locally to that policy.  There is, however, always a race condition possible in that the state of the Attester, and the Appraisal Policy for Evidence, might change immediately after the Evidence or Attestation Result was generated. The goal is merely to narrow their recentness to something the Verifier (for Evidence) or Relying Party (for Attestation Result) is willing to accept.  Freshness is a key component for enabling caching and reuse of both Evidence and Attestation Results, which is especially valuable in cases where their computation uses a substantial part of the resource budget (e.g., energy in constrained devices). There are two common approaches for determining the epoch of an Evidence or Attestation Result. The first approach is to rely on synchronized and trustworthy clocks, and include a signed timestamp (see I-D.birkholz-rats-tuda) along with the Claims in the Evidence or Attestation Result.  Timestamps can be added on a per-Claim basis, to distinguish the time of creation of Evidence or Attestation Result from the time that a specific Claim was generated.  The clock's trustworthiness typically requires additional Claims about the signer's time synchronization mechanism. A second approach places the onus of timekeeping solely on the appraising entity, e.g., the Verifier (for Evidence), or the Relying Party (for Attestation Results), and might be suitable, for example, in case the Attester does not have a reliable clock or time synchronisation is otherwise impaired.  In this approach, a non- predictable nonce is sent by the appraising entity, and the nonce is then signed and included along with the Claims in the Evidence or Attestation Result.  After checking that the sent and received nonces are the same, the appraising entity knows that the Claims were signed after the nonce was generated.  This allows associating a "rough" epoch to the Evidence or Attestation Result.  In this case the epoch is said to be rough because: The epoch applies to the entire claim set instead of a more granular association, and The time between the creation of Claims and the collection of Claims is indistinguishable. Implicit and explicit timekeeping can be combined into hybrid mechanisms.  For example, if clocks exist and are considered trustworthy but are not synchronized, a nonce-based exchange may be used to determine the (relative) time offset between the involved peers, followed by any number of timestamp based exchanges.  In another setup where all Roles (Attesters, Verifiers and Relying Parties) share the same broadcast channel, the nonce-based approach may be used to anchor all parties to the same (relative) timeline, without requiring synchronized clocks, by having a central entity emit nonces at regular intervals and have the "current" nonce included in the produced Evidence or Attestation Result. It is important to note that the actual values in Claims might have been generated long before the Claims are signed.  If so, it is the signer's responsibility to ensure that the values are still correct when they are signed.  For example, values generated at boot time might have been saved to secure storage until network connectivity is established to the remote Verifier and a nonce is obtained. </ins> A more detailed discussion with examples appears in time- considerations.

Discussion:
This commit slightly changes the Freshness section to reflect the outcome of the discussion around PR . (Hopefully I've managed to capture the gist of Henk's thinking without disrupting too much the existing flow.) TL;DR The key change here is the removal of reply protection as a goal in itself. The section now states clearly that the overall goal is instead the identification of the point in time when attestation claims have been signed and/or generated so that a freshness policy can be applied. In this perspective, the fundamental property provided by a nonce-based scheme with regards to freshness is its ability to lock the requester's clock to the underlying protocol transaction, thus indirectly establishing the epoch of the attestation / verification event. By making the nonce unique and non-predictable, the timeline locking cannot be subverted, which provides anti-replay. However, that is a nice side-effect rather than the primary goal. This commit also adds some precision around the nonce and clock properties - unpredictability and trustworthiness respectively.
Added consolidated text based on Thomas initial version and review from MCR
So, if is dead, can you close it?
Done.