From: Mike Jones [mailto:[email protected]] Sent: Thursday, May 22, 2014 12:52 AM To: Jim Schaad; 'Kathleen Moriarty' Cc: [email protected] Subject: RE: [jose] AD review of JWS draft 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). [JLS] Yes – that is what you have as a restriction for the JOSE documents. What about a middleware piece of software?
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
