Upcoming identity work from Google announcement

Tim Bray, a developer at Google who I disagreed with in a previous post has just posted on his blog that the team he is currently working in is going to shortly be announcing some of their early work and thinkings soon.

He says problems they’ve identified and they want to try and solve include:

  • The username/password dance sucks and doesn’t scale, particularly on mobile.
  • People putting up apps and sites regard identity — getting people signed up & signed in — purely as a tax; something they gotta do, but unrelated to what they care about.
  • Most developers don’t understand identity standards like OAuth, or the related crypto and signing technologies, don’t want to learn them, and shouldn’t have to.
  • If you can get new arrivals signed up quicker with less work, that’s a good thing.
  • If you can get people you know signed in quicker, ideally with one click, that’s a good thing.
  • People are paranoid and really don’t want to be in the headlines for next week’s embarrassing password leak.
  • People don’t want to think about privacy and tracking and transparency, but the risk of not doing so (just) exceeds the pain.
  • People like the notion of outsourcing the icky identity work, but are nervous about putting all their eggs in the Facebook’s or Google’s or Yahoo’s or whoever’s basket.
  • On the other hand, having a cluster of Sign in with… buttons on your landing page dilutes your brand and feels like watching NASCAR on TV.

I’m looking forward to seeing what they come up with.

Linkey Project Status Update 1

We’re now a quarter of the way through the Linkey project calendar so I’m going to try and summarise where we are at and where the project is heading.

I’ve spent a considerable amount of time working away on the OAuth PHP library which features code to build an authorisation platform, a resource server, and an abstract client class so that you can easily interact with 3rd party OAuth endpoints.

With this code almost finished and tested I’ve started designing the next generation OAuth endpoint for use here at the university. Coupled with the work we’re doing on the side for our next generation API and open data platform, as well as ICT’s own enterprise service bus and UAG development all together we’re developing a beautiful data driven environment that will allow us to go forth and build rich, personalised and secure services and applications.

My colleagues here in ICT have been testing the UAG on our development network over the past few months and they now feel comfortable to start building a production platform which we can start integrating services into. This will hopefully be ready in the next few weeks and I will be able to go into much more detail about how OAuth and UAG can work together.

The main clients for Linkey are the university library and they have already started reaping some of the benefits of a single sign on environment thanks to an installation of EZProxy which offers reverse proxy authentication to a large number of 3rd party journal and database services. Currently EZProxy is piggybacking off of our Blackboard installation for authentication which benefits students – we know from our analytics that most students access library services through Blackboard – because there are now 35 (at the time of writing) resources which they can access with one click and they won’t have to authenticate a second (or in some cases a third) time.

With a production UAG we should be able to hook up a large percentage of sites and services with relative ease. As a refresher here is the current authentication situation:


and here is the ideal situation which we should be able to achieve:


Over the next 9 months there are a few other areas of access and identity which I want to cover.

At EduServ’s Federated Access Management conference last year there was a talk by Jonathon Richardson, assistant CIS director at the University of East Anglia where he discussed how students and staff can access some of his institutions’ services with their own 3rd party Internet services accounts (e.g. Facebook/Twitter/Google). I would like to look into what are the benefits and risks associated with allowing staff and students to access university resources with their own accounts instead of the brand new account which they are given by us when they start at the university.

Hopefully the OAuth 2.0 specification will also be completed very soon and I want to further investigate OAuth’s potential use cases. I have submitted a conference talk proposal to ConFoo in Montreal, Canada to discuss my findings.

We have also committed to publishing a case study and organising a workshop about OAuth (and access and identity in general) which we will work with JISC to organise and promote.

Update w/c 13th August

I’ve not blogged in a few weeks so I’m just going to give a quick update on what I’m working on.

First of all, I’ve finished porting my old CodeIgniter based OAuth server code to a composer library. It follows the latest version of the specification (draft 31) and supports the authorisation code and implicit grants. I’ve also started work on some unit tests to ensure that the code is bulletproof. There is a small bit more work to do to support the client resource owner password credentials grant and the client credentials grant. Once I’ve completed this work and finish the unit tests (I’m currently at about 60% code coverage) I’ll make a formal announcement on this blog, to the OAuth working group mailing list and to the PHP community.

I’ve been working with Paul Stainthorp in the library to capture examples of poor user experience when accessing electronic resources in the library. I’ve made videos showing how difficult some resources are to access, and I’ve also been going through recent NSS and level 1 and 2 surveys to find examples of students highlighting problems they’ve had accessing the resources.

Plan for w/c 09/07/12

The plan for this week (w/c 09/07/12) is as follows:

  • Continue re-architecting my original OAuth server code into a composer library that is framework agnostic – the code is available at https://github.com/lncd/oauth2server/tree/develop.
  • Meet with Paul Stainthorp to understand (and watch) the difficulties user face access library resources.
  • Following the above, capture videos and screenshots of users accessing library resources so we can hopefully show at the end of the project how things have improved.
  • Write a blog post entitled “What is OAuth?”
  • Response to Tim Bray’s blog post on “OAuth 2 and friends, is way too hard for developers” to show how easy OAuth 2 actually is compared to OAuth 1.0a.
  • Announce the Linkey project on the OAuth mailing list.
  • Finish the project plan for JISC.