Original text:
Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens. <del> This document defines a common HTTP authentication scheme (RFC9110), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens. </del>  Clients and relying parties interact using this scheme to perform the token challenge and token redemption flow.  Clients use a token 2. <del> Token redemption is performed using HTTP Authentication (RFC9110), with the scheme "PrivateToken".  Origins challenge clients to present a token from a specific issuer (challenge).  Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin (redemption). </del>  2.1. "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not fixed, the base64url value MUST include padding.  As an <del> Authentication Parameter ("auth-param" from RFC9110), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks.  This attribute is required for all challenges. </del>  "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. Since the length of the key is not fixed, the base64url value MUST include padding.  As an Authentication Parameter ("auth-param" <del> from RFC9110), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This attribute MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. </del>  "max-age", an optional attribute that consists of the number of seconds for which the challenge will be accepted by the origin. scheme defines one parameter, "token", which contains the base64url- encoded Token struct.  Since the length of the Token struct is not fixed, the base64url value MUST include padding.  As an <del> Authentication Parameter ("auth-param" from RFC9110), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. </del>  Clients present this Token structure to origins in a new HTTP request using the Authorization header field as follows: This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme <del> Registry" defined in RFC9110. </del>  Authentication Scheme Name: PrivateToken

Reviewer comments:
Previously, the document linked to RFC 7235, whose whole purpose was to discuss HTTP Authentication. Now you kjust link to RFC 9110, which all of HTTP semantics. Suggest that you link to Section 11 of RFC 9110 to make the reader's life easier.

Revised text:
Different types of authenticators, using different token issuance protocols, can be used as Privacy Pass tokens.  <ins> This document defines a common HTTP authentication scheme (RFC9110, Section 11), PrivateToken, that allows clients to redeem various kinds of Privacy Pass tokens. </ins> Clients and relying parties interact using this scheme to perform the token challenge and token redemption flow.  Clients use a token 2.  <ins> Token redemption is performed using HTTP Authentication (RFC9110, Section 11), with the scheme "PrivateToken".  Origins challenge clients to present a token from a specific issuer (challenge).  Once a client has received a token from that issuer, or already has a valid token available, it presents the token to the origin (redemption). </ins> 2.1. "challenge", which contains a base64url-encoded RFC4648 TokenChallenge value.  Since the length of the challenge is not fixed, the base64url value MUST include padding.  As an  <ins> Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This challenge value MUST be unique for every 401 HTTP response to prevent replay attacks. This attribute is required for all challenges. </ins> "token-key", which contains a base64url encoding of the public key for use with the issuance protocol indicated by the challenge. Since the length of the key is not fixed, the base64url value MUST include padding.  As an Authentication Parameter ("auth-param"  <ins> from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  This attribute MAY be omitted in deployments where clients are able to retrieve the issuer key using an out-of-band mechanism. </ins> "max-age", an optional attribute that consists of the number of seconds for which the challenge will be accepted by the origin. scheme defines one parameter, "token", which contains the base64url- encoded Token struct.  Since the length of the Token struct is not fixed, the base64url value MUST include padding.  As an  <ins> Authentication Parameter ("auth-param" from RFC9110, Section 11.2), the value can be either a token or a quoted-string, and might be required to be a quoted-string if the base64url string includes "=" characters.  All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. </ins> Clients present this Token structure to origins in a new HTTP request using the Authorization header field as follows: This document registers the "PrivateToken" authentication scheme in the "Hypertext Transfer Protocol (HTTP) Authentication Scheme  <ins> Registry" defined in RFC9110, Section 16.4. </ins> Authentication Scheme Name: PrivateToken