David Recordon

OpenID: technology or a movement?

There's been an interesting discussion on the OpenID mailing lists the past few days stemming from my post Seven sites you didn’t know were using OpenID. The main argument is that because many of these sites aren't letting people use any OpenID, that we shouldn't be promoting them. To me this stems from a deeper question about what OpenID actually is.

On one hand OpenID is clearly a technology. Created in 2005, OpenID 1.1 allowed for basic authentication of people who were represented by profile URLs across the web. But OpenID 2.0 is a pretty different technological beast. It supported both URLs and XRIs which made discovery overly complex, features such as clicking a button to sign in versus typing a full URL, and was designed to be extensible which led to richer profile data and stronger authentication. Today OpenID 2.0 is most widely used – if we look at monthly active users – in conjunction with OAuth 1.0. This is via a bit of a hack Joseph Smarr and I originally created back in 2008 which grafted the two technologies together.

In my mind this evolution clearly means that OpenID is more than a given piece of technology. Over the past five years the community has been willing to evolve it to solve new problems, as we're now starting to do with OpenID Connect.

The challenge with OpenID being a true movement is the need for the community to become evangelical. Supporters of the Free Software movement will at times criticize those who choose licenses other than the GPL which causes them to lose sight of the fact that more open source is actually a good thing overall. OpenID as a technology has never tried to directly address the question of trust. It has always allowed for servers to whitelist and blacklist clients and clients to whitelist and blacklist servers. This is one of the major reasons why OpenID has grown into enterprise and government markets; it didn't try to force a specific trust model, unlike previous technologies.

I am excited to see Kodak support sign in using Facebook (OAuth 2.0 + custom bits), Google (OpenID 2.0 + OAuth 1.0), MySpace (OpenID 2.0 + OAuth 1.0), Twitter (OAuth 1.0 + custom bits), Windows Live ID (fully custom), and Yahoo! (OpenID 2.0 + OAuth 1.0) because on one hand that means we've won. We've finally convinced businesses – which serve normal people – that having their users sign in with existing accounts is better. Do I wish that I could sign in using my own OpenID, absolutely! But I also realize that the "type in your OpenID URL" experience isn't one that Kodak's users will ever understand. If I were building a mass market site today, I'd do the exact same thing.

This is why user experience work around OpenID Connect is vitally important. Clicking buttons of recognizable brands works today, but having true choice of any OpenID server is still ultimately the way forward.

In true Simon Willison style

The past twenty days have been a real whirlwind in terms of new sites adopting OpenID for sign in. Some of the larger deployments have made the news (Google and Yahoo! Store), but here are seven others you’ve likely not heard about.

— OpenID Blog

The three types of OpenID Connect identifiers

One of OpenID's innovations was the idea of every user being represented by a URL. This immediately made the protocol decentralized and helped to provide context for every user across the web. What become clear to me over the past few months is that while this was an important step forward, there are actually three different types of identifiers that are necessary.

OpenID 2.0 has tension between the identifier being secure and globally unique, memorable, and human friendly. OpenID Connect must split them apart.

1) Identify the provider. Much of the recent work around WebFinger is based on the idea that people more commonly identify with email addresses than URLs. From an OpenID perspective, the most important part of `recordond@gmail.com` is that it tells a site that my identity is hosted on gmail.com. The same holds true for `davidrecordon.com` or just clicking a Facebook button.

2) Identify the user. In order for OpenID Connect to be secure, user identifiers must be HTTPS URLs and never recycled. This type of identifier does not need to be human friendly and ideally will never be shown to the user. It is the basis of all identity assertions and is ultimately the unique identifier of the OpenID account. It is easy to never recycle these URLs because they are not human friendly and thus don't take up the valuable part of a service provider's namespace.

3) Link to the user's profile. OpenID 1.0 was originally designed in an environment where the OpenID URL was also a homepage or a blog. It's clear that the profile URL is an important part of online identity, but should be separated from the underlying user identifier. There are times when the profile URL will also be used to identify the provider, but I think that the vast majority of users will instead enter an email address to sign in.

Facebook, Google, and others already have these three different types of identifiers today. For example, I click a button to sign in using my Facebook account, my user identifier is `https://graph.facebook.com/24400320`, and my profile URL is `http://www.facebook.com/davidrecordon`. Or I enter `recordond@gmail.com` which uses Google's provider, my user identifier is `https://www.google.com/accounts/o8/id?id=AItOawmP6awF76I-CromhOw__yakkw0SCM6nzjM&h=aaaa8`, and my profile URL is `http://www.google.com/profiles/recordond`.

Thoughts?

I normally think that GoDaddy is out to scam me in any way possible, but this is the most clear communication about a terms of service change that I've ever received!

Standards are best served second

