Last Call Review of draft-ietf-privacypass-auth-scheme-11
review-ietf-privacypass-auth-scheme-11-opsdir-lc-qu-2023-07-10-00

# OPSDIR review of draft-ietf-privacypass-auth-scheme

I have reviewed this document as part of the Operational directorate's ongoing
effort to review all IETF documents being processed by the IESG.  These
comments were written with the intent of improving the operational aspects of
the IETF drafts. Comments that are not addressed in the last-call may be
included in AD reviews during the IESG review.  Document editors and WG chairs
should treat these comments just like any other last-call comments.

The document is very clear and well-written. The operation process is described
well.

Note: I'm not a security expert, so the review is done more from a general
reader's perspective.

The document is ready. However there are a few nits for the authors to consider.

## nits
The line numbers are from the idnits.

118	   as appropriate for its use case.  These options allow for different
119	   deployment models to prevent double-spending, and allow for both
120	   interactive (online challenges) and non-interactive (pre-fetched)
121	   tokens.
two "allow for", the second should be removed.

262	   *  "challenge", which contains a base64url-encoded [RFC4648]

272	   *  "token-key", which contains a base64url encoding of the public key
Better make the language consistent in these two sections.

364	   context.  For example, double spend state for unique, per-request
365	   redemption contexts does only needs to exist within the scope of the
"does" should be removed.

443	   *  "authenticator" is a Nk-octet authenticator that covers the
a Nk-octet/an Nk-octet

565	   Moreover, when a Client holds cross-origin tokens with empty
566	   contexts, it is possible for any Origin in the cross-origin set to
567	   deplete that Client set of tokens.  To prevent this from happening,
568	   tokens can be scoped to single Origins (with non-empty origin_info)
569	   such that they can only be redeemed for a single Origin.
570	   Alternatively, if tokens are cross-Origin, Clients can use alternate
571	   methods to prevent many tokens from being redeemed at once.  For
572	   example, if the Origin requests an excess of tokens, the Client could
573	   choose to not present any tokens for verification if a redemption had
574	   already occurred in a given time window.

Please make sure it's consistent whether a word's first letter should be
capitalized: cross-origin/cross-Origin, client/Client, origin/Origin etc.