Blue Ocean

Trust assurance in open identity networks

2009-11-04T05:50:47Z

One of key challenges in federated authentication network is the establishment of trust between an identity provider (IDP or OP) and relying party websites (RP). In the real world, contractual agreements provide a simple out-of-band mechanism to effectively bind two parties into a trust relationship. When it comes to federated identity networks, peer to peer contracts between many identity providers and a myriad of relying party websites do not provide for a scalable process. Therefore, open federated networks need a trust assurance framework to bootstrap trust between the three parties (the user, the OP and the RP).

The basic idea is that if an OP can be certified to comply with a set of industry best practices, the RP should be able to enter into open identity exchange where both the websites and the consumers are reasonably protected. Of course, a pragmatic trust assurance framework should be flexible enough to support different levels of assurance based on the transaction risk and value. For low assurance Web federation where large brands such as email providers and major social networks dominate as OPs, certification may seem overkill, unless of course, the federation is built on open principles stating that any OP meeting the standard should be able to participate. For high assurance identity, such as payment networks, financial networks or eHealth record exchanges, certification is primordial. In fact, in such environments, both the OP(s) and the RPs need to be certified.

The NIST guideline for electronic authentication is often referenced in the community as a good model for any identity trust framework. The NIST guideline defines four levels of insurance for e-authentication. Each level is deemed appropriate
Depending on transactional risks. Tiered levels of identity assurance are essential to any pragmatic trust framework. Set the bar too high and deployment becomes impractical. Set the bar too low, and the bad guys will have a ball. Justifiably, the NIST guideline provides a solid starting point. Nevertheless, one needs to observe that the framework may be too narrowly focused on user credentialing and credentials strength to provide a complete answer. Open Identity systems cannot ignore the reality of today's Web vulnerabilities, threats and exploits that feed identity theft around the globes such as man in the browser exploits, session hijacking or Web vulnerability driven exploits like mass SQL injections. A trust standard also needs to go beyond security and address the major consumer concerns and political challenges of privacy. When it comes to trusting identities, security, privacy and anonymity are intricately intertwined. Trust in a federated identity Web mandates a holistic approach that looks not only at user authentication but also takes into account the current state of desktop exploits, Web site compromises and most importantly establishes clear and enforceable privacy protection guidelines.

Trusting the OP/RP Websites: web security & business authentication

For low and medium assurance identity transactions, it seems to be that both the OP and RP website security would need to be asserted. There I think, one can learn from Internet security standard such as PCI. Even though the standard is far from being perfect (a euphemism, perhaps), it provides a shared base of security requirements for all websites to engage into ecommerce and securely handle credit card information. If one believes that consumers will require for their personal identity the same level of security as for their credit card, the parallel can be useful. The OP website should then be scanned for network security vulnerabilities; Ports should be closed. Network services should not run outdated or un-patched software; the OP should not be vulnerable to common Web exploits such SQL injections, cross-site scripting (XSS), or Cross-Site Forgery requests (CSRF). For web application vulnerabilities, the OWASP standard that identifies the top 10 Web vulnerabilities provides a useful reference. In addition to security assessment, a set of security best practices should be required. For example, the OpenID profile retained by the federal pilot already specifies that SSL should be part of the deployment profile. Verifying the authenticity and legitimacy of the organization behind the OP is as important as verifying the security of its website. There, a proven model that the industry could re-use is the EV business authentication standard. EV certification already defines a strong process for vetting organizations and it is already widely used across the industry.

Trusting the user: beyond identity verification and credentials

As mentioned, NIST will provide the foundation for user trust assurance (both for runtime and initial authentication of end users). Equally important, however, is to consider that Internet threats have significantly evolved since the NIST framework was initially published. In particular, we need to recognize that one of the main threat vector for identity theft is now malware. An identity trust framework can no longer ignore the potential of a man-in-the browser attacks (Trojans, key-loggers, worms, etc). Knowing whether the end user has any end-point protection (and maybe encouraging websites to introduce out-of-band messages into high assurance identity transactions when such protection is lacking) could be of consideration.

Trusting the transaction: from activity to security streams

Believing that the OP can provide strong identity assurance by simply checking credentials and abandoning the user at the RP front door is a dangerous over-simplification. Because modern exploits often let the user authenticate to commit fraud further down the session, it is important to enable OPs to leverage the knowledge of the end-user and her transaction patterns to identify high-risk conditions. Since we cannot assume the existence of adequate desktop protection (Internet security that exclusively relies on the presence of a client on the user desktop is no more than an academic exercise), high assurance federation models need to enable the use of fraud engines techniques across RPs (most logically, run at the OP although it could be a separate). The ability to create an effective user risk profile across transactions is what has made the credit card networks work. High assurance identity networks are going to need an equivalent (think VISA of identity). An interesting idea could to leverage the concept of activity stream as a real-time fraud detection primitive. A security stream back to the OP (under complete user consent and strict privacy protection) would allow RPs to feed transactional information back to the OP, allowing it to build a complete risk profile of the user across her Internet activities (fraud detection is often based on clustering techniques that measure abnormal deviation from normal behavior). Even without a risk-engine running at the OP, a security activity stream could have tremendous security value if used as a simple identity alert system to notify the user of all ongoing transactions. In high risk cases, the activity stream could trigger an out-of-band consent for the transaction (think of Visa calling you to confirm and authorize a suspicious transaction); it is interesting to think that the social concept of activity stream that is today missing from OpenID (not from Facebook Connect) could actually be used to drive better identity theft protection. With such transactional feedback loop, a security minded OP would be able return a transaction score and possibly a liability guarantee based on the user risk and behavioral profile built over time. Incidentally, interesting new OP business models could emerge (VISA-like: "I will take a cut of the transaction", Credit-Bureau-like: "I will charge you for the score", Insurance-like: "I will take the liability risk").

