- From: Martin Thomson <mt@lowentropy.net>
- Date: Wed, 23 Jul 2025 22:46:25 +0200
- To: "Roy Fielding" <fielding@gbiv.com>, "Darrel Miller" <darrel@tavis.ca>
- Cc: "Rory Hewitt" <rory.hewitt@gmail.com>, "Atul Tulshibagwale" <atul@sgnl.ai>, "Amos Jeffries" <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
On Wed, Jul 23, 2025, at 18:51, Roy T. Fielding wrote: > IMO, the field described here is not suitable as a structured field value > because the structure has already been encoded as a token. I don't think > adding quotes around it is useful. This turns out to be true, but it isn't obvious. RFC 4648 defines base64url, which is used by JWT (RFC 7519). All the characters in the base64url table are in RFC 9110 tchar. That's good, but RFC 9651 says that the first character has to be alphanumeric. Thankfully, all characters that might start JSON are in the ASCII range because they are either delimiters "{", "[", '", etc... or things like true, false, null. The first six bits of the ASCII range all encode to the first half of the base64 space, which is alphanumeric. RFC 9651 tokens can take uppercase characters, unlike the labels used in parameters and dictionaries, so this works out. You can put a JWT in a structured field token and avoid all the mess around defining a header field properly without using RFC 9651.
Received on Wednesday, 23 July 2025 20:46:52 UTC