Re: New issue: Header type for JWT format values

Hi Poul-Henning,
We have existing software such as Tokenetes <https://tokenetes.io/> (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.
>