Re: New issue: Header type for JWT format values

If you have deployed software and want to shift to structured fields, it sounds like a new field name is in order.

Cheers,


> On 23 Jul 2025, at 12:13 am, Atul Tulshibagwale <atul@sgnl.ai> wrote:
> 
> Hi Poul-Henning,
> We have existing software such as Tokenetes (a CNCF Sandbox project) which use TraTs and the Txn-Token header as a single, unquoted value, which is the JWT.
> 
> Using sf-string would mean we have to place quotes around this value and change software in a backward incompatible way, which is not desirable. The other options would have the same issue. 
> 
> I suppose we have to decide whether we need to change our draft in order to fit one of the existing types, or does it make sense to define a new type that can readily accept a JWT value. I am inclined toward the latter, because I think there will be many headers (for example in the WIMSE working group) that will require such JWT values.
> 
> Atul
> 
> On Tue, Jul 22, 2025 at 3:46 AM Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> --------
> Brian Campbell writes:
> 
> 
> > RFC 7519 defines JWT but for the purpose of this conversation a JWT is text
> > that is composed of three base64url segments separated by the dot/period
> > "." character.
> 
> > There doesn't seem to be a natural fit of an HTTP Structured Field Values
> > to carry a JWT.
> 
> I'm not sure what your criteria is for "a natural fit", but I can see several
> ways that are neither inefficient nor (too) offensive to the eye:
> 
> A)  As a sf-string
> 
> B)  As three sf-strings in a sf-list
> 
> C)  Prepend a 'J' and call it a sf-token
>     (base64url fits in tchar, right ?)
> 
> D)  As three sf-binary in a sf-list.
> 
> 
> -- 
> Poul-Henning Kamp       | UNIX since Zilog Zeus 3.20
> phk@FreeBSD.ORG         | TCP/IP since RFC 956
> FreeBSD committer       | BSD since 4.3-tahoe    
> Never attribute to malice what can adequately be explained by incompetence.

--
Mark Nottingham   https://www.mnot.net/

Received on Wednesday, 23 July 2025 10:04:14 UTC