Blue Ocean

I recently tried to buy a marine handheld GPS online. Like everyone else, I started with some consumer research on Google and finally ended up chasing the best bargain across a few price comparisons engines. I did found some very compelling prices from online stores that I never had heard of before. In the end, however, I decided to buy from Amazon.com. Although Amazon.com commanded a price premium, I still elected to buy from them. Why? Because, I knew that I would have a safe experience and that they would ship the product on time. All the other e-tailers were unknown to me, and I was not willing to take the chance of getting into a hassle for a 10% discount.

This personal experience seems revealing of the state of online commerce today. Short of a strong brand, the long tail of e-merchants is facing head winds when it comes to attract new online customers. It is not enough to be found on search engines. It is not enough to offer better prices. It is not enough to carry more specialized inventories. e-tailers need to inspire trust and confidence to online shoppers. Short of that, consumers will always privilege a larger online competitor and a known brand when it comes to making a purchase decision.

This speaks to a missing element of today's Internet infrastructure, a new breed of Web service that sits between merchants and consumers. In fact, search and price comparison engines only do half the work. They point us to merchants. Yet, they fall short from providing us with the necessary information to make an informed decision. We need a trust engine. We need easy access to a merchant profile, policy and business practices. We need an infrastructure service to discover a merchant's business reputation. We need a trusted third party that can provide accountability when such merchant falls short of our expectations. Easier said than done, but this significant void also creates a promising business opportunity for whom can fill it.

So, what would a trust engine do? What information would it have to provide to become an indispensable tool to both consumers and online merchants? Maybe, a combination of the best ideas from today's offline and online services could do the trick. Indeed, it is easy to be inspired by some of the most useful services that already aspire to feel that gap: from the venerable offline Better Business Bureau, to eBay merchant reputation, to the more user-centric and Web 2.0 Yelp. Yes, more than ever, the Internet seems ready for a network wide business reputation infrastructure.

Posted by Nico at 10:38 AM | Permalink

The controversy around personal and social data portability is growing. For consumers, it is an important issue because it will determine how much ownership they will be able to enforce upon their "digital identity" that lives today across competing Internet silos. For the silos, the Google, FaceBook, Yahoo! and Microsoft of the world, a lot is at stakes since, ultimately, it is about whom consumers will entrust with their digital self.

Undoubtedly, data portability is the natural child of federated identity (more on that in a future post). Personal and social data are an important part of any consumer identity'. Like identifiers, credentials and profile attributes, social graphs, activity streams belong to the end user who created them in the first place. In the long run, consumers will require full control, privacy, security and portability over such personal information. Therefore, the identity technical community must engineer a new and comprehensive identity portability layer. The new layer needs to broaden the tradition notion of identity federation beyond names, passwords and profile to encompass the full gamet of personal and social data. Furthermore, this new layer must support a plurality of identity service providers who can compete and distinguish themselves by the quality of their service and the user experience that they provide. Freeing our data off Web portals and social networks by creating a new service layer dominated by one single service provider is hardly trading one master for another.

Incidentally, putting the user first and ensuring plurality of competing identity service providers strikes as the fundamental principle that OpenID places on identity providers. The OpenID foundation has always be the strong proponent of a user-centric approach to Internet identity. Unlike many organizations, it appears to have achieved a balanced representation across the grass-root technical community and large big Internet corporations. Moreover, because of the strategic stakes it represents, the quest for personal data portability is likely to become the main driving force behind OpenID deployment and maybe, even the necessary solution to the so-called "relying party problem".

As a neutral ground, I hope the foundation will quickly realize that it has the opportunity and responsibility to provide the necessary leadership that helps clearing the technical issues around personal information and data portability. Yes, more than large Internet companies proclaiming their own APIs as open standards, it seems to me that OpenID can be the right foundation (pun intended) to lead towards a true interoperable solution for Internet data portability.

Posted by Nico at 11:11 AM | Permalink

The issue of personal data portability is rapidly moving center stage. So, what is the big fuss about and what is really at stake here?

For us, as consumers, it is an important issue because eventually, it will determine how much ownership we will be able to enforce upon our personal data and content, including our social graph, that today, is dispersed across competing social networks and Web portals.

For Google, and FaceBook (FB), the stakes are equally high. Ultimately, the winner could take it all and be the one who really drives revenue from social networking. But to understand, we need to review the controversy first.

It really all started with OpenSocial. OpenSocial was Google's response to the rapid rise towards hegemony of FB APIs. To counter FB, Google created an alternative that it self-proclaimed an open standard by rallying a large number of FB competitors behind it.

Competitive response aside, Open Social also arises from our industry's realization that social network is much more than a destination. Social networking is really a new application dimension. It is a new form of interactions that can augment almost any application, or any web site. To add social networking capabilities to an application, you need APIs. OpenSocial fills that gap.

