Draft: draft-ietf-privacypass-auth-scheme

Commentary: Is this a breaking change ? In my reference implementation , I grab everything after the prefix because that 's what the spec said to do . 
 Well , it would break implementations that do not use the generic HTTP auth grammar for challenges / credentials . 
 So , yes , this is a breaking change then =) Before this change the spec did not specify the grammar precisely . 
 Well ; it said that it is an HTTP auth scheme , and that , by definition , causes specific syntax requirements . OK , let me rephrase this ... The spec should say that is uses " # auth - param " ( as per ) and then maybe clarify that this may require quoting base64 encoded fields . 
 Right , if the padding is n't needed , then it would be OK to not quote . Our implementation does handle receiving the quotes or not correctly , so the spec was out of alignment there . This is the right change to make . 
 RFC9110 has this to say about encoding : Most of the implementations of authentication headers I 've seen do not use any sort of generic parsing components . Now , I 've not seen very many , but enough to conclude that people just reimplement whatever parsing is needed based on the auth type . Do you know how common it is for implementations to rely on these " generic " parsing functions ? I ask because this change means that servers that were not previously supporting both types of auth - param encodings need to , and there does n't seem to be any good reason to do so rather than , say , just pick one . If a server is using these generic parsing functions , then they can continue using them . Otherwise , if they 're rolling parsing fresh , they have a simpler task at hand . Assuming clients can also easily pick one option , what 's the technical reason for wanting to support both ? 
 Apart of not having to rewrite parsers for each scheme ? Clients need to use a generic parser , because WWW - A can hold a list of different challenges . To get to the point where a client can pick the " best " challenge , it actually has to consume the full combined field value , and the only way to do that is a parser that is scheme - agnostic . 
 let me know if this text looks good now 
 Approved and taking my concerns to this ! 
 Not sure I understand the question . The syntax for the authentication fields is defined in RFC 9110 . You really ca n't change it ( while conforming to that spec ) . All you get to do is naming the scheme and the auth - param names . 
 My objection is to the syntax in RFC 9110 itself . It 's unhelpfully flexible . But I 've settled with addressing that syntax elsewhere . 
 Then your objection is ~25 years late :-) . 
 Heh , I 'm aware ! :) 
 Julian pointed out the following : 
 You seem to be using . The usual method for having multiple drafts in a repo is to just drop multiple files in the root directory . The approach you have works until you try to do CI integration or access more advanced features , like the primitive support that exists for cross - document citations . See for a complete and operational setup .
"challenge", which contains a base64url-encoded RFC4648
TokenChallenge value.  Since the length of the challenge is not
fixed, the base64url data MUST include padding.  This MUST be
unique for every 401 HTTP response to prevent replay attacks.
This attribute is required for all challenges.
"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 data MUST
include padding.  This attribute MAY be omitted in deployments
where clients are able to retrieve the issuer key using an out-of-
band mechanism.
"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
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.
"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"
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.
When used for client authorization, the "PrivateToken" authentication
scheme defines one parameter, "token", which contains the base64url-
encoded Token struct.  Since the length of the Token struct is not
fixed, the base64url data MUST include padding.  All unknown or
unsupported parameters to "PrivateToken" authentication credentials
MUST be ignored.
When used for client authorization, the "PrivateToken" authentication
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
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.