Draft: draft-ietf-privacypass-architecture

Commentary: 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 : < details < summaryA digression on perspective</summaryNote 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 ... < /detailsThe 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  , 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 . 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 ?
The interactions and set of information shared between the Client
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.
The interactions and set of information shared between the Client,
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).
The interactions and set of information shared between the Client
and Attester only, for the purposes of attesting the vailidity of
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.
The interactions and set of information shared between the Client
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.
The interactions and set of information shared between the Client,
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.
The interactions and set of information shared between the Client
and Attester only, for the purposes of attesting the vailidity of
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.
Origin-Client, Issuer-Client, and Attester-Origin unlinkability
requires that issuance and redemption events be separated over time,
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.
Origin-Client, Issuer-Client, and Attester-Origin unlinkability
requires that issuance and redemption events be separated over time,
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.