Ensuring trust across these three dimensions (the organization, the website and the user) is non-trivial. Yet, it is critical to enable consumers worldwide to engage into shared identity interactions with peace of mind across the Internet. Very much like PCI vendors emerged from the existence of a commercial PCI standard, one would hope that Identity trust assurance services could emerge as well since security companies need economic drivers to build great services. One of the key challenges of the standard will be to strike a balance between where to set the security bar to permit a high level of automation for accreditation. Such balance is always hard to strike, but it is also what makes the challenge worthwhile.

OpenID goes to the White House

2009-09-22T19:19:50Z

Two weeks ago, I had the privilege to join the OpenID foundation and Information Card boards for a meeting with CIO, Vivek Kundra and his staff at the Whitehouse. The goal was to discuss the forthcoming OpenID pilot and better understand the government commitment to enabling distributed identity on the Web. Undeniably, this was a very interesting and spirited discussion.

A key take home for me was the recognition of identity as the lynchpin to new citizen-centric services, governmental IT cost reduction, and stronger cyber security. For key Obama initiatives such as citizen participation or electronic health records, identity management was described as foundational. Equally impressive was the sense of a holistic and consensual approach towards the broad deployment of trusted digital services across federal, state and local Web sites.

In particular, there is a clear view that the deployment of low level assurance identities is only a critical first step, not an end in itself. With the initial OpenID pilot, the administration is seeking to teach Internet users how to conveniently and confidently re-use their identities across multiple sites. Federation is a new behavior and as such, it requires training. Federal and State web sites will provide an important training ground of relying parties. The government endorsement of OpenID is likely to prove significant. After all, if OpenID is good and secure enough for the government, it should be good and secure enough for most Web sites. Beside, once consumers are comfortable using distributed identities, it becomes possible to alter the login experience by introducing stronger security and identity assurance. This is the ultimate end game since high assurance identity services are pre-conditions to new strategic initiatives.

Consider health care reforms for example. To counter balance the $900B expense that the new Obama plan calls for, electronic health records must come to reality. However, eHealth requires access control across a large and complex ecosystem. Users must be able to register, login and access private data across physicians, hospital, pharmacies, labs, insurance, and employers Web sites. Privacy and security concerns are high on the list. Without high assurance, clear liability models and robust shared identity services, eHealth is a non-starter.

The crawl, walk run approach to identity services that our federal government is taking may prove insightful. By restricting initial interaction to pseudonymous and low assurance level identities, federal web sites instantly provides the industry with a simple test bed to iron out the trust and privacy frameworks necessary to the deployment of large federated identity networks. User experience, privacy policy and security approach that can work for millions of consumers will have to be standardized. The liability elephant that has been haunting the identity discussion rooms will have to be tamed. No doubt that the OpenID foundation, the Information Card foundation and many other have their work cut out for the next few months.

So, keep an eye on the pilot. If all the planets keep aligning, and federated identity can prove to significantly increase user registration, an important chapter in the book of distributed identity systems may be just about to open in front of us.

Open identities for open civic action? Yes, we can!

2009-09-09T01:05:29Z

Today, Federal CIO Vivek Kundra is announcing the first pilot for its Open identity initiative. The pilot will support both OpenID and Information Card technologies. Initially, it will be conducted by the Center for Information Technology (CIT), National Institutes of Health (NIH), U.S. Department of Health and Human Services (HHS) and other agencies. Over time, over 500 governmental web sites may become Open ID relying parties, potentially, creating one of the largest federated identity network.

Bien sur, VeriSign and the PIP will participate to the pilot as Open ID authentication services. This means that your VeriSign PIP ID will be accepted across participating federal Web sites. Saying that we are proud of being a part of this important announcement would be an understatement. The open identity initiative is a crucial step in President Obama's mandate for open citizen participation on key society issues such as health care, ecology and energy.

The goal is as bold as it is audacious. By embracing open and distributed identity systems, the US government is taking a resolute step towards turning the Web into an organizing engine for participative civic action. Identity is foundational. Making it easy for users to register and participate in government Web sites is smart. Removing obstacle to participation by allowing citizens to manage their digital identity through independent service providers of their choice is inspired. Yes, the tone is definitely right. Civic participation should be based on principles as open as is the Internet that enables it.

User centric identities for a citizen centric Internet? It certainly feels very right to me.

Read our Press Release.

I will have your cookie and eat it too

2009-08-20T16:12:55Z

In the coming years, many websites will contemplate adding strong authentication to accounts login. So far, early adopters for strong authentication have mostly been financial institutions. Since 2005, banks and brokerage firms have had had little choice than following the FFIEC guidance. This 2005 regulated mandated a move to stronger credentials than just name and passwords. Today, SAAS providers and large consumer Web sites are increasingly suffering brand exposure and public scrutiny following high visibility attacks (here and there). With increasing reliance on the cloud to host mission critical applications and sensitive data for enterprises and consumers, I would expect many large online services to begin offering stronger login options to their user base.

Interestingly, the FFIEC deployment of multi-factor solutions such as chase.com or bankofamerica.com give us some insight into the type of technology that are likely to be adopted by non financial service providers. Multi factor authentication essentially relies on a cookie as the second factor (the cookie is "what you have"). Coupled with a backend anomaly engine, the client side cookie is used as a "persistent" device identifier. Cookies as device IDs are alluring because they work across all browsers; they do not require any new client install on the user desktop; cookies are transparent to the end user, and most importantly, they do not cost anything. Since cookies could become prevalent as a "second factor" for web login, it is important to be aware of the security limitations and risk that they represent.

