Mike> (Narrowing discussion to just the JSON parser comment.)
7. In the first paragraph of section 4, couldn't you wind up with different
answers because of the text, "use a JSON parser that returns only the lexically
last duplicate member name"? Full paragraph included for reference:
The members of the JSON object(s) representing the JWS Header
describe the digital signature or MAC applied to the JWS Protected
Header and the JWS Payload and optionally additional properties of
the JWS. The Header Parameter names within the JWS Header MUST be
unique; recipients MUST either reject JWSs with duplicate Header
Parameter 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].
Let's say you have the following:
{“alg”:”alg1”, “alg”:”alg2”}
{“alg”:”alg2”,”alg”:”alg1”}
You could end up with two difference answers about what is the value of the
member alg. A parser that reads everything and then re-emits may change the
order of the fields or emit only one of the fields and thus change the validity
of it.
Can it be reworded to avoid this potential issue?
Mike> When parsing the input “{“alg”:”alg1”, “alg”:”alg2”}” legal outcomes are
either rejecting the input or using “alg”: “alg2” (the ECMAScript 5.1 specified
behavior – using the lexically last member with that name). The wording above
doesn’t allow the “alg”: “alg1” result, since it is neither unique or the
lexically last member name. Likewise, for the input
“{“alg”:”alg2”,”alg”:”alg1”}”, only rejecting the input or using “alg”: “alg1”
are legal outcomes. These inputs are not at all equivalent (unless the parser
rejects them both because they have duplicate member names).
ECMAScript doesn’t permit re-emitting the fields in different order, as you
suggest in your comment, since it changes the meaning of the object. With that
being said, do you still perceive that there’s a potential ambiguity that needs
to be clarified?
[JLS] I would note that while ECMAScript 5.1 does not allow this behavior,
there is nothing in the IETF JSON document which has the same restriction.
Mike> Actually, the last sentence of the quoted section above does incorporate
the same restriction into our draft. Only the lexically last duplicate member
name may be returned (if any).
_______________________________________________
jose mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/jose
