Subject: [woes] Work Done in the OAuth Group

From: Hannes Tschofenig <[email-masked]>
Date: Sun, 20 Feb 2011 10:42:18 +0200

Mike Jones, who is active in the OAuth working group, has worked with others on a specification for JSON security. You can find pointers to various documents in his announcement here: 
http://www.ietf.org/mail-archive/web/oauth/current/msg04912.html

Mike solicited feedback, see for example, and got feedback from the group: 
http://www.ietf.org/mail-archive/web/oauth/current/msg04963.html

When I was asking for running code I got a few quick replies. See, for example, 
* Paul Tarjan's response:
http://www.ietf.org/mail-archive/web/oauth/current/msg04982.html
* Axel Nennker's response:
http://www.ietf.org/mail-archive/web/oauth/current/msg05105.html

Folks in the OAuth WG are pretty fast in writing code (and also in deploying).

JSON is used in OAuth and also in the new version of OpenID (which is based on OAuth). So, the task of providing security for JSON is not academic. 

While it seems trivial for folks to come up with a JSON security specification as well as with the corresponding code there was the question why ASN.1 wasn't used. 

At this point in time I believe it is important to investigate 
a) what the choices are for protecting JSON payload, 
b) what the specific use cases are (the OAuth group has other use cases than the XMPP community, for example)
c) how code can be provided in an easy and not so painful way. 

For (a) I have heard two examples, namely a custom mechanisms in the style of what Mike had proposed and ASN.1. 

Regarding (b) the scenarios point a bit into where should the implication reside,  what are typical programming languages, and who actually needs to do something. 
To illustrate the point, consider for example code running on a Webserver that uses PhP and has to sign a JSON token vs. an example where the JSON signing of a token happens in JavaScript, which is running in the Webbrowser. As an alternative to run JavaScript code in a Webbrowser one could imagine writing a plugin for the browser. This is, however, for many web developers more painful. 
 
Item (c) is important since web developers are typically not willing to wait 5 years for something to be ready. 

Ciao
Hannes