Original text:
2.1. <del> Origins send a token challenge to Clients in an "WWW-Authenticate" </del>  header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. single octet indicating the length.  Challenges with redemption_context values of invalid lengths MUST be ignored. <del> "origin_name" is an optional string containing the name of the origin, which allows a token to be scoped to a specific origin. The string is prefixed with a 2-octet integer indicating the length, in network byte order.  If empty, any non-origin-specific token can be redeemed. </del>  When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes: band mechanism. "max-age", an optional attribute that consists of the number of <del> seconds for which the challenge will be accepted by the Origin. </del>  Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> Origins MAY also include the standard "realm" attribute, if desired. Issuance protocols MAY require other attributes. </del>  As an example, the WWW-Authenticate header could look like this: Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the TokenChallenge has a token_type the client does not recognize or <del> support, it MUST NOT parse or respond to the challenge. </del>  Note that it is possible for the WWW-Authenticate header to include <del> multiple challenges, in order to allow the Client to fetch a batch of </del>  multiple tokens for future use. For example, the WWW-Authenticate header could look like this: <del> If a Client fetches a batch of multiple tokens for future use that </del>  are bound to a specific redemption context (the redemption_context in <del> the TokenChallenge was not empty), Clients SHOULD discard these </del>  tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not <del> be linkable to the original context could allow the Origin to recognize a Client. </del>  2.1.1. unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. <del> Clients present this Token structure to Origins in a new HTTP request </del>  using the Authorization header as follows: For token types that support public verifiability, origins verify the origin tokens with empty contexts can be replayed from one party by another, as shown below.  Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past.  This can make it more As discussed in challenge, clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an <del> Origin using the redemption context state as a cookie to recognize </del>  clients. Applications SHOULD constrain tokens to a single origin unless the

Reviewer comments:
NAME please have a look!
From Ted Hardie in Vienna.
We should also clarify more explicitly how the client uses the origin name field for validating the context it is in.
Leaning towards allowing the being able to be a list of hostnames, with comma separation.
+1 to csv. We think this keeps the client impl's simple while allowing for the added flexibility of origin sets.
Might also have to say something about ignoring whitespace vs and then maybe just whitespace is the separator?
While I can understand the appeal, I'm not yet convinced we should do this until we have a use case and have thought through the possible privacy impacts.
perfect!

Revised text:
2.1.  <ins> Origins send a token challenge to clients in an "WWW-Authenticate" </ins> header with the "PrivateToken" scheme.  This challenge includes a TokenChallenge message, along with information about what keys to use when requesting a token from the issuer. single octet indicating the length.  Challenges with redemption_context values of invalid lengths MUST be ignored.  <ins> "origin_info" is an optional string containing one or more origin names, which allows a token to be scoped to a specific set of origins.  The string is prefixed with a 2-octet integer indicating the length, in network byte order.  If empty, any non-origin- specific token can be redeemed.  If the string contains multiple origin names, they are delimited with commas "," without any whitespace. </ins> When used in an authentication challenge, the "PrivateToken" scheme uses the following attributes: band mechanism. "max-age", an optional attribute that consists of the number of  <ins> seconds for which the challenge will be accepted by the origin. </ins> Clients can ignore the challenge if the token-key is invalid or otherwise untrusted.  <ins> The header MAY also include the standard "realm" attribute, if desired.  Issuance protocols MAY require other attributes. </ins> As an example, the WWW-Authenticate header could look like this: Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the TokenChallenge has a token_type the client does not recognize or  <ins> support, it MUST NOT parse or respond to the challenge.  If the TokenChallenge contains a non-empty origin_info field, the client MUST validate that the name of the origin that issued the authentication challenge is included in the list of origin names. Clients MAY have further restrictions and requirements around validating when a challenge is considered acceptable or valid.  For example, clients can choose to reject challenges that list origin names for which current connection is not authoritative (according to the TLS certificate). </ins> Note that it is possible for the WWW-Authenticate header to include  <ins> multiple challenges, in order to allow the client to fetch a batch of </ins> multiple tokens for future use. For example, the WWW-Authenticate header could look like this:  <ins> If a client fetches a batch of multiple tokens for future use that </ins> are bound to a specific redemption context (the redemption_context in  <ins> the TokenChallenge was not empty), clients SHOULD discard these </ins> tokens upon flushing state such as HTTP cookies COOKIES, or changing networks.  Using these tokens in a context that otherwise would not  <ins> be linkable to the original context could allow the origin to recognize a client. </ins> 2.1.1. unsupported parameters to "PrivateToken" authentication credentials MUST be ignored.  <ins> Clients present this Token structure to origins in a new HTTP request </ins> using the Authorization header as follows: For token types that support public verifiability, origins verify the origin tokens with empty contexts can be replayed from one party by another, as shown below. <ins> Token challenges that include non-empty origin_info bind tokens to one or more specific origins.  As described in challenge, clients only accept such challenges from origin names listed in the origin_info string.  Even if multiple origins are listed, a token can only be redeemed for an origin if the challenge has an exact match for the origin_info.  For example, if "a.example.com" issues a challenge with an origin_info string of "a.example.com,b.example.com", a client could redeem a token fetched for this challenge if and only if "b.example.com" also included an origin_info string of "a.example.com,b.example.com".  On the other hand, if "b.example.com" had an origin_info string of "b.example.com" or "b.example.com,a.example.com" or "a.example.com,b.example.com,c.example.com", the string would not match and the client would need to use a different token. </ins> Context-bound token challenges require clients to obtain matching tokens when challenged, rather than presenting a token that was obtained from a different context in the past.  This can make it more As discussed in challenge, clients SHOULD discard any context-bound tokens upon flushing cookies or changing networks, to prevent an  <ins> origin using the redemption context state as a cookie to recognize </ins> clients. Applications SHOULD constrain tokens to a single origin unless the