Change:
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 <del> fixed, the base64url data MUST include padding.  All unknown or unsupported parameters to "PrivateToken" authentication credentials MUST be ignored. </del> <ins> 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. </ins> Clients present this Token structure to origins in a new HTTP request using the Authorization header as follows:

Discussion:
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 URL) and then maybe clarify that this may require quoting base64 encoded fields.
Right, if the padding isn'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.
NAME 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 doesn'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.
NAME 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 can'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.