Change:
This is a draft PR. More prose is needed around the sequence diagram.
fixed the required event tables entries The new sequence diagram illustrate a more concise "real life" story now and st the same time intends to fixes some ambiguities that snuck in when augmenting the overall diagram layout. Now ready for first walk-through in editors meeting.
looks good to me.
Personally, I find the new text much less clear than the old text
Discuss the impact that altering the distribution of handles (e.g., delaying, suppressing) has on the security of the protocol. Add relevant text to the Security Consideration section.
Is this more than just finishing ? If so, what?
The scope is different: deals with the example in the appendix, this one is for text that belongs to the security considerations. Regarding the "what": is the issue description insufficient? If so, do you have any suggestion on how to make it clearer?
The appendix on Handles needs some work to better clarify the concepts and simplify the flow. Some things about the text: Clearly define what is a handle; Explain its relation with epoch establishment; Clarify network jitter impact on handle validity; Explain what are the base rules for working with handles; Some further points on the sequence diagram: Fix confusing legend; Add some accompanying prose to explain the depicted use case as it's not self-evident;
fix all time to be delta

Discussion:
16.3. <del> The following example illustrates a hypothetical Passport Model solution that uses handles instead of nonces or timestamps.  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.  Due to distribution over the network, there is some jitter with respect to the time the Handle is received, 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'_v) + offset - time(HR_v)". 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_v) - time(EG_a) < 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(HR'_v)-time(HR_v)) - (time(HR_a)-time(EG_a)) < 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. </del> <ins> The example in fig-handle-passport illustrates a hypothetical Passport Model solution that uses handles instead of nonces or timestamps. The Handle Distributor broadcasts handle "H" which starts a new epoch "E" for a protocol participant upon reception at "time(HR)". The Attester generates Evidence incorporating handle "H" and conveys it to the Verifier. The Verifier appraises that the received handle "H" is "fresh" according to the definition provided in epochfreshness whereby retries are required in the case of mismatching handles, and generates an Attestation Result.  The Attestation Result is conveyed to the Attester. After the transmission of handle "H'" a new epoch "E'" is established when "H'" is received by each protocol participant.  The Attester relays the Attestation Result obtained during epoch "E" (associated with handle "H") to the Relying Party using the handle for the current epoch "H'".  If the Relying Party had not yet received "H'", then the Attestation Result would be rejected, but in this example, it is received. In the illustrated scenario, the handle for relaying an Attestation Result to the Relying Party is current, while a previous handle 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. </ins> 16.4.