Re: New issue: Header type for JWT format values

That'll work. I think it will be simplest for us to:

   - Treat Txn-Token as an unstructured field
   - Keep the value as an unquoted JWT.

Are there any concerns/issues with this approach?

Thanks,
Atul


On Wed, Jul 23, 2025 at 10:10 AM Rory Hewitt <rory.hewitt@gmail.com> wrote:

> > I don't believe that is true.
>
> This was also my take - Structured Fields should be used where the field
> value is in any way 'complex', but if it's just a single value, it can (and
> maybe should) be used as-is.
>
> JWTs are a relatively new but also common standard and hence my
> suggestion that you simply define the Txn-Token field as a basic unquoted
> string which allows any characters, so it can be passed as:
>
> Txn-Token: eyJhbGciOiJ...mqJp-QV30
>
> (on the assumption that the sender passes a valid JWT). Or you could
> define the field value as a valid JWT (three strings delimited by dots,
> with appropriate character sets for the two Base64 Url-encoded sections and
> for the key).
>
> Rory
>
> On Wed, Jul 23, 2025 at 9:51 AM Roy T. Fielding <fielding@gbiv.com> wrote:
>
>> On Jul 22, 2025, at 2:14 PM, Darrel Miller <darrel@tavis.ca> wrote:
>>
>> The current guidance is that all new HTTP fields are defined using
>> structured field values.
>>
>>
>> I don't believe that is true.
>>
>> If a new field would benefit from having a structured field value,
>> the usual suspects will ask for reasons why it isn't structured. That is,
>> structured fields have a known set of benefits for many potential
>> definitions
>> and the folks defining a new field may not be aware of those benefits.
>>
>> OTOH, there are many common fields for which structured field values
>> would be a waste of processing time and extra bytes on the wire.
>> Other usual suspects will ask for justification before wasting internets
>> on a syntax that isn't useful.
>>
>> Neither one is ensured by the current review process, which typically
>> allows
>> anyone to mint any field name with any arbitrary syntax, provided that
>> there
>> is some document that describes it. Not everything starts out as an I-D.
>>
>> IMO, the field described here is not suitable as a structured field value
>> because the structure has already been encoded as a token. I don't think
>> adding quotes around it is useful.
>>
>> Better questions are whether encoding the data as a token is a good idea,
>> given the alternative of using a structured list, and whether the data
>> contains credentials?
>>
>>   https://www.rfc-editor.org/rfc/rfc9110.html#name-credentials
>>
>> Credentials belong inside the existing auth fields, not in extension
>> fields.
>> They need to be separated from other data to avoid compression and
>> other problematic handling/storage of extension fields.
>>
>> ....Roy
>>
>>
>
> --
> Rory Hewitt
>
> https://www.linkedin.com/in/roryhewitt
>