W3C home > Mailing lists > Public > public-identity@w3.org > December 2011

Re: JSON Description Language

From: Richard L. Barnes <rbarnes@bbn.com>
Date: Mon, 5 Dec 2011 22:18:57 -0500
Cc: "public-identity@w3.org" <public-identity@w3.org>
Message-Id: <47DD187D-A492-4539-9DAA-EF50E6273A01@bbn.com>
To: Anders Rundgren <anders.rundgren@telia.com>
> 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.
> 
> Lets say that you have a system that accepts a certain set of
> different objects.  How can you tell the difference between
> them without writing some kind of "content sniffer"?

There has been some work proposed in the IETF that would create a schema for JSON.
<http://tools.ietf.org/html/draft-zyp-json-schema-03>

But isn't XML schema validation basically "content sniffing" anyway?  You go through and check that all the right stuff is present.  The only think you lose by not having a schema language is that you have to write the definitions in human language and generate the parser by hand.  Like we do for, say, IP or TCP.


> How can you deal with JSON objects in Java?  It seems that you
> only get an "Object" and then have to explicitly cast that
> based on knowledge of the data structure.

It's slightly more advanced than that.  For example, in the json.org API, you don't get an "Object" in the sense of a Java Object on which you have to do introspection.  You get a JSONObject object with methods that tell you what's in the object.
<http://json.org/java/>


> If I were into the JOSE stuff, I would consider adding a mandatory
> name-space to all container objects which would open the door
> to automatic generation of proxy objects and data validation.
> There's no imminent need to agree on a JSON DL at this stage.

Maybe I'm misunderstanding the question, but in JOSE, there's not a need to separate container from content with a namespace.  JOSE is designed to protect arbitrary octet strings, so those data will just look like opaque octets from the perspective of JOSE processing.  Whereas the container will be JSON.  (Same as in CMS.)  

For the same reason, I'm not sure what you mean by "data validation".  If the octets you're carrying are just octets (and not JSON, XML, DER, etc.), then what would you validate?  If you're worried about integrity, that's what MACs are for; if you're worried about the validity of the container, you can do that at the JSON layer (without a schema, as above).

But feel free to send comments to the JOSE list.  It's completely open, and it's been pretty quiet lately.
<https://www.ietf.org/mailman/listinfo/jose>

--Richard
Received on Tuesday, 6 December 2011 03:19:26 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 6 December 2011 03:19:26 GMT