The first issue with cookies is their lack of persistence. Statistics show that users very often reset their cookie. This leads to the challenge of "cookie re-issuance" or cookie reset. This problem is roughly equivalent to password reset which, as many recognize, is the Achilles' heel of login. The alternative is not pretty. Either you make the reset process stringent and secure and it becomes a hassle to the end-user; or you make the process relatively easy, and it leads to very simple attacks. In short, the lack of persistence of cookie as device ID will trigger many cookie re-issuance events. Since high frequency life-cycle events cannot be made too complex without frustrating customers, the high frequency of cookie reset will inexorably lead to simple procedures. In turn, these simple procedures will inevitably open the door to a broad range of attacks.

The second class of problem with cookies is that they can easily be stolen using remote attacks such as cross-site scripting (XSS). XSS is a vulnerability that lets the attacker overcome the same origin policy enforced by all modern browsers. The policy circumvents scripts loaded from one domain to access content from another domain. XSS vulnerabilities effectively allow an attacker to execute scripts in the context of the vulnerable domain, hence overcoming the same origin safeguard in the browser. All the attacker needs to do is to exploit this vulnerability by crafting a request parameter value along the lines of . Since this gives the attacker unlimited access to any cookies of the website, DOM content, etc., this is considered one of the most serious vulnerabilities out there. The key about this type of cookie attack is that it can be launched remotely. In other words, an attacker can get to a user cookie without the user machine being compromised by malware. Add malware on the user machine, and cookies as a device ID become a recipe for disaster. In that case, cookies and machines fingerprints can be harvested and sent to the bad guys without the user ever noticing anything.

The increasing reliance on a silent device ID that does not impact the user experience is a logical approach to strengthening authentication on the Web. It is only the absence of alternative to cookies that is leading web engineers to leveraging them for authentication. Cookies were not invented for such purpose. As my sweet-tooth daughter would eloquently put it: the world need better cookies. Eventually, we do need stronger, more persistent devices ID that can be deployed across fixed and mobile devices, competing operating systems and browser platforms. These strong device IDs can be shared secrets, asymmetric key pairs or device certificates. The technology clearly exists but we lack a common deployment framework for device IDs (open client, common user experience, shared ID security stack, hardware protection too) .That is typically where the industry does it best work. Everyone needs it. Everyone will benefit from it. No one can do it alone.

The common need for open standard, open stack and open policies to deal with strong, persistent and privacy-conscious device IDs will inevitably lead to a joint effort. As cookies start crumbling across websites, security experts will get together and the urgency for collaboration will come to bear. In the meantime, when access security really matters, I will keep using my one time password token. If only, I could remember where I left it.

Are Clouds of Change Looming over Perimeter Security?

2009-06-26T17:29:49Z

Although the managed security services (MSS) is a relatively well understood and mature market, a few innovating startups are beginning to challenge the current structure of perimeter security. The interesting question at hand is whether the rapid emergence of cloud computing and the de-centralization it engenders challenge the whole notion of perimeter security, forcing our industry to re-invent today's approach to managed security services.

Today's managed security service providers (MSSPs) essentially offer perimeter security management outsourcing. Customers still have to buy and deploy in-premise security equipment such as firewalls, IPD, IDS and the rest. The tedious day to day management and continuous policy process is delegated to the cloud, but the security boxes remain. From that standpoint, todays managed security services fall short from moving the infrastructure cost and complexity of perimeter security to the cloud.

This brings the question of what happens to perimeter security when enterprise mission critical data and applications start migrating off the IT network to the cloud? How does an enterprise create, enforce and maintain security, access and auditing policies in a world where sales data reside at SalesForce.com, and departmental applications are running on Google App engine, Microsoft Azure or Amazon EC2? In short, what does perimeter security mean when the perimeter extends beyond the familiar boundaries of today's corporate network?

One approach is for SalesForce, Microsoft, and Google to create a home-grown perimeter security management service, on top of their respective cloud infrastructure. Of course, the PAAS (Platform as a Service) vendors will have to enable their cloud perimeter to be flexible enough to adjust to policy requirements as diverse as their customer base. Of course, since applications will migrate across machines depending on load, these polices need to be able to follow the data and applications across data-centers, servers and virtual machine slices dynamically. In many ways, this means that perimeter security has to be virtualized in the same ways as the virtualized data and applications that they are attempting to protect. The problem with this model is to force PAAS providers to go beyond their initial core competency. To go from Web services infrastructure providers driven by large economy of scales, to full IT infrastructure security & compliance provider. That is a lot of complexity and competency to absorb, even for a Google or a Microsoft.

Another model would be for the PAAS to think as a true platform provider and enable specialized security vendors to start building such services on top of their platform. In that model, MSSPs would start building virtualized, multi-tenant perimeter infrastructure on top of their favorite PAAS, and then, sell perimeter security as a service within these environments to their customer base. Obviously, this would require a different platform than the current MSS infrastructures. Moreover, MSS providers would have to adapt to each specific PAAS, forcing them to make strategic choices and restrict them to a few partners, who may not fit what their customers want in the first place.

The last alternative would be the emergence of standalone network security services in their own cloud (separate from the PAAS). The new security cloud would acts as a virtual perimeter by funneling, inspecting, filtering and policing all traffic. Think of the perimeter as dissolving and being replaced by a defense network that consistently protects all corporate network assets independently of where these assets live: within an enterprise, within a SAAS, within a PAAS. For the same reason that Web application software tends to be very different than security software (industry consolidation aside), it would enable cloud providers to focus on what they do best: a cloud to build and deploy custom apps, a cloud to secure them. For the customer, it would enable one single set of policies to be defined, implemented and enforced in a single place independently of the where network application and data actually reside (inside or outside the enterprise).

