Re: JSON Description Language

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 08:38:39 UTC