Original text:
protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a <del> client, using the "WWW-Authenticate" HTTP header.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </del>  Token redemption: An action by which a client presents a token to <del> an origin, using the "Authorization" HTTP header. </del>  2. 2.1. 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. </del>  Origins that support this authentication scheme need to handle the following tasks: Clients can ignore the challenge if the token-key is invalid or otherwise untrusted. <del> The header MAY also include the standard "realm" attribute, if </del>  desired.  Issuance protocols MAY require other attributes. <del> As an example, the WWW-Authenticate header could look like this: </del>  Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the Caching and pre-fetching of tokens is discussed in caching. <del> Note that it is possible for the WWW-Authenticate header to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header could look like this: </del>  Origins should only include challenges for different types of issuance protocols with functionally equivalent properties.  For credentials MUST be ignored. Clients present this Token structure to origins in a new HTTP request <del> using the Authorization header as follows: </del>  For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate

Reviewer comments:
This one goes out to all the HTTP pedants out there =)
There's a few cases of rather than , which is puts you on HTTP's naughty list

Revised text:
protocol to create a signed token. Token challenge: A requirement for tokens sent from an origin to a  <ins> client, using the "WWW-Authenticate" HTTP header field.  This challenge is bound to a specific token issuer and issuance protocol, and may be additionally bound to a specific context or origin name. </ins> Token redemption: An action by which a client presents a token to  <ins> an origin, using the "Authorization" HTTP header field. </ins> 2. 2.1. Origins send a token challenge to clients in an "WWW-Authenticate"  <ins> header field 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. </ins> Origins that support this authentication scheme need to handle the following tasks: Clients can ignore the challenge if the token-key is invalid or otherwise untrusted.  <ins> The header field MAY also include the standard "realm" attribute, if </ins> desired.  Issuance protocols MAY require other attributes.  <ins> As an example, the WWW-Authenticate header field could look like this: </ins> Upon receipt of this challenge, a client uses the message and keys in the issuance protocol indicated by the token_type.  If the Caching and pre-fetching of tokens is discussed in caching.  <ins> Note that it is possible for the WWW-Authenticate header field to include multiple challenges.  This allows the origin to indicate support for different token types, issuers, or to include multiple redemption contexts.  For example, the WWW-Authenticate header field could look like this: </ins> Origins should only include challenges for different types of issuance protocols with functionally equivalent properties.  For credentials MUST be ignored. Clients present this Token structure to origins in a new HTTP request  <ins> using the Authorization header field as follows: </ins> For token types that support public verifiability, origins verify the token authenticator using the public key of the issuer, and validate