I mentioned this idea back in March when I was working on an early draft of OAuth 2.0. The past few days I've actually started to write a modest proposal. Quoting from http://openidconnect.com/:
Did you know that OpenID was last updated in 2007? Since then we've seen OAuth 1.0 and 2.0. Facebook Connect. OpenSocial. Google FriendConnect. Rich address book APIs. And more recently, Twitter @anywhere.
In 2005 I don't think that Brad Fitzpatrick or I could have imagined how successful OpenID would become. Today there are over 50,000 websites supporting it and that number grows into the millions if you include Google FriendConnect. There are over a billion OpenID enabled URLs and production implementations from the largest companies on the Internet.
But we as a community must be willing to take a step back and realize that there's still a long way to go. The early draft below is meant to inspire and help revitalize the OpenID community. It isn't perfect, but hopefully it's a real starting point. It is designed to be modern, removing support for features which haven't seen adoption and adding support for things like using your email address as your identity.
We've heard loud and clear that sites looking to adopt OpenID want more than just a unique URL; social sites need basic things like your name, photo, and email address. When Joseph Smarr and I built the OpenID/OAuth hybrid we were looking for a way to provide that functionality, but it proved complex to implement. So now there's a simple JSON User Info API similar to those already offered by major social providers.
We have also heard that people want OpenID to be simple. I've heard story after story from developers implementing OpenID 2.0 who don't understand why it is so complex and inevitably forgot to do something. With OpenID Connect, discovery no longer takes over 3,000 lines of PHP to implement correctly. Because it's built on top of OAuth 2.0, the whole spec is fairly short and technology easy to understand. Building on OAuth provides amazing side benefits such as potentially being the first version of OpenID to work natively with desktop applications and even on mobile phones.
Why the name "OpenID Connect"? I'm a geek which means that good branding (or good design) isn't my thing, but Chris Messina (who is good at branding and design) proposed it a few months ago. As Chris said in January, "I want OpenID Connect to be what Facebook and Google and others implement that becomes the interoperable identity interchange protocol for the social web. But we're not quite there yet, though all the technology is on the verge of being...ready." To me, OpenID Connect captures both the product experience and technological evolution. Not to mention that "OpenID 3.0" just sounds like we're trying too hard.
So with that background, I hope you understand where this proposal came from. It was written in just a few days and I am really hoping that by sharing a technical proposal (along with a few bits of code) we can start having an actual conversation about the future of OpenID. Want to discuss it, jump on email@example.com. Or see you in person at the Internet Identity Workshop.
Thanks to a bunch of people who I've talked with about this over the past few months. I really can't claim credit for the idea, just writing down and gluing together good ideas. Specifically I'd like to call out Eran Hammer-Lahav (who actually wrote some of the text!), Allen Tom, Chris Messina, Evan Gilbert, Joseph Smarr, Luke Shepard, and Martin Atkins for their ideas and quick feedback!
Why can't I set a preference on my credit card which tells the store's computer to not print a receipt if the purchase is under X dollars? Or why not have my credit card give the store my email address so that they can send me a PDF – like Apple does – instead? Or if the store doesn't want to deal with emailing customers, how about a way for them to send my purchase details to my credit card company instead?
Is anyone working on this sort of thing?
Over the weekend I took a quick stab at what a new draft of an OAuth 2.0 spec would look like. I don't have a lot of normative text but wanted to share what I was thinking about in terms of the specification's structure and technical inner-workings.
This comes out of the survey from two weeks ago which Peter Saint-Andre summarized as there being consensus around:
- OAuth 2.0 taking aspects from both the 1.0 and WRAP specs/drafts with a preference toward the WRAP draft
- we should go back to working on a single document
- OAuth 2.0 should support signatures as a mechanism for making requests
- OAuth 1.0: http://tools.ietf.org/html/draft-hammer-o
- WRAP: http://tools.ietf.org/html/draft-hardt-o
Combined document structure:
My goal is that sections one through four are not more than fifteen to twenty pages combined.
1.3 Notational Conventions
2. Getting an Access Token
2.2 Rich App Profile (can open a browser)
2.3 Device Profile (no browser, should be like the Netflix flow)
2.4 Username and Password Profile
2.5 Client key and secret (not in the context of a user)
3. Refreshing an Access Token
4. Accessing a Protected Resource
4.1 Using SSL
4.2 Using a signature
5. Security Considerations
OAuth 2.0 provides a method for an application (Client) to access the Protected Resource hosted on a server on behalf of a Resource Owner (such as a different client or an end-user). It provides a process for end-users to authorize third-party access to their Protected Resources via a variety of Authorization Profiles which generally do not include having to share their credentials (typically, a username and password pair). A server can additionally delegate authorization to one or more authorities (Authorization Server) which issue Access Tokens to Clients.
- This section should provide a longer description of the protocol flows and the evolution from OAuth 1.0.
- The terminology should be based on updated OAuth 1.0 terminology which is already close to the WRAP terminology as well. We should err on the side of more generally understood terms.
- Both OAuth 1.0 and WRAP contain fairly complete introductory sections. I think that the WRAP one is a bit too long and we should shoot for this section being a little over two pages (including terminology).
Getting an Access Token
- This section really comes from WRAP. I believe that a server MUST implement at least one of the profiles to be considered OAuth compatible.
- While the SAML assertion profile has been in WRAP, I haven't seen strong advocates on the mailing list or in the survey for it. Does someone want to argue for keeping it? Could it be drafted as a separate profile from the core spec?
Refreshing an Access Token
- In WRAP this functionality is described along with each individual authorization profile. Some profiles require the client id and secret though not all of them. In terms of writing more reusable code I imagine that implementors will write a single refresh_token(client_id, client_secret) function so breaking this out into its own section will be easier to implement. We could either require the client id and secret for all profiles or keep them as optional for some profiles. Personally I lean toward consistency.
Accessing a Protected Resource
- This section is really a combination of WRAP and OAuth 1.0. SSL support will be a MUST and signatures will be optional.
- Bearer tokens (even short lived) without using SSL or signatures feels like a poor idea, but given the WRAP draft it seems like the security teams at Google, Microsoft and Yahoo! are all comfortable with doing so? Given that we'll be adding signatures as an option do we still need unprotected bearer tokens?
- The SSL section basically copies directly from WRAP section #4. It's about a page and a half and really easy to implement.
- We need to agree on the signature method though there is a lot of normative text in the OAuth 1.0 spec to draw from. OAuth 1.0 is about three pages of text assuming people are happy with the mechanism; it would be good to simplify as much as possible.
- We're missing an access token secret, but I'm wondering if we can treat the refresh token as the access token secret since it's only sent over the wire via SSL?
- Alternatively we could modify the refresh token request to let the client specify that they'd also like an access token secret for that request. This seems like the right way of doing it.
- Both break the idea that the API endpoint doesn't have access to secrets, but the deployment scenarios I've seen discussed as wanting signatures (at least Facebook and Twitter) won't be separating their architecture anyway.
- I'm the wrong person to write this section.
- Rename parameters to oauth_
If I were to spend some time over the next week or two drafting this spec would folks generally be supportive of it? If not, what would you change so that you could be supportive of it?
One of my goals is getting OAuth 2.0 to the point – fairly quickly – where we can start to architect the next version of OpenID on top of it. WebFinger + OAuth 2.0 + identity would be sweet and finally give us a consistent story for both authentication and authorization. I'd love whatever help I could get with all of this as well!
Cross posted to the OAuth IETF mailing list
I wish more people understood this fact.
I sold my Subaru about nine months ago since I wasn't driving much in San Francisco. I lived an easy fifteen minute walk from work, fifteen minute cab ride from the airport, have multiple Muni lines/trains two blocks from where I live, and about a half-dozen ZipCars along my block. Working in the Valley now means that I'm commuting fifty miles each way every day, generally via CalTrain. I figured that I'd buy a car within weeks, but now three months later I'm still without a car.
For the past few months I've thought that I would buy a BMW 1 Series. It's a small two door sports car, has only been in the USA for about a year, and I'm still a bit sad that I sold my first BMW.
This weekend I drove a few cars. Started with an Audi S4 Cabriolet and then a S5 Coupe. Both felt great and were a bunch of fun. Sadly going from a 4.2L V8 to a 3.0L twin-turbo inline-6 made the BMW feel quite weak. Even in sport mode, it didn't have the sort of "go" as the Audi.
I want to love the BMW but it's just not as much car for the same price (which is extreme to begin with). Or should I just wait for a Chevy Volt? :)
Two years ago when I re-joined Six Apart, I did so out of an interest in evolving social networking technologies along with brad and we – along with many others – have made an amazing amount of progress. This was my second time working at Six Apart and I'm sad to leave; they're a great bunch of people with some awesome stuff coming.
This past year as I've worked closer with teams at Facebook, I've been impressed by their products, smart people, and innovation. I hope to continue building on my past experience in working on making the web more open and useful for everyone along with the great team at Facebook!
I Dig It - Another iPhone game which is quite addicting until you run out of missions. You run a "digger" machine and go mining under a farm for jewels, fossils, gems, etc in order to raise money to save the farm. You have to spend money to upgrade your digger to go deeper, hold more cargo, have more gas, etc and complete your mission goal before time runs out. Some missions include finding things underground versus a specific monetary goal.
The first Community Leadership Summit - Jono Bacon, Canonical's community manager for Ubuntu around the World, organized an unconference style event the weekend before OSCON to bring together people who work with various open source and related communities. I went Saturday and really enjoyed the series of discussions that I participated in. They ranged from how to be successful at marketing open source style projects, to building healthy open communities, to how open source projects live or die through acquisitions. If Jono organizes this event again next year, it is definitely worth checking out.
Roast Chicken - I was out in New York a few weeks ago having dinner with Anil and Alaina when we started talking about easy things to cook at home. They both suggested roast chicken and were right! The first one turned out great and I made a second last night – less lemon and more garlic – which is even jucier! Chicken, butter, garlic, lemon, salt, pepper, oil, an oven and an hour is all it takes.
And of course, OpenID continues to rock! (though Google News keeps including articles that mention "OpenID" as one of the log in methods which is really annoying since the articles aren't actually about OpenID)
“We’re constantly looking for ways to stay innovative in our online initiatives by identifying and implementing technologies that help our users navigate our communities with ease,” says Rob Harles, Sears’ vice president of community. “Our adoption of the OpenID technology helps simplify our customers’ online experience and ultimately helps us meet our goal of ensuring our customers have the most efficient shopping experience possible.”
Given how quickly the Social Web is coming together, I believe that HTML will need to support social elements someday soon. It's great to see this type of innovation by Facebook running in the wild, but the web itself ultimately evolves best when multiple competing approaches come together. Just as OAuth brought together the best practices from AOL, Flickr, Google, Yahoo! and others, there is a similar opportunity to bring together FBML, YML and OSML along with the client-side benefits of XFBML.Read more...