Re: [jose] #27: member names MUST be unique needs additional text

["Manger, James H" <[e-mail]>]

> > each recipient MUST either reject messages with duplicate names or
> accept only the last name.
> 
> Maybe only gatekeeper functions need validating parsers?

Doubt it. How can a JOSE library tell if it will ever be used by a gateway... better treat all libraries as potential gateways.

> gatekeeper function: A processing step that derives (makes/validates)
> an assertion from a JOSE object and then moves forward that JOSE object
> unchanged to the next processing step (e.g., to preserve a
> signature)
> 
> validating parser: A JSON parser that rejects JSON that might be
> interpreted differently by another JSON parser

But now a validating parser MUST reject dupes, as others might interpret them differently, so the validating parser cannot be built from many standard JSON libraries.

> Are we sure that the duplicate key issue is the only one that needs to
> be checked by a validating parser?  A number of candidate issues:
> 
> http://www.ietf.org/mail-archive/web/json/current/msg01068.html
> 
> E.g., what about issue 3.8?  If a gatekeeper function derives an
> asssertion about a JOSE object mentioning twitter ID
> 10765432100123456789, but the next step thinks it is about
> 10765432100123458000?
>
> https://dev.twitter.com/docs/twitter-ids-json-and-snowflake

That would be a problem, but one for the app using JOSE to fix, not JOSE itself. I don't think any JOSE fields use JSON numbers as integers; and if they did the JOSE spec should add a "MUST be under 2^53" rule. At least in this case it is clearer what is at fault.

> The list in msg01068 also is not complete for our purposes, e.g., it
> mentions normalization issues only in passing.  A validating parser
> sure wants to reject anything that isn't already normalized Unicode.

Not sure if that is a problem. JOSE might avoid those issues (almost by accident) by only defining field names that use ASCII letters. If it turns out that a bunch of JSON parsers "legitimately" accept {"alg":"ABC","\u24D0\u24DB\u24D6":"XYZ"} as having an "alg" value of XYZ (due to some normalization) we would need to amend JOSE to explicitly forbid it. I doubt that isn't necessary.

["\u24D0\u24DB\u24D6" = "ⓐⓛⓖ"]

> Maybe gatekeeper functions are not such a bright idea?

They are everywhere. Firewalls, proxies, WAFs, gateways; any tiered architecture... 
Gateways are fine. Potentially ambiguous messages are the idea that is not so bright. 

It is not just "inline" gateways. You don't want your audit tool, or support tool, that might look at messages after they have been processed to see a different interpretation. You don't want a court disagreeing about a message years later.

--
James Manger