Re: New issue: Header type for JWT format values

You are correct - I meant the "Authorization" header - apologies for the
confusion.

I guess my question is why you need to use a Structured Field at all -
surely the server can define that it expects the field value to simply be
the JWT?

Not all fields need to be structured - you can just use this format:

Txn-Token: eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.KMUFsIDTnFmyG3nMiGM6H9FNFUROf3wh7SmqJp-QV30

On Tue, Jul 22, 2025 at 1:52 PM Atul Tulshibagwale <atul@sgnl.ai> wrote:

> Hi Rory and Amos,
> I see these relevant headers in the HTTP field names registry:
>
>    - Authentication-Control
>    - Authentication-Info
>    - Authorization
>
> Of these, the "Authentication-Info" field seems to be a HTTP Response
> field (as seen in this description
> <https://www.rfc-editor.org/rfc/rfc9110.html#section-11.6.3> of the
> field). The "Authentication-Control" field also appears to be a HTTP
> Response field (see description here
> <https://www.rfc-editor.org/rfc/rfc8053.html#section-4>).
>
> The Authorization header cannot be used because it needs to be kept
> available for service-to-service authorization such as SPIFFE. The TraTs
> spec clarifies this here
> <https://www.ietf.org/archive/id/draft-ietf-oauth-transaction-tokens-05.html#section-8>
> .
>
> This is why we thought we would need a new header field.
>
> Thanks for your feedback and review,
> Atul
>
>
> On Tue, Jul 22, 2025 at 9:16 AM Rory Hewitt <rory.hewitt@gmail.com> wrote:
>
>> Is there a benefit to creating a specific new header for JWTs?
>>
>> I would suggest either passing them in an Authentication header (commonly
>> currently used by some apps) or the application which needs them can define
>> its own header (also common).
>>
>> On Tue, Jul 22, 2025 at 8:24 AM Amos Jeffries <squid3@treenet.co.nz>
>> wrote:
>>
>>> On 22/07/25 06:28, Atul Tulshibagwale wrote:
>>> > Hello,
>>> > We are currently working on a draft for Transaction Tokens <https://
>>> > datatracker.ietf.org/doc/draft-ietf-oauth-transaction-tokens/>, which
>>> > envisions a new HTTP Request Header called "Txn-Token" <https://
>>> > www.ietf.org/archive/id/draft-ietf-oauth-transaction-
>>> > tokens-05.html#name-txn-token-http-header>. The header value is
>>> expected
>>> > to be a JWT.
>>>
>>>
>>> Taking a brief looks at the document ...
>>>
>>>  > 2.1.  What are Transaction Tokens?
>>>  >
>>>  >   Txn-Tokens are short-lived, signed JWTs [RFC7519] that assert the
>>>  >   identity of a user or a workload and assert an authorization
>>> context.
>>>
>>>
>>> So, if I am reading that correctly these are a cross between login
>>> credentials and a session ID.
>>>
>>>
>>> I am wondering why these credentials are using a custom header instead
>>> of being sent as part of HTTP Authentication (request) and
>>> Authentication-Info (response) headers.
>>>
>>> There is a lot of HTTP security behaviour that can be leveraged just by
>>> using the Authn headers instead of re-inventing the wheel.
>>>
>>>
>>> Cheers
>>> Amos
>>>
>>>
>>
>> --
>> Rory Hewitt
>>
>> https://www.linkedin.com/in/roryhewitt
>>
>

-- 
Rory Hewitt

https://www.linkedin.com/in/roryhewitt