Re: New issue: Header type for JWT format values

Thanks Tim, and everyone who contributed to this discussion.

Atul

On Wed, Jul 23, 2025 at 11:11 AM Tim Bray <tbray@textuality.com> wrote:

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