Da Capo: JSON "clear text" signatures

[Anders Rundgren]

On 2018-01-29 16:47, Hannes Wallnöfer wrote:
> Thanks for the clarification, Anders.
> 
> If you are working from Nashorn, the simplest way to enforce JS formatting is to coerce the Java number (whatever type it is) to a JS number, e.g. using unary + operator.
> 
> If you need this in Java core libs, the place to discuss this would  be the core-libs-dev mailing list rather than nashorn-dev, but I think the chances to get such specialised functionality to core libs would be very slim.

Well the JSON java guys have to duplicate serialization not only of numbers but of strings so it appears to be on the same level as Base64 support which made it to JDK 8:
https://docs.oracle.com/javase/8/docs/api/index.html?java/util/Base64.html

Anders



> 
> Hannes
> 
>> Am 29.01.2018 um 15:46 schrieb Anders Rundgren <anders.rundgren.net at gmail.com>:
>>
>> On 2018-01-29 15:49, Sundararajan Athijegannathan wrote:
>>> Just to be clear. so.. do you want a toString (static method?) variant
>>> in java.lang.Double class as per this specification?
>>
>> I don't think this is a major issue because all fundamental JSON types anyway needs be dealt with separately or through a super interface.
>> The existing Nashorn method (after upgrade to match ES better) moved to the Java layer would probably be just fine.
>>
>> Anders
>>
>>> -Sundar
>>> On 29/01/18, 7:45 PM, Anders Rundgren wrote:
>>>> On 2018-01-29 14:52, Hannes Wallnöfer wrote:
>>>>> Hi Anders,
>>>>>
>>>>> I think I lack the context required to understand what you’re asking
>>>>> for. Can you explain how transmitting numbers/doubles in JSON should
>>>>> work and how the static method you’re asking for would enable this?
>>>>
>>>> Sure.  Signatures depend on that data appears identical on both sides
>>>> (sender + receiver).
>>>> If one side outputs the integer 10 as 10.0 (which is OK JSON-wise),
>>>> the signature will break in an EcmaScript environment where it must be
>>>> 10 and nothing else.
>>>> JSON tools would call the proposed static method rather than building
>>>> their own number serializer.
>>>>
>>>> Initially I thought number serialization was a simple problem but that
>>>> was entirely wrong :-)
>>>> Fortunately the ECMA folks have the expertize needed and their
>>>> solution is already supported in billions of devices.
>>>> Nashorn almost cuts it but only for JavaScript, not Java.
>>>>
>>>>> Also, is there a document somewhere describing the IETF
>>>>> standardization work you’re talking about?
>>>>
>>>> You will have to wait to next week (when it becomes public), but in
>>>> the meantime you can take a look at the core "input specifications":
>>>> https://cyberphone.github.io/doc/security/jose-jcs.html
>>>> https://cyberphone.github.io/doc/security/jose-jef.html
>>>>
>>>> Thanx,
>>>> Anders
>>>>
>>>>>
>>>>> Thanks,
>>>>> Hannes
>>>>>
>>>>>> Am 28.01.2018 um 10:48 schrieb Anders Rundgren
>>>>>> <anders.rundgren.net at gmail.com>:
>>>>>>
>>>>>> The JSON "clear text" signature initiative seems to (finally) be
>>>>>> headed for IETF standardization.  The plan is having a BOF session
>>>>>> at the next IETF in London.
>>>>>>
>>>>>> This scheme builds on EcmaScript JSON processing rules for data
>>>>>> normalization which only rely on JSON.parse() and JSON.stringify().
>>>>>>
>>>>>> A thorny issue for implementers is though serializing the JSON
>>>>>> "Number" type.
>>>>>>
>>>>>> An with Node.js, Chrome, Firefox, Safari (unfortunately not entirely
>>>>>> compatible...) solution is currently available in "Nashorn":
>>>>>> http://hg.openjdk.java.net/jdk8/jdk8/nashorn/file/096dc407d310/src/jdk/nashorn/internal/objects/NativeNumber.java
>>>>>>
>>>>>>
>>>>>> It would be great if such support could for example be included as a
>>>>>> static method in java.lang.Double, making Java and
>>>>>> EcmaScript/JavaScript 100% interoperable with respect to this
>>>>>> feature, the rest is actually close to trivial.
>>>>>>
>>>>>> thanx,
>>>>>> Anders
>>>>>> https://github.com/OAI/OpenAPI-Specification/issues/1464#issue-291622705
>>>>>>
>>>>>
>>>>
>>
>