Re: JSON Description Language

On 12/06/2011 07:40 PM, Ron Garret wrote:
> Ah.
>
> It is true that DOMCrypt produces and parses data objects in the JSON format.  However, the semantics of these objects is fundamentally different from the kinds of objects that you are dealing with in "your world".  The J in JSON stands for Javascript, and it's there for a reason: JSON is (or at least started out as) a serialization for Javascript objects, and actually for only a subject of possible Javascript objects, specifically strings, numbers, arrays and dictionaries.  There is, for example, no JSON serialization for Dates, Objects, Functions, RegExps, etc. etc.  So, for example, JSON objects do not have a class name because the objects for which they are serializations are not members of classes.  And this would be true even if JSON included serializations for ALL Javascript objects because Javascript's object system is based on prototypes, not classes.
>
> It is possible to layer a class-based object system on top of the Javascript object system.  There are a number of such systems (e.g. http://www.sencha.com/learn/sencha-class-system).  But standardizing that sort of thing seems to me pretty clearly outside the scope of this group.

Again, that work is already being done by JOSE WG for object signing and 
tokens etc. so it is definitely out of scope for us. We will not 
reinvent wheel.  See previous email.
> rg
>
> On Dec 6, 2011, at 12:37 AM, Anders Rundgren wrote:
>
>> Ron,
>>
>> I did the (maybe faulty) assumption that DOMCrypt produced and
>> parsed data objects in the JSON format, just like the following spec:
>>
>> http://tools.ietf.org/id/draft-jones-oauth-jwt-bearer-02.txt
>>
>> In my world all objects have a clearly identifiable class name.
>>
>> If the JS-camp believes that this is only "decoration" they are free to
>> do that.   In my own and rather extensive use of serialized data in both
>> Java and XML, I found it invaluable.  That's all.
>>
>> Anders
>>
>> On 2011-12-06 09:08, Ron Garret wrote:
>>> On Dec 5, 2011, at 7:48 PM, Anders Rundgren wrote:
>>>
>>>> On 2011-12-06 04:31, Ron Garret wrote:
>>>>> On Dec 5, 2011, at 6:51 PM, Anders Rundgren wrote:
>>>>>
>>>>>> The following is related to DOMCrypt and similar...
>>>>>>
>>>>>> http://tools.ietf.org/html/rfc4627
>>>>> It is?  What does JSON have to do with DOMCrypt?
>>>>>
>>>>>> Having a strong background in XML schema authoring I'm slightly
>>>>>> puzzled by the enthusiasm of using "secure" objects that (seem) to
>>>>>> have no notion of explicit (built-in) name-spaces or a description
>>>>>> language.
>>>>> I'm puzzled in what sense you think that JSON is "secure".  The only
>>>>> security claim made for JSON that I know of is that it can be safely
>>>>> parsed by the Javascript eval() function.
>>>>>
>>>>> Can you please clarify why you think this is relevant to this group?
>>>> DOMCrypt parses and generates JSON-formatted objects, right?
>>> I don't know.  This page:
>>>
>>> https://wiki.mozilla.org/Privacy/Features/DOMCryptAPISpec/Latest
>>>
>>> claims to be the latest version of the DOMCrypt spec, but it makes no mention of JSON.  This page:
>>>
>>> http://mozilla.ddahl.com/domcrypt/demos/demo.html
>>>
>>> says "Latest Developments - JSON data persistence for a user's default encryption credentials" but I can't find any more details.
>>>
>>>> I suggested that such objects should have a unique name (space).  It costs
>>>> virtually nothing and would open the door to better language bindings
>>>> and simplified validation.
>>>>
>>>> This need is by no means limited to "security objects" but writing security
>>>> protocols without such mechanisms doesn't IMHO completely feel like 2011.
>>> I'm still confused.  JSON is just a serialization/deserialization standard for numbers, strings, vectors, and associative maps (a.k.a. dictionaries).  What would it even mean for there to be a "namespace" for such a thing?
>>>
>>> rg
>>>
>>>
>

Received on Tuesday, 6 December 2011 18:51:13 UTC