This is somewhat similar to the concept of "clean pipe" that many MSSPs have been contemplating for several years. The difference is that the move to the cloud and SAAS becomes the compelling driving force that shifts today's legacy deployment model of network perimeter security towards a true in-cloud model. The exact timing of such transition remains unclear, but if one believes that cloud computing is an unstoppable trend, perimeter security may be due for significant transformation in the years to come.

The Next Trust Infrastructure: Securing Mashups

2009-03-09T00:55:15Z

There is no doubt that mashups will be an important construct of the next Internet. The ability to "compose" distributed Web services into one single aggregate service or view is a significant enabler. The lightweightness of HTML and JavaScript speak to the simplicity of a successful programming model. Add to this the emergence of open standards like OAuth, and the need to distribute functionality across screen boundaries (PC, mobile and IP TV), and the picture becomes very clear; mashups and widgets are likely lead the componentization of the Web and become an important distribution mechanism.

For mashups to become ubiquitous, a trust infrastructure is needed. To establish trust between a widget aggregator (a consumer portal, the enterprise portal or your homepage or TV screen), and a widget provider, protocols like OAuth essentially rely on the exchange of shared secrets. This works well when there are only a few big portals serving as aggregators. However, because they require pair-wise trust relationships, the approach does not scale to a truly distributed environment. In particular, the model breaks very quickly in the enterprise as the number of network end-points (enterprise portals and SAAS) explodes.

Ravi Ganesan and his new company SafeMashup may have found the answer to this thorny problem. Ravis' answer is brilliantly simple: reuse the existing and proven trust infrastructure of the Web. Indeed, SafeMashup enables existing CAs to issue credentials to mashers and mashees. These credentials are identical to the one they issue to Web sites today. Because Web 2.0 protocols such as OAuth require a shared secret, Ravi uses the SSL handshake and the issued SSL certificate as a secure method to establish a shared secret between the masher and the mashee. This approach allows him to layer SSL and certificates on top of the Web 2.0 protocols without requiring any change to these protocols. Brilliant!

There is no doubt that broad deployment of mashups requires an open, standard-based scalable trust infrastructure. Reusing the existing PKI infrastructures and its rugged SSL cousin strikes me as a very good idea! After all, when the wheel works, why reinvent the wheel. So, "bonne chance" to Ravi and SafeMashup. Indeed, there is something truly exciting brewing in San Antonio, Texas.

OpenID and the User-Centric Time Machine

2009-02-22T17:37:24Z

There have been a few very insightful discussions from Chris Messina and other regarding the PIP as a secure file, so I thought I would share some of our longer-term product goals.

Today, the PIP file vault is a personal digital locker for our users to manually upload their most personal files. That by itself is not an innovation. In fact, the Web is full of personal storage services like Gmail. Online storage provides immediate and useful value, yet its usefulness is limited by the amount of work an end-user is willing to commit (uploading takes work!).

Now it is interesting to consider how this simple Web 1.0 model of personal digital storage evolves when combined with an OpenID provider. Together, can these technologies allow us to transfer and store in one single place under our control the personal files, private data and rich media content that is today spread throughout the Internet? In short, can a simple file vault become the in-cloud "time machine" of our distributed digital lifestyle?

A SAAS and device-centric view of cloud storage:

A lot has happened with network storage in the last few years. One of the most notorious disruptions is Amazon S3. I would characterize Amazon S3 as a SAAS-centric view of storage. Web applications can outsource the storage function to a highly cost-effective network that already has reached economy of scale. Obviously, it fits the Amazon economic model perfectly. Closer to the end user, we find Microsoft and Apple storage services. Their approach is similar in concept. To them, cloud storage is merely a device enhancement and synchronization is their lingua Franca (iSynch for Apple, Live Mesh for Microsoft). The concept certainly has merit for users with data spread across multiple devices. However, this is a very device-centric view of the world. It fails to realize that increasingly, our critical data resides across many Internet Web Sites with no ability to synch.

A user-centric viewpoint: centralized storage for distributed private data

So, what happens now when one looks at storage with a Web 2.0 user-centric view instead of the cloud-centric view of Amazon, and the device-centric view of Microsoft and Apple? One sees independent, distributed and sometime competing Web services. Through these services, users store personal information, create new data, and acquire digital content. Some of that content is low value and can be left behind. Some of his data is social in nature and is probably best shared with our Facebook friends. However, some of this data is also highly confidential and personal in nature. In that case, we, the end user, should be able to request its safe transfer, and backup to a digital locker that we fully control (the OP).

Towards a "Locker Connect" mechanism

Using the OpenID and OAuth models, such private data transfer can be authenticated and authorized by the end-user (although the data flows from the RP to the OP). The locker network end point address can be discovered as any identity attribute would. Finally, a user interface ala Facebook Connect can provide a friendly user experience while ensuring a user-centric control point (the user controls what, where, when and if the data is being sent).

The "wow" effect

The use cases certainly sound unlimited. Think digital health care and the $20B stimulus package: whether I am accessing my doctor, hospital, lab or pharmacy Web sites, I can now authenticate across all health service providers and authorize the audited transfer of personal health records back to my locker. Think rich media content: I can now purchase digital music, movies, or books across multiple e-tailers and have the bits (or maybe just the digital rights) sent back to my locker. Think payment and billing: please, send all my purchase and online statements back to my digital locker.

