Re: New issue: Header type for JWT format values

Pretty sure that's the right thing to do. There are plenty of ID tokens
flying around in openID Connect transactions already so it's not as though
this is anything new..

On Wed, Jul 23, 2025, 10:33 AM Atul Tulshibagwale <atul@sgnl.ai> wrote:

> 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
>>
>