Hi David,
I am not referring to RFC 7519 (JWT) but to RFC 8259 (JSON).
I-JSON (i.e. Internet-JSON) mandates the uniqueness of claim names in an
object (as well as JWT).
RFC 8259 does not mandate uniqueness.
Denis
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> 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
