[OAUTH-WG] XML Encoding

Justin Richer <jricher@mitre.org> Mon, 27 September 2010 19:36 UTC

Return-Path: <jricher@mitre.org>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 144193A6DA1 for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 12:36:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.494
X-Spam-Level:
X-Spam-Status: No, score=-6.494 tagged_above=-999 required=5 tests=[AWL=0.105, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id b3rsW+LnrhCV for <oauth@core3.amsl.com>; Mon, 27 Sep 2010 12:36:06 -0700 (PDT)
Received: from smtp-bedford.mitre.org (smtp-bedford.mitre.org [129.83.20.191]) by core3.amsl.com (Postfix) with ESMTP id 246723A6DA8 for <oauth@ietf.org>; Mon, 27 Sep 2010 12:36:05 -0700 (PDT)
Received: from smtp-bedford.mitre.org (localhost.localdomain [127.0.0.1]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o8RJai6Z017121 for <oauth@ietf.org>; Mon, 27 Sep 2010 15:36:44 -0400
Received: from imchub1.MITRE.ORG (imchub1.mitre.org [129.83.29.73]) by smtp-bedford.mitre.org (8.13.1/8.13.1) with ESMTP id o8RJahn6017118 for <oauth@ietf.org>; Mon, 27 Sep 2010 15:36:43 -0400
Received: from [129.83.50.65] (129.83.50.65) by imchub1.MITRE.ORG (129.83.29.73) with Microsoft SMTP Server id 8.2.254.0; Mon, 27 Sep 2010 15:36:43 -0400
From: Justin Richer <jricher@mitre.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Content-Type: text/plain; charset="UTF-8"
Date: Mon, 27 Sep 2010 15:36:43 -0400
Message-ID: <1285616203.15179.204.camel@localhost.localdomain>
MIME-Version: 1.0
X-Mailer: Evolution 2.28.3
Content-Transfer-Encoding: 7bit
Subject: [OAUTH-WG] XML Encoding
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 27 Sep 2010 19:36:08 -0000

I've got XML-based protocols here that we want to protect with OAuth,
and so having to deal with a JSON blob is less than optimal for us. Ages
ago, we decided to make JSON be the One True Encoding for the core spec,
and I commented that I was fine with that if we had a way to represent
things in other encodings in an appropriate way. 

In spite of the recent flurry of activity over signatures, I want to
dust this one off. There are a few ways one can translate JSON to XML or
vice versa; over the weekend, I came across this interesting article:

http://answers.oreilly.com/topic/279-how-to-convert-json-to-xml-in-java/

And while it doesn't seem to have any specification guiding it (that I
could find), it does have what I consider to be a reasonable way to
represent the JSON objects as XML documents using a few simple rules
that I could distill from this software's behavior. This is all pretty
close to what I was thinking of proposing anyway, but if there's an
existing spec/draft out there for this, someone please point me to it.

0) No namespacing (as in JSON)
1) All objects are element nodes at the root of a tree or subtree
2) All members of an object are sub-element nodes of the object element,
with the name of the member as the node name
3) Strings and numbers values are encoded as CDATA within a an element
4) Members have an optional "type" attribute to help differentiate
strings and numbers
5) Lists are represented by repeated elements with the list name, as
available, with each member of the list as one repeated instance and
list order being preserved by document order

There are a couple things missing to make it really useful for us.
First, "default" naming scheme for anonymous objects and lists as
allowed by JSON. In particular, the root node needs a name, though we
could easily use "oauth" here and call it a day. If extensions start
making use of list and object parameter values, then we get into
trouble. So far, we haven't really seen anyone doing that yet. Second,
having some kind of "implied namespace" at the root would be helpful in
letting this XML blob play along nicely with other XML blobs -- but I'm
certainly happy to punt on that issue.

If there's interest in this, and it hasn't already been covered in
another draft we can just profile, I'm willing to start work on a draft
myself here and present it to the WG as an item. I'm also looking for
any co-conspirators who are crufty enough to still be using XML.

 -- Justin