After a long silence this is a catch up on things OAuth-related. Firstly, a follow up to announce that ndg_oauth is now finally moved to PyPI for its first 'official' release. There are separate client and server packages. The latter containing the functionality for both authorisation and resource server:
http://pypi.python.org/pypi/ndg-oauth-client/
http://pypi.python.org/pypi/ndg-oauth-server/
Before any more on that though I should really say something about the recent news with OAuth 2.0, something that colleagues nudged me about. It's disappointing but then maybe signs were there. When I first became familiar with the draft for 2.0, it looked like it would be easier to implement and it would meet a broader set of use cases. Two things appealed particularly: the simplification of the message flow and the use of transport layer instead of message-level security. Having had experience wrestling with different implementations of WS-Security to get them to interoperate and particularly XMLSec digital signature, it was relief to not to have to deal with that in this case. Also, transport layer security is established in Grid security and federated identity worlds and so is a known quantity.
All the same, the reported problems with OAuth 1.0 and signatures seems a little surprising. Consistent canonicalisation of a HTTP header for OAuth 1.0 seems a much easier prospect vs. XML signature. It hardly seems such a difficult requirement to implement. Message level security also provides some protection for the redirects in use: securing at the transport layer will give me secure channels between user agent and authorisation server and user agent and OAuth client but the content can still be tampered in between these interactions at the user agent itself.
Our use of OAuth has definitely been taking it beyond the simple web-based use cases that I've seen for 1.0. When I say 'our' I'm thinking of its application for Contrail and some interest shown by others in the academic research community. In our case, we can exploit version 2.0 to address the multi-hop delegation required to fit together the various actors in the layered architecture for Contrail or it could be applied to manage delegation across multiple organisations in a federated infrastructure like ESGF. These cases need support for non-browser based clients and for actions executed asynchronously, removed from direct user interactions. These are in effect enterprise use cases for the academic communities involved.
As I looked over the draft specification with colleague Richard and he started an implementation it became clear that there was opening of possibilities to support many use cases but with it a concern that when it came to an implementation there were gaps to fill in and choices to be made about how best to implement. It was clear from that it would need careful profiling if it was to be of wider use in our communities but this is familiar ground in geospatial informatics and I'm sure elsewhere to.
A consensus is badly needed but I think that's practicable and can be a process. By making an implementation, and working with other collaborators we are making the first steps towards standardising a version 2.0 profile for use with a Short-Lived Credential Service. This was the original motivating driver - to provide a means for delegation of user X.509 certificates. So returning to the ndg_oauth implementation, it aims to fit this purpose but at the same time provide a baseline of more generic functionality that others can extend and build on. More to follow! ...
