Draft: draft-ietf-privacypass-architecture

Commentary: Some editorial suggestions . 
 Awesome Thanks !
Privacy Pass is an architecture for authorization based on privacy-
preserving authentication mechanisms.  Typical approaches for
authorizing clients, such as through the use of long-term cookies,
are not privacy-friendly since they allow servers to track clients
across sessions and interactions.  Privacy Pass takes a different
approach: instead of presenting linkable state carrying information
to servers, e.g., a cookie indicating whether or not the client is an
authorized user or has completed some prior challenge, clients
present unlinkable proofs that attest to this information.  These
proofs, or tokens, are private in the sense that a given token cannot
be linked to the protocol instance in which that token was initially
issued.
Privacy Pass is an architecture for authorization based on privacy-
preserving authentication mechanisms.  Typical approaches for
authorizing clients, such as through the use of long-term cookies,
are not privacy-friendly since they allow servers to track clients
across sessions and interactions.  Privacy Pass takes a different
approach: instead of presenting linkable state-carrying information
to servers, e.g., a cookie indicating whether or not the client is an
authorized user or has completed some prior challenge, clients
present unlinkable proofs that attest to this information.  These
proofs, or tokens, are private in the sense that a given token cannot
be linked to the protocol interaction where that token was initially
issued.
The following terms are used throughout this document.
Client: An entity that seeks authorization to an Origin.
Origin: An entity that redeems tokens presented by Clients.
Issuer: An entity that issues tokens to Clients for properties
attested to by the Attester.
Attester: An entity that attests to properties of Client for the
purposes of token issuance.
An entity that seeks authorization to an Origin.
An entity that redeems tokens presented by Clients.
An entity that issues tokens to Clients for properties attested to
by the Attester.
An entity that attests to properties of Client for the purposes of
token issuance.
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step 6 and redeem its
token.  Otherwise, it invokes the issuance protocol to request a
token from the designated Issuer.
If the Client already has a token available that satisfies the
token challenge, e.g., because the Client has a cache of
previously issued tokens, it can skip to step-redemption and
redeem its token.  Otherwise, it invokes the issuance protocol to
request a token from the designated Issuer.
Redemption context: 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.
Issuance context: 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).
Attestation context: 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.  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.
Issuer-Client unlinkability.  This is similar to Origin-Client
unlinkability in that a Client in an issuer context is
indistinguishable from any other Client that might use the same
issuer context.  The set of Clients that share the same redemption
context is referred to as a redemption anonymity set.
Issuer-Client unlinkability.  This is similar to Origin-Client
unlinkability in that a Client in an issuance context is
indistinguishable from any other Client that might use the same
issuance context.  The set of Clients that share the same
redemption context is referred to as a redemption anonymity set.
At a high level, these properties ensure that no single party amongst
the Attester, Issuer, or Origin can link client identifying
information to client activity, e.g., the origin being accessed.
The manner in which Origin-Client, Issuer-Client, and Attester-Origin
unlinkability are achieved depends on the deployment model, type of
attestation, and issuance protocol details.  For example, as
discussed in deployment, failure to use a privacy-enhancing proxy
system such as Tor Dingledine2004 when interacting with Attesters,
Issuers, or Origins allows the set of possible Clients to be
partitioned by the Client's IP address, and can therefore lead to
unlinkability violations.  Similarly, malicious Origins may attempt
to link two redemption contexts together by using Client-specific
Issuer public keys.  See deployment and privacy for more information.
By ensuring that different contexts cannot be linked in this way,
only the Client is able to correlate information that might be used
to identify them with activity on the Origin.  The Attester, Issuer,
and Origin only receive the information necessary to perform their
respective functions.
The manner in which Origin-Client, Issuer-Client, and Attester-Origin
unlinkability are achieved depends on the deployment model, type of
attestation, and issuance protocol details.  For example, as
discussed in deployment, failure to use a privacy-enhancing proxy
system such as Tor DMS2004 when interacting with Attesters, Issuers,
or Origins allows the set of possible Clients to be partitioned by
the Client's IP address, and can therefore lead to unlinkability
violations.  Similarly, malicious Origins may attempt to link two
redemption contexts together by using Client-specific Issuer public
keys.  See deployment and privacy for more information.
Issuers are uniquely identifiable by all Clients with a consistent
identifier.  In a web context, this identifier might be the Issuer
host name.  Issuers maintain one or more configurations, including
issuance key pairs, for use in the issuance protocol.  Issuers can
rotate these configurations as needed to mitigate risk of compromise;
see rotation-and-consistency for more considerations around
configuration rotation.  The Issuer public key for each active
configuraton is made available to Origins and Clients for use in the
issuance and redemption protocols.
Issuers are uniquely identifiable by all Clients with a consistent
identifier.  In a web context, this identifier might be the Issuer
host name.  Issuers maintain one or more configurations, including
issuance key pairs, for use in the issuance protocol.  Issuers can
rotate these configurations as needed to mitigate risk of compromise;
see rotation-and-consistency for more considerations around
configuration rotation.  The Issuer public key for each active
configuration is made available to Origins and Clients for use in the
issuance and redemption protocols.
Certain instantiations of the issuance protocol may permit public or
private metadata to be cryptographically bound to a token.  As an
example, one trivial way to include public metadata is to assign a
unique Issuer public key for each value of metadata, such that N keys
yields log2(N) bits of metadata.  Metadata may be public or private.