Change:
The definition of the redemption/issuance/attestation contexts seem to exist primarily to support the different unlinkability goals in the document. Let's take the redemption one, which is defined as: A digression on perspective Note that "Client visible" is probably ambiguous here; it could mean information about the client that is visible (though to whom?) or information that is visible to the client. This suggests that your goal is establish a point of reference or perspective for these: in this case, the relevant perspective is that of an Origin. But this was not my main point... The corresponding unlinkability definition says: This is a little confusing, because you might conceive of the defines the context as enclosing a single interaction between the Client and Origin, but this implies that a context encompasses multiple interactions with either the same client or different clients (all of which are indistinguishable). That makes the definition of the context seem like it lacks something. Does this refer to the information that is provided within that context that might be used to identify a client, from the perspective of the server? Finally, there is mention of an "an empty redemption context" in Section 3.1. I had no idea how to interpret this claim. Does empty refer to the set of clients? The set of interactions? The information provided in that context?
The empty redemption context comment is talking about the field of the challenge being empty / zero-length.
Basically, yeah, this is the idea. Perhaps framing it this way would be a more clear description. NAME regarding "empty redemption context," maybe we just say "an empty token challenge redemption context," or something, to make it clear that this is referring to the challenge field described in Section 3.1?

Discussion:
of contexts: The interactions and set of information shared between the Client <del> and Origin.  This context includes all information associated with redemption, such as the timestamp of the event, Client visible information (including the IP address), and the Origin name. </del> <ins> and Origin, i.e., the information that is provided or otherwise available to the Origin during redemption that might be used to identify a Client and construct a token challenge.  This context includes all information associated with redemption, such as the timestamp of the event, Client visible information (including the IP address), and the Origin name. </ins> The interactions and set of information shared between the Client, <del> Attester, and Issuer.  This context includes all information associated with issuance, such as the timestamp of the event, any Client visible information (including the IP address), and the Origin name (if revealed during issuance). </del> <ins> Attester, and Issuer, i.e., the information that is provided or otherwise available to Attester and Issuer during issuance that might be used to identify a Client.  This context includes all information associated with issuance, such as the timestamp of the event, any Client visible information (including the IP address), and the Origin name (if revealed during issuance).  This does not include the token challenge in its entirety, as that is kept secret from the Issuer during the issuance protocol. </ins> The interactions and set of information shared between the Client and Attester only, for the purposes of attesting the vailidity of <del> the Client.  This context includes all information associated with attestation, such as the timestamp of the event and any Client visibile information, including information needed for the attestation procedure to complete. </del> <ins> the Client, that is provided or otherwise available during attestation that might be used to identify the Client.  This context includes all information associated with attestation, such as the timestamp of the event and any Client visibile information, including information needed for the attestation procedure to complete. </ins> The privacy goals of Privacy Pass are oriented around unlinkability based on these contexts.  In particular, Privacy Pass aims to achieve

Origin-Client, Issuer-Client, and Attester-Origin unlinkability requires that issuance and redemption events be separated over time, <del> such as through the use of tokens with an empty redemption context, or be separated over space, such as through the use of an anonymizing proxy when connecting to the Origin. </del> <ins> such as through the use of tokens that correspond to token challenges with an empty redemption context (see redemption), or be separated over space, such as through the use of an anonymizing proxy when connecting to the Origin. </ins> 4.2.