Home - Stay N Alive

The Future Has No Log In Button

Posted on November 25, 2009 by jessestay

Since last week’s Kynetx Impact Conference I have gained an entirely new vision for the open web. I now foresee a web which the user completely controls, lives in the browser, syncs with the cloud, and has no boundaries. This new web completely makes the entire Social and Real-time paradigms miniscule in terms of significance. What I see is an internet that, regardless of what website you visit, you will never have to enter your login credentials again. I see the end of the log in button.

It all centers around identity. The idea comes with a technology called Information Cards, and a term called the “Selector”. With these technologies, websites will rely on the client to automatically provide the experience you want without need for you to log in ever again. It relies on OpenID, doesn’t really need oAuth (since all the authorization ought to happen on the client), but the best part is you, the user, don’t ever have to know what those technologies are. It “just works”.

OpenID

Let’s start with what you might already be familiar with. You’ve probably heard about OpenID before. If not, you might notice a little vertical orange line with a little gray arrow going from the line in a circle on some sites you visit. Google just announced today that their profiles are now OpenIDs. That basic concept is that you can specify on any website on the web a “provider”. When you log in via Open ID, all you have to enter is your preferred website that specifies this “provider”. The website you’re logging in to then redirects you to that provider, you provide your password, and it takes you back to the authenticating site. It’s a simple authentication mechanism that enables sites to know who you are, just via a simple URL. StayNAlive.com is a identifying URL for me, and points to my provider, myopenid.com.

In addition, utilizing technologies such as “FOAF” (Friend of a Friend), and the Google Social Graph APIs and other technologies, you can do cool things with identity. Since I know your provider ID is being linked by your website, I know both your website and that provider are the same person. You can link sites together, and now you know which profiles around the web are truly you – it becomes much harder to spoof identity in this manner, especially as more and more sites begin to adopt this methodology. The problem with OpenID is its still a little confusing (even for me), and not everyone is familiar with entering in a URL into a log in space to identify themselves.

Information Cards

Enter Information Cards. This is a new space for me, but a fascinating one. An information card is a local identity, stored in your browser or on your operating system, which you can “plug in” to any website, and it tells that website about you. Theoretically, they could even sync off of a local server somewhere, but Information Cards (so I understand) are controlled on the client.

The cool thing about Information Cards is that you can store lots of different types of information on them (again, if I understand correctly). At a very minimum, information cards allow you to store an identity about an individual. In an ideal environment, you would be able to download an information card program like Azigo, visit a site like Yahoo.com, select your Yahoo information card, and just by clicking the information card it would immediately log you

into Yahoo. The cool thing is that ideally, this completely avoids the phishing problem because Yahoo is the only one that can read your information card for Yahoo.com.

Here’s the kicker though – you can store more than just the log in for an individual in an information card. Imagine storing privacy preferences. What if I don’t want Yahoo to have access to my birth date, for instance? Or what if I wanted to go even further and completely customize my experience? What if I wanted Microsoft to provide updates for me right on top of Yahoo.com? What if I wanted to get a completely customized experience based on the websites I really like around the web? This is where the next part comes in.

The End of the Cookie and Birth of “the Selector”

Imagine a web where you, the viewer or user or consumer, are able to browse and get a completely customized experience that you control. What if you are a Ford user and want to see comparable Ford cars on Chevy’s website? (I talked about this earlier) Or here’s one I’ve even seen in production: I’m a big Twitter user. What if I want to learn what others are saying about the websites I visit on Twitter without ever having to leave those websites? Or say I’m a AAA member and want to know what hotels I’m searching for are AAA-supported? What if I don’t like the way a website I visit is rendering content and I want to customize it the way I want to? All this stuff is possible with the Selector.

In the past you usually were at the mercy of these websites unless they provided some way for you to create your own context. This is because these sites are all reliant on “cookies”, pieces of information stored on the browser that are reliant on IP that are only readable by the websites that generated them. With a cookie there is no identity. There is only IP. With a cookie the website controls the experience – each website is in its own silo. The user is at the mercy of each silo.

Kim Cameron and Craig Burton have been big proponents of a new identity technology intended to replace the cookie. It’s called “the Selector”. The idea of the Selector is that you, the user, use Information cards in a manner allowing you to fully control the experience you have as you peruse the web. The idea uses an extension to information cards, called “action cards“, which enable users and consumers to specify their own preferences as to who shows them data and when around the web. The cool thing is that businesses have a part in this as well that the users can opt into.

For instance, Ford could provide an action card (or “Selector”) using technologies like Kynetx to display comparisons of Ford products right next to Chevy’s right on the Chevy.com website. Chevy.com can do nothing about it (other than provide their own selector) – it is 100% user-controlled, and the user’s choice to enable such. Or, let’s say I’m a big Mac user and I want to see what Dell products are compatible with my Macbook – I could simply go to Dell.com and find out because hopefully Apple has created a Selector for Dell.com. Not only that, but these sites, Dell.com, Apple.com, Ford.com, Chevy.com can all track my interest based on preferences I set and customize the experience even further so I am truly gaining a “purpose-based” experience around the web.

