I am the assigned ART-ART reviewer for this draft. I also did a Gen-ART
review of the previous version of this document.  Please treat these
comments just like any other last call comments.


Document: draft-ietf-privacypass-architecture-13
Reviewer: Russ Housley
Review Date: 2023-06-22
IETF LC End Date: 2023-07-03
IESG Telechat date: Unknown


Summary: Almost Ready

Major Concerns:

In Section 1, I think that a bit more context is necessary.  At a very high
level, this is an architecture for authorization based on privacy-preserving
authentication mechanisms.  So, this section needs to say more about
authentication, authorization, and how the two work together.  See the
discussion of these two concepts in RFC 4949.

In Section 2, I think that the definition of Attestation procedure should be
reworded to avoid using "trusted" in this manner.  The use of "trust" In
Section 3.2 is more in line with the usual use of this term.  Suggestion:

   Attestation procedure:  The procedure by which an Attester determines
      whether or not a Client has the specific set of properties 
      that are necessary for token issuance.


Minor Concerns:

Section 5: Please explain "viability of an open Web".


Nits:

Section 3.4.2: A reference for Tor would be useful.