Yes, we can! With data portability and OpenID, a simple file vault can grow into a much more compelling personal identity service. And who knows. With security and private storage, we may even have a real business model!

PIP Update: a free secure digital lock box

2009-02-17T17:24:04Z

The PIP team just released a new feature on Friday: a secure digital vault to store your most personal documents online. Think of it as a digital lock box in the cloud to store copies of your most important documents online (deed of trust, will, passport, property pictures for insurance, etc).

Since, these documents are your secrets, all files are encrypted using key management best practices. To increase security, access to the vault requires two-factor authentication. If you already have a VIP token, simply link it to your PIP account. For our most cost conscious PIP users, we offer a free mobile version of the VIP OTP token. It can be downloaded to your phone here (I use the iPhone Beta version that will be available soon). Once strongly authenticated, the vault opens (Flash is your friend) and you can begin to upload files.

The activation process is really straightforward, and our usability team has done a lot of work on the user interface. Moreover, it is free to all PIP users. So, try the new features and tell us what you think. By combining OpenID, strong authentication, password vault and secure storage, the PIP is getting one step closer to realizing VeriSign's long term vision of a user-centric identity service that will enable and protect our digital self.

FaceBook Joins OpenID: Goodbye OpenID, Bonjour Open Connect?

2009-02-12T21:53:54Z

Great news for OpenID aficionados, the largest ~~identity~~ social network is embracing OpenID. With 221M users, one could easily conclude that OpenID has just received the stimulus package that it needed to finally achieve critical mass. But, what does it really mean for OpenID? While we are all looking forward to the day FaceBook becomes both an OpenID provider and relying party, the initial impact is more likely to be a significant change in the OpenID user interface. As shown, here and there, is clear that from a UI standpoint, Google and FaceBook are converging in terms of how to achieve login and exchange of personal data across relying parties and social networks.

While FaceBook will likely integrate OpenID as the "alternate" login method for FaceBook Connect, Google and its followers will do the same with Open Social and Google Friends Connect (in the case of Google, you may also get the friendly Yahoo!, MySpace and AOL followers). By becoming the alternate login method (but a more obscure one), the risk for OpenID is to be relegated to the level of OAuth and SAML as authentication protocols without any consumer brand recognition. Alternatively, OpenID may rise above the "open stack" plumbing to become the network mark that ensures interoperability across the FaceBook and Google networks. That my friend, is of course politics, but with a Facebook on board, it would appear that this week, this old chimera of federated Internet identity may have made a significant leap forward.

New PIP Feature: Add any Site to your 1-Click Sign-in List

2009-01-12T02:24:03Z

This week, the PIP team is releasing an improved version of the 1-click sign in. The great news is that PIP users are no longer restricted to our small initial list of supported sites. Indeed, you can now add any of your favorite sites to your 1-click list (with a few caveats such as pure flash sites). Over time, we will monitor the most popular sites being added and we will include them to the default 1-click list.

This is great news for PIP users, especially for the non-US community who is no longer limited to our choice of sites (I must confess that our initial list was very US-centric). By the way, kudos to the PIP engineering team: doing all this in JavaScript without any browser plug-in is a real engineering "tour de force". Also, the team also improved the UI and performance of the bookmarklet window. Note that you will be prompted to re-install the 1-click bookmarklet.

The Internet is getting easier. Happy 1-click navigation!

My OpenID New Year's Wish List

2009-01-04T06:15:32Z

2009 promise to be a pivotal year for OpenID. So far, industry adoption has been strong with consumer powerhouses such as Google, Yahoo!, Microsoft and MySpace backing up the technology. At the same time, consumer adoption remains limited to early adopters. Meanwhile, FaceBook, the identity provider of choice for 160M consumers is promoting its own alternative in the form of Friends Connect, creating the risk of balkanization. With a new year beginning, a recently augmented leadership, and high competitive stakes, the moment felt opportune to put together my 2009 wish list for OpenID.

Execution: The Separation of Concerns

My first wish is organizational. The OpenID foundation board host really bright and passionate people. Folks are committed to the success of OpenID. Across the board, there is also a strong willingness to do what is right. Nevertheless, execution on key priorities appears to remain sluggish at times. Perhaps, the foundation needs a more effective way to drive execution. There, it could borrow a page from what larger corporations do extremely well. They separate governance from execution. The OpenID board is governance. It needs to articulate priorities, but create focused committees around these priorities. Then, it needs to empower the best elements in the board and the community to drive the outcome. Sounds obvious, but by enforcing that separation of concern and empowering people to work in parallel, I think the OpenID foundation could gain tremendously effectiveness in 2009.

Identifier: Email Address as OpenID, at Last!

In the last two years, I have been regularly in a position to explain and pitch OpenID to Financial Institutions, Mobile Network Operators and MSOs. By experience, I have learned that OpenID detractors and alternate technology providers will always bring two detrimental arguments against OpenID: user experience and security. The usability argument can be summarized as follows: "How much marketing dollars do you plan on spending to teach consumers to type a URL instead of a user name?". The answer is simple and usually reminiscent of Omer Simpson's catch phrase. So, in 2009, let us do ourselves a favor. Let us remove the leading argument against OpenID. Let us make email addresses first class OpenID identifiers. It is not about alienating URLs as identifiers, it is about enabling email addresses alongside URLs, because millions of consumers already regard email as their primary online identity and an email address is already their user name across so many sites.

Security: OpenID Security Analysis and Best Practices