With OpenSocial, Google is also reducing social network to mere "containers". Google is turning the social networking portals into a set interoperable data sources that it can dip into. In fact, with the consent of the end-user, these social databases become instantly accessible to a whole new layer of identity services. The first generation of these new of services is now known. It is called Google Friend Connect.

It is clear that FB understand the threat of a layer above social networks dominated by Google. Its decision to block Friend Connect under the excuse of privacy control does not fool anyone. It is also likely that OpenSocial may have forced FB into exposing its own APis to third party Web sites. Friend Connect, on the other hand, is consistent with Google "social cloud" strategy. It simply extends OpenSocial by alleviating the need for site owners to write code. Although it remains to be seen whether an embedded widget can provide the right user interface, by putting itself, between Web sites and social networks, Google is moving fast to disintermediate the leading social network. If Google were to succeed, it would surely make a significant dent into FB's $15B valuation.

But what is the real prize here? What is really at stakes? Let me venture an explanation. How do you discover sites, products, music, videos on the Internet? You Google it,of course. Now, in the real world, how do you discover products, movies, or books? Very often, you discover them through your social connections. Social events are always full of "I love this new product, you should really buy it too", "you must see that movie", "I highly recommend reading that book", "this restaurant is unbelievable". So maybe, social discovery is the perfect complement to search when it comes to generate and monetize traffic to other sites.

So here may lie Google's bet on Open Social. The bet is that social networking capabilities integrated into a Web site can drive viral traffic (because your social feed will notify your friends of a site visit or of a transaction, because you will recommend a merchant by becoming a 'member of the site' or writing a review, because you will trust a site by finding people you know who have already experienced this site). Not withstanding the data mining and advertising intelligence opportunity that sitting between sites and social networks can present in the long run, the bet is that social interactions will drive more site visitors. Of course, for an ad network like Google that strives on monetizing new customer acquisition and traffic, it is a very rational bet.

So while FB seems initially more concerned about keeping interactions within the walled garden, Google is forcing all the social networks to embrace a deportalization strategy. Of course, it is a smart move for Google who, unlike social networks, has already strong customers relationship with most Web sites through its AdWords and AdSense programs. Without access to a direct channel to online merchants and .COM sites, FB is in a relatively weaker position but it had to respond and Facebook Connect is its current answer to Google. Will FB be more effective in driving revenue by deportalizing its APis and driving traffic outside FB instead of raising the walls of the garden day by day? That remains to be seen.

At the end of the day, social traffic is still a theory in search of validation. For these merchants and Web site owners, that traffic may never materialize. To the non-believers, I can only oppose the success of Yelp whose sole purpose of its community is to drive traffic to local businesses. Considering the energy that Google is deploying around open Social and Friend Connect, we should have our final answer soon. One thing is almost certain, for the near future, the social cloud is likely to be the strongest market force driving internet-scale identity services, and that is very good news for OpenID.

Posted by Nico at 11:18 AM | Permalink

With the increasing visibility of OpenID, VeriSign gets often invited to conferences to discuss the implications of this new technology. One of the questions that I often get from the audience borrows a line from Jerry Mc Guire: "When technology is based on IP-free open standards, how do identity vendors and service providers make ends meet?" In other words: "Show me the money!" Broad question, so I thought I would get on the record to describe a few of the popular business theories around OpenID and discuss their respective merit.

The IDM Software Business Model:

The first answer is to observe that OpenID is a federation protocol and as such, it fits well within an identity management suite (very much like SAML, or WS-*). Vendors in that space are well known: CA, HP, IBM, Microsoft, Oracle, Sun, etc. IDM vendors derive revenue by licensing their identity management software to large enterprises. Single-Sign-On across enterprise applications still remains an unsolved problem within many enterprises. Because of it is ligthtweightness, OpenID carries the promise of simpler integration across many internal Web applications (enterprise portal, SAP, Oracle Web apps, etc...), making it an attractive IDM solution component and a must-have for most IDM software vendors.

The Service Aggregator Business Model:

OpenID is especially best suited for managing identities across consumer services. So, the natural early adopters will be consumer service aggregators, such as Mobile Network Operators and MSOs. Indeed, these companies view their millions of subscribers as an untapped strategic asset. The ability to leverage OpenID to more easily up-sell and cross-sell subscribers across a growing portfolio of services and channels (wireless, broadband and TV) has strong business appeal. In other words, federating within the walled garden makes good business sense: one unified identity, one converged brand experience, one view of the customer and the ability to subscribe existing customers across new services in one single click, whilst charging them on one single bill.

The Security Business Model:

As a consumer, if you have one consolidated identity for use across many Web services, you are more likely to want to protect that unique identity. It is also easier to do so, since only the identity provider needs to deal with the complexity of any additional security technology. In a shared identity eco-system, security solutions such as strong authentication become more cost-effective since the price of securing identities can now be shared across all the relying parties. In other words, economies of scale can be realized. This is exactly the VeriSign identity protection model that we introduced in early 2006. At that time, OpenID did not exist, so the chances of sharing a complete identity were pretty slim. Therefore, we decided to adopt a simpler sharing model where only the security (the second authentication factor) is shared across sites. Authentication services such as VIP are a good fit for OpenID as they make it relatively easy to turn any IDP into a strong IDP. Beside, if accepting a name and a password from a third party may not provide much additional value over a self-issued name and password, the idea that an identity provider will provide a more secure and stronger identity could well be a compelling value proposition for sites to start accepting OpenID as relying parties.