I'm up in Portland today at the first Federated Social Web Summit and there have been a number of interesting presentations about open source projects trying to build interoperable social experiences. The morning has also been fairly packed with emerging technology buzzword bingo. At times it felt as if people were starting with the technologies and protocols and only then trying to find a product that needs PubSubHubbub enabled JSON hCards federated via OStatus! 

The Diaspora talk jumped out to me as they twice said, "we've implemented this product feature as a prototype, it works, and now we want to talk about the standard version of it." That's the right way to build standards. Have a product problem, solve it, and then iterate with others on an open specification.

But most importantly, don't be afraid of starting over (while learning from the past). We wouldn't have OpenID if we stopped when we were told that SAML already solved the problem. Wouldn't have OAuth 2.0 if we stopped when we were told that Kerberos already solved the problem. Wouldn't have Microformats if we stopped when we were told that RDF already solved the problem.

So yes, try to build on Activity Streams, PubSubHubbub, Salmon, OStatus, and WebFinger but don't be afraid to rip them apart as needed if you'll end up with a better product, a better technology, and ultimately a better standard. We did this recently with OAuth 2.0 and the internet is better for it. And don't forget that you need to solve a problem that people care about.

What is HTML5?

Earlier this weekend, Christopher Blizzard wrote about how there's not one easy answer as to what HTML5 actually is. While I don't agree with placing all of the blame on Google, I certainly agree that there needs to be a simple answer as to what, "support HTML5!" means. Not just for browser vendors, but for website owners as well.

<rant>At Google I/O in 2009, it seemed like HTML5 meant canvas, video, geolocation, app cache, local storage, and web workers. (See http://radar.oreilly.com/2009/05/google-bets-big-on-html-5.html.)

But then The HTML5 Test also includes a variety of new markup (such as form controls) and multiple different ways to store and cache data within the browser.

While Mozilla supports the geolocation API, they don't mention it on their What is HTML5? page.

If you go to the W3C you get the HTML5 specification which is 676 pages of printed HTML. Wanting to build a geo app, I search the spec for geolocation but don't find any mention of it. The first result on Google for "gelocation API" is the old Google Gears API. The Geolocation API Specification turns out to be a separate spec which doesn't contain "HTML5" in the title at all.

I've heard about WebSockets as being the way to replace traditional long polling, but the HTML5 spec doesn't seem mention it either. So I Google "web sockets" and find out that the WebSockets API is being standardized by the W3C while the WebSockets Protocol is being standardized by the IETF.

At this point I figure that maybe the W3C will have a good answer as to what HTML5 actually is. A few clicks later and I'm on the HTML Current Status page. The first three things it tells me about are RDFa, XHTML-Basic, and XHTML-Print. No luck.

I now head over to the W3C's HTML Working Group page but it still only talks about the main HTML5 specification. Digging some more I find a W3C presentation which says that the next open web platform is dozens of specifications!</rant>

While treating HTML5 as a broad umbrella brand helps everyone feel like there's a chance to have their problem solved as a part of it, website owners aren't clear on what's worth shipping when. As an outsider it feels like having a simple "implement this stuff to make your website support HTML5" page based on what non-beta versions of browsers have shipped would be incredibly useful.

Is there a reason the W3C isn't doing this? Or am I just missing something?

Thinking about how to rebuild OpenID on top of OAuth 2.0

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 specs@openid.net. 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!

(Original comments at http://daveman692.livejournal.com/349750.html.)

I'm tired of paper receipts

How do we move away from every store giving you a piece of paper to stick in your wallet as a receipt? I generally don't read them and if I'm expensing something then I need to digitize the paper anyway.

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?

(Original comments at http://daveman692.livejournal.com/349621.html.)

Working toward an initial draft of OAuth 2.0

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

Documents involved:

1. OAuth 1.0: http://tools.ietf.org/html/draft-hammer-oauth-10
2. WRAP: http://tools.ietf.org/html/draft-hardt-oauth-01

Combined document structure:

My goal is that sections one through four are not more than fifteen to twenty pages combined.

0. Abstract

1. Introduction
1.1 Acknowledgments
1.2 Terminology
1.3 Notational Conventions

2. Getting an Access Token
2.1 Web App / JavaScript Profile (in browser)
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

Abstract

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.

Introduction

• 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.
• The updated OAuth 1.0 spec could also be useful for more complete language around the Web App Profile though we should also draw from Luke Shepard's JavaScript profile (which needs updating). I believe the main difference is the security characteristics.
• 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.

Security Considerations

• I'm the wrong person to write this section.

Misc

• 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

(Original comments at http://daveman692.livejournal.com/349384.html.)

Yes, faxes are dead

I wish more people understood this fact.

(Original comments at http://daveman692.livejournal.com/349183.html.)