All of the sudden I’m now visiting “the web” instead of individual sites on the internet, and the entire web becomes the experience instead of a few websites. The possibilities are endless, and now imagine what happens when you add a social graph full of truly contextual identities on top of all this. Now I can feed my friends into this contextual experience, building an experience also based on the things they like and adding it onto the things I like. There are some really cool possibilities when the web itself is a platform and not individual websites.

Ubiquity

The future of the web is Ubiquity, the state or capacity of being everywhere, especially at the same time. Users will be ubiquitous. Businesses will be ubiquitous. There are no boundaries in the web of the future. I’ve talked about the building block web frequently but that just touches the surface. In the future these building blocks will be built, and controlled by the users themselves. Businesses will provide the blocks and the users will stack them on top of each other to create their own web experience.

Businesses will have more sales because the consumers will be getting what they want, and consumers over all will be more productive. This new approach to the web will be win-win for both sides, and we’re just getting started.

Where We Are At

Here’s the crazy thing that blew me away last week – we’re so close to this type of web! We see Google building an operating system entirely out of a browser. We have Information card and Action card/selector platforms such as Azigo, which enable users to seamlessly integrate these experiences into the browser. We have developer platforms like Kynetx which enable the creation of such an experience.

Imagine if Google were to integrate information and action cards right into ChromeOS. What if Kim Cameron were to get Microsoft to integrate this into IE and Windows? (hint – they will) What if Apple integrated Information Cards into the Keychain so you actually had context with your log on credentials? All this is coming.

Where We Still Need to Go

We’re not there yet, but we’re so close! I want to see more focus on this stuff and less on the Social web and real-time technologies. For those technologies to fully succeed we need to stop, take a deep breath, step back, and get identity right. We’re not quite there yet.

I want to see technologies such as Mozilla Weave integrate Information Cards for their browser (rather than reinvent the wheel, which is what they appear to be doing). We need more brands and more companies to be writing contextual experiences on the Kynetx platform (which is all Open Source, btw). We need more people pushing companies like Google and Microsoft and Apple to be integrating these technologies so the user can have a standardized, open, fully contextual experience that they control. I want to see Facebook create an experience on these platforms using Facebook Connect. I want Twitter to build action cards.

For this to happen we need more involvement from all. Maybe I’m crazy, but this future is as clear as day for me. I see a future where I go do what I want to do, when I want to, and I get the exact experience I asked for. This is entirely possible. Why aren’t we all focusing on this?

Sign in Graphic Courtesy Chris Messina

Ebay Suggests Identity API – Can They Do it Alone?

Posted on November 4, 2009 by jessestay

Ebay’s CTO, Mark Carges, today announced at Paypal X Innovate plans by Ebay, Inc. to begin incorporating the Paypal login process as an identity platform for consumers to eventually open up to developers. The platform, Carges said, aims to use the existing Paypal login ID which includes address and phone number verification, bank account attachment, and more to identify individuals as real people. He stated Paypal already goes through great lengths to protect these users’ identity, suggesting this was a natural move towards identity in the cloud.

The move makes sense, but searching Twitter during the Keynote revealed a different story. Audience members are skeptical, stating things like “scary morning talk by the Paypal CTO. all your ID belonging to us. a closed OpenID?” and “wonder if this is what @timOreilly is afraid of – platforms becoming the OS?”. In many ways these audience members have a point – is it possible for Paypal to go alone in this identity space when they could either be leading or joining existing identity efforts such as OpenID? I may be wrong but I do not recall any mention of the word “open” in his proposal. And when he mentions things like “they are working with Government” it gets a little scary that a single company may control all this along with government.

At the same time, maybe this is the solution. Will the solution to identity be a closed platform that has devoted ways of verifying identity like Paypal and Ebay can provide? Does the web need a “more secure” closed platform to finally solve the identity problem?

I’m very interested to see how Paypal progresses on this. My hope is that they either lead or join existing open standards in this effort, and rather than taking this alone they approach others. A platform is always a good thing, but a platform is not “open” until it is based on open technologies and the technologies themselves are built by the community. This is especially applicable in the identity space.

Paypal’s CEO yesterday reiterated that through the years payment itself was controlled by a few big entities. Paypal’s vision is “Into the hands of many” , intending to pass that control to the developers. He even compared it to Linux and how the future is in the community and no one company having control. My hope is that Paypal maintains this standard in the identity arena. Based on their vision so far it looks hopeful – let’s hope they don’t feel the need to take the Identity platform alone.

