Merge pull request #429 from ietf-wg-privacypass/caw/lars-nits

Address Lars' nits

draft-ietf-privacypass-auth-scheme.md

@@ -307,7 +307,7 @@ An empty redemption context is not bound to any property of the client session.
 Preventing double spending on tokens requires the origin to keep state
 associated with the redemption context. The size of this state varies based on
 the size of the redemption context. For example, double spend state for unique,
-per-request redemption contexts does only needs to exist within the scope of
+per-request redemption contexts only needs to exist within the scope of
 the request connection or session. In contrast, double spend state for empty
 redemption contexts must be stored and shared across all requests until
 token-key expiration or rotation.
@@ -377,7 +377,7 @@ above.
 - "challenge_digest" is a 32-octet value containing the hash of the
 original TokenChallenge, SHA256(TokenChallenge).
 
-- "token_key_id" is an Nid-octet identifier for the token authentication
+- "token_key_id" is a Nid-octet identifier for the token authentication
 key. The value of this field is defined by the token_type and corresponding
 issuance protocol.
 
@@ -427,7 +427,7 @@ When used in contexts like websites, origins that challenge clients for
 tokens need to consider how to optimize their interaction model to ensure a
 good user experience.
 
-Tokens challenges can be performed without explicit user involvement, depending
+Token challenges can be performed without explicit user involvement, depending
 on the issuance protocol. If tokens are scoped to a specific origin,
 there is no need for per-challenge user interaction. Note that the issuance
 protocol may separately involve user interaction if the client needs to be
@@ -604,7 +604,7 @@ and limited experimentation.
 This document defines several Reserved values, which can be used by clients
 and servers to send "greased" values in token challenges and responses to
 ensure that implementations remain able to handle unknown token types
-gracefully (this technique is inspired by {{?RFC8701}}). Implemenations SHOULD
+gracefully (this technique is inspired by {{?RFC8701}}). Implementations SHOULD
 select reserved values at random when including them in greased messages.
 Servers can include these in TokenChallenge structures, either as the only
 challenge when no real token type is desired, or as one challenge in a list of
@@ -617,7 +617,7 @@ The initial contents for this registry consist of the following Values.
 For each Value, the Name is "RESERVED", the Publicly Verifiable, Public
 Metadata, Private Metadata, Nk, and Nid attributes are all assigned "N/A",
 the Reference is this document, and the Notes attribute is "None". The
-iniital list of Values is as follows:
+initial list of Values is as follows:
 
 - 0x0000
 - 0x02AA