From JWT RFC 7519, section-4:
The Claim Names within a JWT Claims Set
MUST be unique; JWT parsers MUST either reject JWTs with duplicate
Claim Names or use a JSON parser that returns only the lexically last
duplicate member name, as specified in Section 15.12 ("The JSON
Object") of ECMAScript 5.1 [ECMAScript].
I can’t speak to whether if, had timelines had been different, whether JWT
would have referenced I-JSON.
-DW
> On Oct 3, 2023, at 9:43 AM, Denis <denis.i...@free.fr> wrote:
>
> Hi Watson,
>
> The word "semantics" is not present in RFC 8259.
>
> I looked for the word "unique" in RFC 8259. There are three occurrences of
> that word in clause 4. Objects,
> in particular:
> The names within an object SHOULD be unique
> There is indeed a "SHOULD", but not a "SHALL".
>
> If there were a "SHALL", in case of a claim name duplicate, RFC 8259 would
> have said what SHALL be the behaviour of the software implementation,
> but this is not the case.
>
>
> An object whose names are all unique is interoperable in the sense
> that all software implementations receiving that object will agree on
> the name-value mappings. When the names within an object are not
> unique, the behavior of software that receives such an object is
> unpredictable. Many implementations report the last name/value pair
> only. Other implementations report an error or fail to parse the
> object, and some implementations report all of the name/value pairs,
> including duplicates.
>
> JSON parsing libraries have been observed to differ as to whether or
> not they make the ordering of object members visible to calling
> software. Implementations whose behavior does not depend on member
> ordering will be interoperable in the sense that they will not be
> affected by these differences..
>
> An application that receives an object should anyway retrieve the appropriate
> schema to check whether what it has received complies with the schema.
> If the schema indicates that several claims with the same name can be
> present, then the application should use an appropriate software
> implementation of the JSON decoder.
>
> An application using a JSON structure should describe what it expects.
> Currently, the following text is present:
>
> The JWT MUST contain an "iss" (issuer) claim ...
> The JWT MUST contain an "status_list" (status list) claim ...
>
> Maybe, in the future, this would be changed into:
>
> The JSON object MUST contain a single occurrence of an "iss" (issuer)
> claim ...
> The JSON object MUST contain at least one occurrence of an "status_list"
> (status list) claim ...
>
> Denis
>> On Mon, Oct 2, 2023, 11:56 PM Denis <denis.i...@free.fr>
>> <mailto:denis.i...@free.fr> wrote:
>>> Hi Justin,
>>>
>>> Your premise relies on a feature of JSON that does not exist. JSON does not
>>> provide well-defined behavior for repeated names within an object:
>>>
>>> When the names within an object are not
>>> unique, the behavior of software that receives such an object is
>>> unpredictable.
>>>
>>> You should also cite the next two sentences which are:
>>>
>>> Many implementations report the last name/value pair only. Other
>>> implementations report an error or fail
>>> to parse the object, and some implementations report all of the
>>> name/value pairs, including duplicates.
>>>
>>> A specification might require to use implementations that report all of the
>>> name/value pairs, including duplicates.
>> That's not sticking to JSON semantics. Extending JSON to be a
>> multifunction or worse a sequence of key value pairs changes the
>> semantics. If you use JSON stick to RFC 8259 as it interoperates not
>> gratuitously cause problems.
>>
>> Justin is right.
>>
>> Sincerely,
>> Watson Ladd
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
