Re: New issue: Header type for JWT format values

On Wed, Jul 23, 2025 at 01:55:52PM -0700, Rory Hewitt wrote:
> > 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?

That could be a new auth method, not Bearer but Pop or some such method
name.  It's really not crazy.  Think, a JWT has a header, the token
body, and a signature (well, signed ones; there are encrypted JWTs too,
though rarely used).  If the claims were to include the public key that
the supplicant has to prove possession of to the relying party, then one
would then append a second signature.

At any rate, decomposing tokens is a bad idea.  Don't.  HTTP does not
need to know the internals of its auth methods' tokens, and does not
need to decompose and recompose them.  We wouldn't do that for, say,
Negotiate, or SCRAM.

Nico
--

Received on Thursday, 24 July 2025 03:21:20 UTC