Change:
cc NAME
[x] 1. The Reference PPEXT is not cited in the document. seems it could be sited in the into PR [x] 2. I think it would be good to explicitly say that the HTTP authentication protocol is targeted at redemption and the issuer protocol is targeted at issuance. PR [ ] 3. Last paragraph in section 3.2.1 mentions Origin Allow Lists. These allow lists are not specifically mentioned earlier in the document. Can you clarify this. [ ] 4. In section 4.3 and 4.4 is the attester involved in the TokeRequest and TokenResponse messages? Is the attester proxying the communication? It would be good to clarify this in the text. [ ] 5. Section 6 has an incomplete reference. [x] 6. It seems that the Reference to RFC 8446 is not needed. PR [ ] 7. The link - URL does not work perhaps this is the updated one? - URL

Discussion:
in attestation quality is therefore a deployment-specific task.  In Split Attester and Issuer deployments (see deploy-split), Issuers can choose to remove compromised Attesters from their trusted set until <del> the compromise is patched, without needing to modify Origin allow- lists. </del> <ins> the compromise is patched. </ins> 3.2.2.

4.3. In this model, the Origin and Issuer are operated by the same entity, <del> separate from the Attester, as shown in the figure below. </del> <ins> separate from the Attester, as shown in the figure below.  The Issuer accepts token requests that come from trusted Attesters.  Depending on the issuance protocol, the Attester may relay these requests between Client and Issuer over an authenticated channel, or trust may be established in some other manner. </ins> This model is useful for Origins that require Client-identifying attestation, e.g., through the use of application-layer account

4.4. In this model, the Origin, Attester, and Issuer are all operated by <del> different entities, as shown in the figure below. </del> <ins> different entities, as shown in the figure below.  As with the joint Origin and Issuer model, the Issuer accepts token requests that come from trusted Attesters, and the details of that trust establishment depend on the issuance protocol. </ins> This is the most general deployment model, and is necessary for some types of issuance protocols where the Attester plays a role in token

A consequence of limiting the number of participants (Attesters or Issuers) in Privacy Pass deployments for meaningful privacy is that <del> it forces concentrated centralization amongst those participants.{ {?CENTRALIZATION=I-D.nottingham-avoiding-internet-centralization}} discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what candidate participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the system used to control the Web's trust model. </del> <ins> it forces concentrated centralization amongst those participants. CENTRALIZATION discusses several ways in which this might be mitigated.  For example, a multi-stakeholder governance model could be established to determine what candidate participants are fit to operate as participants in a Privacy Pass deployment.  This is precisely the system used to control the Web's trust model. </ins> Alternatively, Privacy Pass deployments might mitigate this problem through implementation.  For example, rather than centralize the role