Original text:
15.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. <del> 15.4. </del>  The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any

Reviewer comments:
This is an evolution of PR and based on Issue Attester Awareness time(AA) is not included in this PR (see ), but a concise definition of Handle received (HR). The included diagram might need more work. Also a "background-check version" might be perceived as missing. Do we need one? (oh and the compilations errors due to malformed references are also fixed in this PR. pls always make sure your commit compiles before push)
PR and PR merged text that I had, and continue to have, problems with. A summary of the problems follows: 1) It includes events (CC, RP) that are not used in any checks in the text. I had pointed this out before when the PR was generated, but the PR was merged without addressing this comment. 2) The section about using timestamps with synchronized clocks was removed and replaced with a section that talks about a different mechanism (handles) that is not in any RFC or WG document. I believe that such replacement is inappropriate. If the WG adopts a document that talks about a handle distribution mechanism, then a section can be added. Or if there is a standard from another org that can be referenced then it's fine to add one in that case too. But I think it should not replace the section discussing the well known technique of synchronized clocks (e.g., using secure NTP, or PTP (IEEE 1588-2002) or whatever other standard mechanism). 3) time(HD) is problematic as phrased since all the other events are times as seen by a single entity, whereas time(HD) does not clearly say whose perspective (i.e., whose clock) it is from... is it the distributor's? Text is unclear. 4) It talks about nonces in a timestamp section, which I think causes confusion since there's already a separately section about nonces and this section is labeled to be scoped to timestamps. Addressing might address this naturally, if it uses a different section title. 5) There are some editorial typos, such as capital "The" in the middle of a sentence, etc. 6) I have no idea what "delta(time(HD),time(EG))distribution-interval" is supposed to mean. Normally I would expect an equality for any condition to be evaluated, but I have no idea what this check is. 7) time(HD) and time(EG) are according to different clocks (if my guess about point 3 above is right) and so the delta is not directly comparable. I'm not sure how point 6 accounts for this. 8) The phrase "A nonce not predictable to an Attester (recentness & uniqueness) is sent to an Attester" has "(recentness & uniqueness)" which doesn't read well (sounds like bad grammar) to me, and is not explained.
Hopefully PR now addresses this issue.
PR reverts the text, leaving the work in progress in PR
fixed by .
Much better than previous PR but needs some cleanup

Revised text:
15.3. <ins> Handles are a third option to establish time-keeping next to nonces or timestamps.  Handles are opaque data intended to be available to all RATS roles that interact with each other, such as the Attester or Verifier, in specified intervals.  To enable this availability, handles are distributed centrally by the Handle Distributor role over the network.  As any other role, the Handle Distributor role can be taken on by a dedicated entity or collapsed with other roles, such as a Verifier.  The use of handles can compensate for a lack of clocks or other sources of time on entities taking on RATS roles.  The only entity that requires access to a source of time is the entity taking on the role of Handle Distributor. Handles are different from nonces as they can be used more than once and can be used by more than one entity at the same time.  Handles are different from timestamps as they do not have to convey information about a point in time, but their reception creates that information.  The reception of a handle is similar to the event that increments a relative tickcounter.  Receipt of a new handle invalidates a previously received handle. 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". 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". Due to the validity-duration of handles, multiple different pieces of Evidence can be generated based on the same handle.  The resulting granularity (time resolution) of Evidence freshness is typically lower than the resolution of clock-based tickcounters. The following example illustrates a hypothetical Background-Check Model solution that uses handles and requires a trustworthy time source available to the Handle Distributor role. 15.4. </ins> 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.  <ins> 15.5. </ins> The following example illustrates a hypothetical Background-Check Model solution that uses nonces and thus does not require that any