The second argument that OpenID detractors will always bring up is security. In fact, there is a lot of confusion around the security of OpenID as a protocol and its propensity to phishing as a user experience. There again, detractors and naysayers are having a ball. What we need there is a neutral third party study that explains why OpenID is a sound protocol, and describes the best security practices to deploy the technology. None of the companies involved in the foundation should be responsible for such study. Instead, the board should sponsor an independent and reputable third party security lab to lead the security review. Once it is complete, the foundation should publish the results of the security analysis, alongside the recommended deployment best practices.

Branding: Establishing the "OpenID Network Mark"

Everyone agrees that OpenID needs to emerge as a brand that consumers can recognize. Similarly to Visa for payment, Dolby for music and Gore-Tex for rainwear, OpenID ought to become the "ingredient brand" for identity. The reason the OpenID brand needs to emerge is that we need a "network mark" that transcends all the identity silos. Very much like consumers know that their bank card will work when they see the Cirrus network logo on an ATM machine, consumers need to know that their identity will work on a Web site that carries the OpenID network logo. A network mark has a simple yet powerful meaning. It does not matter whether the card is from Bank of America, Wells Fargo or WAMU, it just works with this ATM machine. It does not matter whether the identity is from Google, Yahoo! or MySpace, it just works with this Web site.

In the OpenID brand lies the one big problem. Although a strong OpenID brand will prove to be good for everyone in the long run (by creating ubiquitous interoperability, Visa helped card issuing banks make more money than they would made on their own), at this time, none of the large consumer companies involved in the OpenID foundation have any incentive to promote another brand than their own. Therefore, the foundation needs to create a forcing function. My recommendation would be to leverage its ownership of the OpenID intellectual property to enforce the network mark. Let us keep OpenID free to all, but let us require everyone who uses the technology and benefit from the free IP to display the OpenID logo.

Avoiding the balkanization of identity to achieve the broadest possible user-centric federation network is what is at stakes in 2009. Undeniably, this is the year when OpenID can get from good to great. The OpenID network will rise or OpenID will become another commodity protocol encapsulated in the stacks of more fragmented identity networks (such as Google Open Connect or FaceBook Connect). It is up to us the OpenID community to make things right by seizing the opportunity. As we say in the valley, it is all about mere and simple execution. Yes, indeed, this coming year ought to be a critical and exciting year for Internet identity and OpenID.

Identity and Security in a World of SAAS: the Case for Federation

2008-12-14T00:38:59Z

As you probably heard, a significant network security incident happened last week. A large phishing attack was perpetuated against CheckFree.com. Millions of consumer identities have presumably been stolen. Consumer impact aside, the attack warrants our attention because it shows the new challenge that identity and access management faces in a world of outsourced network services. For businesses, the lesson is as clear as it is scary. In a world of SAAS, you do no longer control your security. Your home-grown access policies have become irrelevant. As an enterprise, you have lost control of your network protection. Unfortunately CheckFree and millions of their consumers learned this lesson the hard way last Friday.

So what happened? In a nutshell (you will find a very good explanation here), the bad guys first used a spear phishing attack to capture the credential that would allow access to CheckFree's account at Network Solutions. Once the first phase was successfully completed, the attackers logged into the Network Solutions account to map CheckFree's name server to theirs own servers, located in Ukraine. Following the DNS compromise, the bad guys eventually launched a large scale phishing attack against CheckFree's customers, potentially allowing the compromise of millions of consumer identities.

Because, the DNS servers were hosted at Network Solutions, CheckFree's security was totally bypassed. As a matter of fact, it did not matter what level of security checkfree.com implemented. Their policies had become irrelevant. Had CheckFree deployed risk-based authentication, two-factor authentication, smart card with biometry or anything else to their millions of consumers, it would not have mattered. Checkree's consumer identity protection had become as vulnerable as Network solutions name and passwords.