When it’s uploaded you can listen to the whole Keynote in my Cinch folder.

Oh, the Trouble With OAuth

Posted on August 7, 2009 by jessestay

This article has been sitting on my desk for the past week or so, and recent activities around the Twitter/Facebook/LiveJournal/Blogger DDoS attacks have made it even more applicable, so it’s good I waited. The problem centers around the “Open” authentication protocol, OAuth, and how I believe it is keeping companies like Twitter who want to be “Open” from becoming, as they call it, “the pulse of the Internet”. The problem with OAuth is that, while it is indeed an “Open” protocol, it is neither federated, nor decentralized. We need a decentralized authentication protocol that doesn’t rely on just the likes of Twitter or Flickr or Google or Yahoo.

Let’s start by covering a little about what OAuth is. OAuth centers, as the name implies, on Authorization. This is not to be confused with identity, which other decentralized solutions like OpenID focus on. The idea behind OAuth is that any website, or “Service Provider”, will accept a certain set of HTTP requests, handle them, and send them back to the developer, or “Consumer” in exactly the same way as any other OAuth protocol does. OAuth tries to solve the issue of phishing and storage of plain-text usernames and passwords by sending the user from the Consumer website, to the Service Provider’s website to authenticate (through their own means or means such as OpenID), and then authorize. On Twitter this process is done via an “Allow” or “Deny” button the user can choose to enable an application to make API calls on their behalf. Once authorized, the Service Provider sends the user back to the Consumer’s website, which is given a series of tokens to make API calls on behalf of that user.

OAuth’s strengths are that it is easily deployable by any site that wants a central, secure, and understood authorization architecture. Any developer can deploy an OAuth instance to communicate with APIs that provide OAuth architectures because libraries have been built around the architecture for developers’ preferred programming languages, and adapting to a new site implementing OAuth is only a matter of changing a few URLs, tokens, and callback URLs. I’m afraid that’s where OAuth’s strengths end, though.

Let me just put this out there: The User Experience behind OAuth is horrible! From a user’s perspective, having to go to an entirely new website, log in, then go back to another authorization page, and then back to the originating website is quite a process for an e-commerce or web company that is focusing on sales around that user. No e-commerce company in their right mind would put their users through that process, as the sale would be lost with half the users that tried it. Not to mention the fact that (and I don’t know if this has anything to do with the actual OAuth protocol) with most OAuth implementations there is no way to customize the process the user goes through. For example, on Twitter, I can’t specify a message for my users specific to my app when they authorize it. I can’t customize it in any way to my look and feel. I completely lose control when the user leaves my site to authorize and authenticate.

Let’s add to that the problem of the iPhone, desktop apps, and other mobile apps. Sure, you can redirect the user within the app to a website to authorize, but again, you’re taking them away from the app flow during that process. It’s a pain, and headache for users to log in using that method! Not to mention they have to do that EVERY. SINGLE. TIME. they log in through your app since there’s a good chance they were not logged into Twitter or Flickr or other OAuth app in the first place. It’s a huge problem for OAuth developers on these devices, and less-than-ideal.

Now, back to my original point. The biggest problem with OAuth is that it requires a centralized architecture to properly authorize each application. We see this is a problem when entire apps like my own SocialToo.com can’t authenticate users when Twitter gets bombarded by DDoS attack. The need for centralized control of each app on their platform is understandable, in that in the end the companies implementing OAuth still need a way to “turn off” an application if an app gets out of hand. Of course, one solution to this from the developer’s (Consumer’s) perspective is to implement their own authentication and authorization scheme rather than relying on someone like Twitter’s. This is less than ideal though, since most of our users all belong to some other network that already handles this process for us. Why require our users to repeat the “account creation” process to overcome centralization?

I think there is a better solution though. What if a distributed group of “controlling sources” handled this instead, giving each company admin control over their own authorization? What I propose is that a new layer to OAuth be created (or new protocol, either way), enabling trusted “entities” to, on a peer-to-peer (federated) basis, sync authorization pools of users and their distinct permissions between each Consumer app and Service Provider. Companies/Service Providers could then register with these “controlling sources”, and they would have admin access to turn Consumer apps on or off in the event of abuse within their app.

So let’s say you’re Twitter and you want to let your developers authorize with your API. You register on one of these “controlling sources”, they confirm you’re legit (this could possibly be done via technology in some form, perhaps OpenID and FOAF), and let you create your own “domain” on the “controlling source”. Twitter would now have their own key on the “controlling source” to give developers, and the controlling source would divvy out tokens to developers wanting to access Twitter’s API. Twitter’s API could verify with the controlling source on each call that the call is legit. To kill an application, they would just need to log into the controlling source and deny the application. The application would get denied at the controlling source before it even hit Twitter’s API.

