- From: Rory Hewitt <rory.hewitt@gmail.com>
- Date: Wed, 23 Jul 2025 13:55:52 -0700
- To: Martin Thomson <mt@lowentropy.net>
- Cc: Roy Fielding <fielding@gbiv.com>, Darrel Miller <darrel@tavis.ca>, Atul Tulshibagwale <atul@sgnl.ai>, Amos Jeffries <squid3@treenet.co.nz>, "ietf-http-wg@w3.org" <ietf-http-wg@w3.org>
- Message-ID: <CAEmMwDysUV2VjYnteEpAA-w16RvDfS177EyJWYo=ZuaZ0zQ5Fw@mail.gmail.com>
> I don't recommend decomposing the JWT. We should treat JWTs as opaque. > Suppose for example that someone wanted to extend JWTs to add, idk, a proof of possession or something where they add extra items all separated with ASCII '.', then any software that expects exactly three such items will break. I 100% agree with your first line. As to your second... the JWT is a pretty well-understood and conformed-to standard. JWTs allow folks to include basically any information within the JWT itself, so depending on the requirement, they can either add a new payload claim (if they have the signing key) or just add a separate header. If someone is going to start appending things to the encoded JWT itself as in your example, that's SUCH a bad idea that I don't think we should worry about it - their software will just not work with anything else that expects a standard JWT. Not disagreeing with you that it *could* happen, but should we worry about fools being fools? Rory On Wed, Jul 23, 2025 at 1:46 PM Martin Thomson <mt@lowentropy.net> wrote: > 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. > -- Rory Hewitt https://www.linkedin.com/in/roryhewitt
Received on Wednesday, 23 July 2025 20:56:08 UTC