The lesson is brutally clear. In a world of SAAS, a world where most enterprises are increasingly living in, corporate access policies are no longer enforceable. As an enterprise, you can raise your identity game, but your game is now as good as your weakest SAAS vendor (granted that in this case, Network Solution provided a mission critical Internet service by managing the IP addresses of CheckFree's name servers). When it comes to security, if you do not control access policies (authentication and authorization), the truth is that you do not control anything. Furthermore, you may now longer be in compliance since most regulations like Sarbanes-Oaxley require an enterprise to implement stringent policy, processes and audit to regulate employee and non-employee access to critical business information.

The DNS Cathedral and the Identity Bazaar

While the pundits scream for DNSSec deployment, the bad guys have already found a chin in our future Internet armor. Their message to us is simple: there is no point in securing the front door if the back door is to remain open. DNSSec is important, but not the panacea. Phishing will not go away unless we also work on strengthening identity and access management on the Internet. Last week attack makes this conclusion inescapable. Today, the Internet counts about 100 millions domain name. There are also hundreds of ICANN accredited registrars. Some are small companies, some are very large businesses. The world now understands that millions of businesses worldwide rely on these registrars for protecting their most precious digital asset: their Internet name. Does it mean that all the registrars of the world, large or small, need to change the way they authenticate users all at once?

Maybe, but a coordinated and more effective approach should also be considered. Time may be ripe for federated identity services, a new breed of cloud services that would make it easier for registrars (and SAAS vendors) to deploy stronger authentication; a federated identity service that provides choice of authentication and allow registrants to define authorization policies based on their own internal requirements and business needs. Instead of each individual registrar whose business expertise has little to do with identity management, a shared identity service trusted by the whole ecosystem could increase security for a much lower cost and complexity than point solution deployment. A cloud identity broker that provides additional authentication factors such device ID, certificates, one time passwords or smart card would have allow CheckFree to enforce two-factor authentication without Network Solution having to know or do anything.

Identity Brokers - Local Bootstrap Credentials - Locally Defined Policies

Software aficionados will always question the security of a centralized cloud identity service. Centralized identities present a risk. However, the risk of a centralized IDP can also be reduced by allowing domain name holders (the enterprise) to provide their own bootstrap credentials to the IDP. After all, small and large enterprises like CheckFree already issue trusted credentials to their employees. A cloud identity service that can also integrate with the enterprise would provide optimal security, accountability and flexibility. Simple yet effective security policies could now be implemented- for example, requiring that every employee access to Network Solution originates from CheckFree's internal IT network (think Kerberos to SAML). Such simple access policy alone would have defeated the Ukrainian attack from last week. Finally, had CheckFree already issued tokens or smart cards for remote access to its employee, a federated identity cloud service would have enabled their re-use to protect employee access to Network Solution.

Interestingly, the same week Google Facebook and MySpace launched their own competing solution for consumer federation, the CheckFree incident reminds us that the most urgent need for federated identity may not lie in the land of consumers but in the world of enterprise and B2B security. Undisputedly, the growth of cloud computing and SAAS exacerbates the need for secure identity providers. In that world, less OpenID, no FB Connect or MySpaceID; SAML tends to be the Lingua Franca. As the CheckFree incident demonstrates, the benefits of SAML federation are significant for enterprises. Compliance, security, and data safety are at stakes. Who know? As smarter attacks keep on emerging, SAAS federation and SAML identity providers may be the next big thing when it comes to securing cloud computing and digital identities on an increasingly wilder Internet.

Google's Smart OpenID Move

2008-11-04T00:29:14Z

There has been a lot of buzz around Google's OpenID announcement last week. First, because Google awkwardly decided to change the service end point discovery part of the protocol. The good news is that Google fixed their faux-pas fairly quickly. In fact, they had no reason not too follow the spec and alienate the OpenID community.

More significant and more interesting however, was Google OpenID departure from requiring users to use URL as OpenID identifiers. Instead Google wants to let users use their GMail address as an OpenID identifier. Using GMail addresses as OpenID is not only a justifiable way to improve the OpenID user experience; it is also a very smart move by Google in their quest to become the dominant Internet identity provider (IDP).

As a consumer, there is no doubt that using an email address is the obvious identifier. Email is to consumers what domain names and URL are to businesses: a natural identifier. After all, email is already my Amazon, Apple and many other sites login. It is the intuitive OpenID that any consumer will expect to type in any relying party login box. In the long run, not having to teach millions of consumers that they should type a URL instead of an email address will prove a huge win for OpenID. Too bad it took though it took the weight of one to move an entire community forward.

But the consumer is not the only winner here. I think Google will prove to be the other beneficiary. By making email addresses, the de-facto OpenID identifier, guess who is now more likely to become the identity provider of choice for millions of consumers? I would venture that those IDPs who are already providing millions of Web mailboxes to consumers, have just gained a position of strength. Coincidentally, Google, Yahoo! and Microsoft have quite a few of those under management! Of course, Yahoo! and MSN are well tame rivals as far as Google is concerned. No, to appreciate this chess move, we ought to look at the other guardians of our Web identity: the social networks.

So, by changing the OpenID user interface, Google is now in a position of strength vis-à-vis OpenID, forcing FaceBook further into a dead-end proprietary identity APIs strategy. The beauty is that Google did not even have to force a button or any branding on relying party web sites. The choice of identifier alone will make it easier for consumers to choose Google over FaceBook. I would now expect to see Google drive OpenID integration across all APIs related to social networks and mobile (we already know that OAuth/OpenID integration is next) at full speed.

So, for sure, with Google and email, OpenID has gained a lot this week. At the same time, the idea of a federated Web identity network dominated by the three large Web mail providers is becoming more real. Nevertheless, consumers should rejoice. This week was a big step towards less name and passwords, and in the end, more convenience is certainly no evil.

DECE or the Digital Content Cloud: Last Chance for DRM.

2008-09-11T19:01:20Z

For almost 18 months, we have been working with the Movie studios on creating a blueprint architecture for rich digital media (a fancy name for digital movies). The concept falls in what I like to call the "big idea" category. The goal is to create an Internet eco-system that re-creates the user experience and commercial success of the DVD: an industry standard shared across all content providers, all retailers, and all device manufacturers.

Like the brick and mortar DVD, this new Internet DVD will share a common brand recognized by consumers worldwide; it will provide a common format with interoperable digital rights protection technology; The Internet DVD will be backed by a common usage policy that is consistent across movie studios and will provide a simple user experience for consumers. Believe it or not, we all believe that these lofty goals are achievable and we even have a proof of concept to support our irrational exuberance. You will just have to wait for this effort to become consumer facing to see it.

If successful, this "Internet DVD" standard, will allow any consumer to purchase and download movies from any online store (pick your favorite ecommerce store), and view it on any device (a PC, an IP TV, a mobile device). From the studios standpoint, the concept of the Internet DVD arises from witnessing the Internet speed transformation of the music industry: loss of sales driven by pirated content, emergence of music distribution silos where the lack of interoperability eventually leads to the elimination of rights protection altogether, a risk that the movie industry is not willing to accept without a good fight.

A key requirement of the "Internet DVD" is to enable DRM interoperability, which is timely considering the focus of regulatory instances, such as the European government. Of course, many will argue that the easiest way to achieve DRM interoperability is to get rid of DRM altogether. My theory (a lonely one in the blogosphere) is that a cloud-based approach is not only technically viable to create DRM interoperability. It is also the only possible approach to creating a user experience that resonates with consumers.

Indeed, the key to making the Internet DVD an insanely great consumer product is both open standards and a cloud approach. The cloud services (including OpenID-based identity services, of course,) are essential to mask the complexity of dealing with multiple DRM systems, multiple content formats and multiple retailers. The other trick is to leverage the cloud to provide additional functionality that the silos dismiss today: rights locker, perpetual ownership and the separation of the purchase from download experience. That last one is likely to resonate with marketers as the Internet DVD will encourage impulse by without forcing consumers to be tethered to a 10GB pipe.

Of course, the proof is in the pudding. We still have a few challenges ahead. We need to prove that the industry can come together and create a compelling joint offering for digital entertainment. We also need to prove that the hereditary vices of DRM can be hidden from consumers by using a cloud-based approach. The immensity of such challenge aside, the immediate lesson to me is that the cloud can be a disruptive force when it comes to new product design. The cloud creates new dimension that can challenge common thinking and alter the status quo, like the well-established thinking that DRM is a dead end. One thing is sure. The movie industry is a fascinating world and it will be fun to see how the cloud allows it to reinvent its biggest commercial success. So, say hi to the Internet DVD, it may be coming to a computer near you very soon now.

The New Personal Identity Portal (PIP):

2008-08-21T16:53:35Z

Today, we are releasing a brand new version of the Personal Identity Portal (PIP). With support for two-factor authentication, the PIP remains a strong OpenID provider as VeriSign remains committed to the broad deployment of OpenID across the Internet. Beyond OpenID, the new PIP also includes some unique identity management features. As the user-centric identity movement reaches beyond authentication and attribute exchange, we wanted to evolve the PIP into an identity aggregation service that enhances control, convenience and security over personal data even when the data is scattered across non-interoperable Web sites.This theme of identity aggregation is going to remain an important product philosophy for us moving forward. Our first implementation focuses on personalization, convenience and security. This post provides a brief overview of the new features. For those of you who never read product description, you can sign up for a free PIP account here. For the more curious minds, please, read on, and let us know what you think.

Personalization and the Personal Identity Page
The Personal Identity Page allows you to aggregate public identities and presence across multiple Web sites under your OpenID. In my case, my personal identity page can be found at nico.pip.verisignlabs.com. You can see that I have chosen to aggregate my Blog, my Flickr pictures, my YouTube videos, and other personal links to provide a complete reflection of my public Web persona. With a Personal identity page, my OpenID URL now provides a simple way for people to find and discover my "aggregate me". Think of it as a modern version of public white pages. We have tried to keep it simple enough that it can be built within a few minutes, but rich enough to keep it interesting.
Of course, for many, the logical place to share their identity is their social network. For that reason, we have also created a FaceBook application. As shown below, the PIP FaceBook application lets you embed your "identity carrousel" into your FaceBook profile to share it with your friends.

Convenience and 1-Click Sign-in across any Web site
The PIP 1-click sign-in service may be one of the most interesting new features. The service aims at enabling single sign on across all popular Web 1.0 and Web 2.0 sites (whether they support OpenID or not). We have devised a client-less authentication solution that only requires one single click for you to log in across your social sites (FaceBook, Yahoo!, Google, MySpace...), your travel sites (TripIt, Expedia, United...), your financial site (Wells Fargo, E*Trade, ....), almost any of your sites, really! Think of it as a password vault in the cloud. Think of it as a universal single single-sign-on Web service. Since, we did not think you wanted to give all your names and passwords to VeriSign, we have designed it in such a way that VeriSign never sees your actual names and passwords (we only receive and store an encrypted form of them and you keep the secret key for yourself). Of course, you still need to log into the PIP (that is the one required login). Unlike most existing solutions out there, there is no client to install, only an optional bookmarklet to save in your browser (the install is drag and drop in Firefox and Safari and we have an automated install script for IE6 and IE7 users). It works on Windows, and the MAC. It will work in your 3G iPhone too, making OpenID and general login really user-friendly in a mobile environment (more in my next post). Note that the Beta 1-click service only supports 70 popular Web sites at this point. If your feedback is positive, we will add many more, so once again, let us know what you like and what you dislike.The bookmarklet is also a nifty navigation tool. When you are not on the login page of a Web site, it triggers a small navigation window (see above). The window displays the list of all the Web sites that you have registered with the 1-click sing-in service. Simply click any of these links; you will navigate to the site and be logged in automatically. No more URL to enter, no more name and passwords to remember or type, only your PIP OpenID!

Security and Free Digital certificates
Since the 1-click vault security hinges on the PIP authentication, we wanted to offer you a broad choice of strong authentication solutions. Last year, we enabled VIP credentials (OTP tokens) within the PIP. This year we added a free layer of security that does not require any hardware. Indeed, we are giving our PIP users a free VeriSign certificate to secure their PIP account. Certificates and PKI have often been blamed for poor user experience. Therefore, we decided to create a new user interface for logging in with a certificate. Instead of issuing an identity certificate, we are issuing what we call a "browser certificate. A browser certificate is anonymous. It does not contain any information about you. Think of it as an opaque token that you link against you PIP account to protect it (it provides a second authentication factor: "something you have". Your PIP login name and passwords remains your first authentication factor: "something you know"). You can install these certificates on Mac and Windows (as many as you need). The certificates are free. We are still working on the iPhone (we have encountered a few challenges with certificates with the iPhone Safari, but with a little help from Apple, we will get there).

Voila!
The whole PIP team has worked hard during the last 8 months to bring you all this new functionality. We are really excited to release this new version of the Personal Identity Portal to our growing PIP community. We hope you will enjoy using it as much as we enjoyed building it. Feel free to drop us a note, report bugs and make product suggestions. Our support email is support@verisignlabs.com. We are looking forward to your feedback!