What makes this open is that, if this were itself written under an open protocol, anyone could theoretically create one of these “controlling sources”. So long as they operated under the same protocol, they would operate and work exactly the same, no matter who they were. Developers could then pick and choose what “controlling source” they wanted to authorize through. If one went down, they could switch to another. Of course, there are some security issues and authenticity of “controlling source” issues that need to be worked out, but you get the idea. This would essentially completely de-centralize the entire authorization process. Authorization itself would quickly become a federated process.

Now, that still doesn’t solve the User Experience issues I mentioned earlier. To solve those, I think we should look at Facebook and what they’re doing with Facebook Connect. With Facebook Connect, the user never leaves the Consumer’s website to authorize and authenticate. They click a button, a popup comes up, they log in, and a javascript callback notifies the app the user has been authorized and authenticated. It’s essentially a simple, 3-step process that completely leaves the website owner in control. In addition, Facebook has provided Javascript methods allowing the developer to confirm various states of authenticity, without the user having to leave the website. I’d like to see OAuth emulate this model more. Right now I’d rather implement Facebook Connect than OAuth for these reasons.

I think, as both Dave Winer and Rob Diana point out, there are some serious issues being brought up from the recent DDoS attacks against Twitter and other sites. Twitter’s inability to handle the DDoS attacks when compared to the others I think shows we need much more Federation from the site, as well as the “Open” protocols it is trying to build around. Twitter wants to become a utility. There is no way that will ever happen until they Federate, and I think that has to start with a change to the OAuth protocol.

Facebook’s Deployment Record is Spinning but Seems Broken – Does it Need a Poke?

Posted on May 25, 2009 by jessestay

Facebook lately has been very good at providing regular and frequent updates to its service. So much that it has often come under the gun for updating too much to the detriment of its user experience. I have been last to critique them on this however, as I think it’s a good thing to be listening to your users like they have, releasing early, and releasing often as users give feedback towards the experience. I think it’s a major reason Facebook is still growing and still surviving despite Social Network users being the type to easily get bored of new technology. There have been several launches recently which, IMO have been very loud and powerful in the way they were announced and the affect they would have on users. You probably read about them because they were talked about on almost every major Tech blog when they were announced. There’s still one major problem though – myself and numerous other users still haven’t received these features.

Let’s start with the launch of one, as a heavy FriendFeed user and strong advocate of real-time updates, hits near and dear to my heart. The Facebook stream live updates were announced over 3 weeks ago, claiming to provide you with a live update of new posts in your stream when they appeared. A simple click on the link should make those messages appear. While not completely real-time, it’s a step forward, and something I’ve been really looking forward to for over 3 weeks. You can see my profile, after over an hour of not refreshing on Safari here – note there is no link with new updates:

Here’s how it should look, according to Facebook:

It should also be noted this looks the same if leaving Firefox stagnant, or running on Windows, or any other machine or browser. This isn’t an OS or browser issue it would appear – it looks as though Facebook’s deployment routines simply haven’t gotten to my user account. It would appear I’m not alone in this either. Asking about this on Twitter about a week ago I got numerous responses from other Twitter and Facebook users who also were not yet seeing this in their stream. A Facebook employee even kindly suggested I was supposed to be receiving this. I responded saying I wasn’t, but still have not received any feedback in return from Facebook.

It would appear that’s not the only thing that is having trouble rolling out lately though. Over a week ago, Luke Shepard, a developer at Facebook, announced a very welcome feature launching Facebook into a much more open era. The feature enables users to link their Facebook accounts to their Gmail accounts and other OpenID providers, making Facebook an official OpenID provider. Also, according to Shepard, users would be able to register for Facebook by simply entering their Gmail credentials. “Now, users can register for Facebook using their Gmail accounts. This is a quicker, more streamlined way for new users to register for the site, find their friends, and start exploring,” he said.

The problem is that I still don’t see a way to do this on Facebook. I can link my Facebook account with various OpenID providers and even Gmail, but that’s only if I have an existing account. However, there is no option when I log into Facebook, or when I try to register with Facebook to login or register with my Gmail credentials or other OpenID credentials as he says. Am I just the last person on their deployment list? I know I’m not the only one because this was pointed out by someone else with the same question. If I can link my OpenID profile with my Facebook profile, but can’t login or register with it, what good is this announcement?

Note there is no option to log in with Gmail or OpenID

Note there is no option to register with Gmail or OpenID

It would appear something seems broken in the Facebook deployment process. Either it’s just really slow, or not all users are getting the updates they’re supposed to be getting. Or are we getting these announcements just to get the marketing spin machine going? It would appear that this blogger is not on that list if it is the case! Regardless, I’d really love to have the updates we were promised!

If you’re seeing the same issues, let it be known in the comments. You can follow me on Facebook at http://jessestay.socialtoo.com.