Life, Identity and Everything – a chat with Tim Bray and Breno de Madeiros from Google

Last night I took part in the Life, Identity, and Everything Google developer chat with Tim Bray and Breno de Madeiros.

Tim Bray is the Developer Advocate, and Breno de Madeiros is the tech lead, in the group at Google that does authentication and authorization APIs; specifically, those involving OAuth and OpenID. Breno also has his name on the front of a few of the OAuth RFCs. We’re going to talk for a VERY few (less than 10) minutes on why OAuth is a good idea, and a couple of things we’re working on right now to help do away with passwords. After that, ask us anything.

Here is the video of the chat:

To summarise the event they said that Google are committed to OAuth 2.0 and OpenID. They intend on all Google APIs supporting OAuth 2.0 and they believe it has helped developers develop for Android because support for the OAuth dance is baked into the Android APIs making it very simple to integrate with it.

They also feel that Mozilla Persona is a promising (but complicated) protocol; however they feel that on mobile devices it will cause problems in terms of the user flow.

I asked two questions which Tim and Breno answered:

”What do you think the future of OAuth is? Eran Hammer publicly quit as the editor and claiming the v2.0 specification is “more complex, less interoperable, less useful, more incomplete, and most importantly, less secure”. Will there be OAuth 3?”

and

“Could a ./well-known/oauth file published at each providers endpoint help with interoperability? This file would describe their implementation responds with json or text, which grants are supported, etc”

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.

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.