- From: Rory Hewitt <rory.hewitt@gmail.com>
- Date: Tue, 22 Jul 2025 14:06:18 -0700
- To: Atul Tulshibagwale <atul@sgnl.ai>
- Cc: Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
- Message-ID: <CAEmMwDxtfMG6QQf7NwxLDmUzwRiwh1Nr-Ff+igu665-2VJaR8w@mail.gmail.com>
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
Received on Tuesday, 22 July 2025 21:06:34 UTC