Code change:
This nags at me a bit. I think you want to be crystal clear are what parts of Stuctured Fields you are and what you aren't. As far as I see, you want to use the aspect in order to reuse the serialization/deserialization, legal characters, legal range, etc., for the auth parameter values. But you don't need the aspect, which would allow you to parameterise the parameters. Does that sound accurate?
We added this sentence based on a URL from NAME Martin, do you have thoughts here? I think the intent was just to point out that we're in the new structured fields world even though Authorization hasn't been retrofitted yet
In , NAME pointed out that we can't simply use byte sequences from structured fields because authentication parameter values need to be which doesn't allow non-quoted colons. So I switched to double-quotes in dcc520544cf98cf634c9ca0a24119256fd18d58e, but that makes the usage of structured fields somewhat messy. Thoughts?
Copying my comment from the change
Good call. I now added both colons and double-quotes via 690ee072bb450ab631db5b32a23b457cec9bb6be
From Ilari Liusvaara on the : I renamed this issue to track whether we want to keep structured fields or not. Personally, I don't have a strong opinion either way.
I could live without structured fields here, presumably there are servers that already have to handle Authorization fields using the more-traditional encodings
I'll note however that if we go with we'll need to either double-quote it or explicitly ban padding, because is not allowed as part of
While base64 proper is often padded, it is more common for base64url to be unpadded (indeed, I think that the string "base64url" specifically refers to the unpadded version if you follow it to its origin, which I think is URL).
dates back at least as far as and that spec explicitly : None of which is a problem, we just need to be explicit. We know how to do that.
Right, the 7515 thing was what we ended up using in another context, where padding was explicitly not included. Clearly, we shouldn't use it here either[^1]. [^1]: I hold the view that it shouldn't be used in any situation, because if knowing the length is important, you would have a length prefix or delimiter, rendering padding pointless for anything other than protection against traffic analysis. And you can't arbitrarily pad with base64 padding, so that's no good.
I'd ideally want to align with draft-ietf-privacypass-auth-scheme. We reviewed this a lot with NAME and went back and forth and ended up with: So from a syntax standpoint, this is "base64url and you don't need quotes, but do include quotes if you have padding". If you define that you don't use padding, then you don't need quotes. So I think things can be consistent here.
Based on the conversation in the room at IETF 117, I'm inclined to make these no longer structured headers, and to use base64url without padding, without quotes, and without colons.

Related discussion:
text: 5. This specification defines the following authentication parameters. <del> These parameters use structured fields (STRUCTURED-FIELDS) in their definition, even though the Authorization field itself does not use structured fields.  Due to the syntax requirements for authentication parameters, the byte sequences defined below SHALL be enclosed in double-quotes (the base64-encoded data and colon delimeters are enclosed in double-quotes, see example in example). </del> <ins> All of the byte sequences below are encoded using base64url (see BASE64) without quotes and without padding.  In other words, these byte sequence authentication parameters values MUST NOT include any characters other then ASCII letters, digits, dash and underscore. The integer below is encoded without a minus and without leading zeroes.  In other words, the integer authentication parameters value MUST NOT include any characters other than digits, and MUST NOT start with a zero unless the full value is "0". Using the syntax from ABNF: </ins> 5.1.