The Insurance Policy Model:

Building on the idea that what makes accepting a third-party as an identity provider is a stronger identity, arises the identity assurance model. In that model, the identity provider becomes a risk underwriter. Basically, the IDP "insures" the relying party on the validity and knowledge that it has about a given identity. The identity risk profile allows the IDP to make some explicit guarantees (e.g. "no charge back") and be compensated for it. For example, a bank who knows a lot about a consumer identity and purchase behavior could vouch for a consumer transaction to be trustworthy and underwrite the risk based on the consumer risk-profile that it has accumulated over time.

The Lead Generation and Advertising Model:

In OpenID everyone is focused on Single-Sign-On. The truth is that the real money-maker may be more about attribute exchange than simpler login. By attribute exchange, I mean the ability to seamlessly transmit a subscriber's registration profile and payment information in real-time. In that context, I can see OpenID become an enabler for CPA-based advertising. In the CPA model, the publisher and the ad network (IDP) get paid when the user registers with the advertiser (lead acquisition) or purchases from the advertiser (impulse buy). By removing the typing, OpenID can enable a much more effective CPA model where the user only needs to login into their identity provider to authorize a registration or a purchase. The ability to register a new customer and allow them to pay from any device within 1-click could prove a significant enabler for direct response advertising.

Of course, all these business models remain somewhat theoretical and unproven. However, the intuition is that there are many angles to consider when approaching OpenID from a business perspective. Interestingly, the breadth of opportunities should make the emerging standard more relevant to many leading Internet companies. This may explain the broad and growing attraction for federated identity, and OpenID in particular. That is all good news for the technology, as without business drivers, it will remain a technology construct that makes conferences headlines but is ignored by business minded leaders. That would be a shame of course as the best ideas are the one that can seduce consumers, technologist and those who follow the same three directives day after day: "Show me the money, show me the money, show me the money!"

Posted by at 10:38 AM | Permalink

When Google tells the world it is going after the mobile way, one should always take notice. So, after weeks of procrastination, I finally took a look at Android. My timing was not too far off, since the first Android phone only made its appearance at GSM this week.

In a nutshell, Android is a mobile platform that builds on top of Linux but bundles additional layers such as a web browser (Webkit), a set of applications services (e.g. telephony and messaging) some libraries and a homegrown runtime (ala Java VM). The marketing brochure says that Android is Open (and most of the components are).

Like the first Google phone, Android seems to be a work in progress. A few hours of digging into the developer site and the examples, followed by a sudden crave for caffeine that interrupted my progress, eventually left me with mixed impressions. Yes, I would have to admit that Android was rapidly falling short of my high expectations. After all, the mobile brainchild of a company with such technical talent as Google had to be second to none.

It is not that Android is technically bad. It is quite the opposite, actually. Technically, Android is extremely sound and brings some interesting innovations. It is just that it does not seem very Google-like to me. In particular, it does not fit the Web-centric programming model that you would expect from the inventors of AJAX and precursors to the Web 2.0 movement. Why Google would decide to err so far away from the development model that made their success was really a big surprise to me.

Take for example, Android's application component model. It relies on the new concepts of "Activity" and "Intent". The idea is to enable an application to easily mix different components from other applications within its own view (way back then, Microsoft called this Object Linking and Embedding (OLE)). Great idea, right? Yes, especially, in a mobile environment where users frequently need to switch between messaging, contacts, and calendaring. But then again, why not enabling widgets and mashups as a simpler GUI and component model for mobile? After all, Apple just did that for MAC OS X. instead of making the Web and mobile come together, Android is introducing yet another programming model. As good as it may be, it sounds like a missed opportunity to do what Google does so well: pushing complexity to the cloud, and simplicity to the client in order to enable the largest developers community.

This is my sole disappointment, really. Android does not try hard enough to enable the Web programming model into the mobile. Instead, like any traditional mobile OS company, it makes it a second-class citizen. In doing so, Android confines most of the Web developers to the browser. That kind of traditional device-top approach is exactly what you would expect from non-Web companies like Nokia, Sun or IBM, but from Google? Where are the XHTML, CSS, JavaScript and all the REST (pun intended) of the Web 2.0 technologies that made us scream "WOW" the first time we saw that Google map drag along the mouse?

Yet, Google is standing strong behind Android. Therefore, I would expect Android to enjoy a long and prosper future. It just seems strange that in the end, Google decided to opt for a development model that is foreign to its own DNA. Ah! But on the other hand, they did call it Android, didn't they?

Posted by at 02:47 PM | Permalink