March 18, 2008

The Business of Identity

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!"

July 26, 2007

Been a Busy Two Weeks!

Not too long ago I learned from my colleges in our Japanese office about things happening around OpenID in Asia. Working with Kentaro Sakamoto-san from VeriSign Japan, I managed to setup a trip coinciding with the ITU-T's Focus Group on Identity Management meeting, to Tokyo and Seoul. Working with Sakamoto-san and Andy Song from AhnLab, who I met at Web 2.0 Expo this year, we managed to setup a great trip where I spent about a week in Tokyo and 22 hours in Seoul. I had a lot of great meetings in Tokyo and in Seoul AhnLab hosted a wonderful half-day OpenID session. Slides from that are up on SlideShare at http://www.slideshare.net/daveman692/open-id-overview-seoul-july-2007 Thanks again to Sakamoto-san, everyone at VeriSign Japan, and Andy for being terrific hosts.


Last Saturday, we completed the upgrade of our Personal Identity Provider. All accounts have been automatically upgraded and the URL is the same at http://pip.verisignlabs.com. We definitely encourage everyone to come try it out as we believe it is the best OpenID Provider in existence! Not only does it have all of the features from the PIP we launched last May, but adds support for OpenID 2.0, the ability to manage multiple identities within one PIP account, integration with strong authentication via our VeriSign Identity Protection network, Information Card support as one way to help protect against phishing attacks, and our SeatBelt Firefox add-on which works with a variety of OpenID Providers.


This week I'm up in Portland OR at O'Reilly's Open Source Convention. Tuesday morning, Simon Willison and I gave a three-hour OpenID Bootcamp tutorial where we dove into many different aspects of OpenID from a basic introduction, to security concerns and solutions, to implementation details. Slides from the tutorial are also up on SlideShare at http://www.slideshare.net/daveman692/openid-bootcamp-tutorial. In the afternoon, Simon and I joined Tim O'Reilly during his Radar Executive Briefing where we gave an update on OpenID and discussed why as he said, "OpenID is taking the world by storm".


Ending the day Tuesday, I was awarded a Google-O'Reilly Open Source award which I posted more about on my personal blog. The award I won was for Best Strategist which refers to the work I've done over this past year at VeriSign within the wider OpenID community. Am certainly really honored to have been recognized, though am guessing I now need to work on raising my hacker geek cred again. :P

June 27, 2007

Updating the PIP

Today at the Burton Group's Catalyst conference in San Francisco during an interoperability event this evening, we'll be demoing a pre-release of our upcoming update to our Personal Identity Provider. This update touches every aspect of the PIP, providing the foundation for a identity management platform from VeriSign.

Over the next few weeks, leading up to the launch of this update, we'll be looking at the new features one-by-one in a series of blog posts. From a high-level, you can look forward to the following, but overall we've focused this release on security, control, and convenience:
  • Completely redesigned interface to make the PIP easier to use
  • Support for OpenID 1.1 and 2.0
  • Ability to create multiple identities managed from within a single user account
  • New "tag based" profile data management interface making it easier to view and sort all of your profile data
  • Ability to download managed Information Cards for each of your created identities to use with technology such as Microsoft's Cardspace
  • Strong authentication support via second-factor credentials from the VeriSign Identity Protection network, along with the ability to have a one-time PIN sent via SMS or email if you've forgotten your credential
  • Phishing-resistant logins using both VIP credentials and managed Information Cards
  • Full activity logging so you can have a complete picture of where you've used your identities
  • Integration with our own "OpenID SeatBelt" FireFox add-on to provide additional convenience and security protections when using OpenID identities from the PIP, AOL, Xlogon and MyOpenID.com


Check it out, but please realize that any accounts you create will go away in a few weeks when we fully transition the PIP. http://jpip.verisignlabs.com

June 22, 2007

Bringing Useful Scalable Security to OpenID

Considering our background, it shouldn't be surprising that when looking at OpenID we do so from a security and privacy perspective...in fact three of our other blogs are related to various security topics. While we have a lot more coming around the Personal Identity Provider related to security, right now I'd like to focus on a new extension to OpenID which is designed to help Relying Parties make informed decisions as to the reliability and strength of an authentication when an OpenID user logs in.


While we may be a security company, and certainly sell high-end solutions to three letter agencies, we also very much take the approach that security must scale with the requirements and associated risk of any transaction. Last year at the Digital ID World conference the former CTO of VeriSign Information Services spoke on a panel and clearly articulated this view; one authentication mechanism is not the solution for every problem.


What becomes painful on the Internet is that if I want varying levels of authentication at different sites, it means I have to remember different passwords, have different certificates, or have multiple physical devices depending on what I'm doing. Thankfully we've been able to help this with the VeriSign Identity Protection network where you can have a single hardware one-time password token and use it at a variety of sites...assuming each site is a part of the network. Overall this is still the fragmented view of the world; each site I visit creates its own password policies (don't even ask me the number of times I've had to call an unnamed bank I use due to forgetting how my two passwords work) as well as needs to choose to integrate with the VIP network for me as the consumer to benefit. So now how does this change in the decentralized world of OpenID?


The integration cost of OpenID as a Relying Party is extremely low, the technology is free and as Brian Ellin and I showed at Web 2.0 Expo the time commitment is also low due to a lot of great Open Source code out there which takes care of the heavy lifting. So now the RP has successfully integrated OpenID and removed the need for new users to create yet another password for their site, though they no longer have the control over the strength of a user's authentication process. The RP may be a simple Web 2.0 site and not care beyond that the user has a password, it may store marginally sensitive information and want to make sure that the Provider did something to help protect the user from common phishing attacks, or maybe it's a site which has truly sensitive information and wants to make sure that a second-factor device, such as a VIP token, was used.


With the OpenID Provider Authentication Policy Extension that I just published, this is now possible. This extension to OpenID 1.1 and 2.0 allows Relying Parties to express preferences around the authentication, such as "use technology which is phishing resistant" (stemming from the collaboration announcement at the RSA conference earlier in the year), for the Provider to inform the user of the request, guide them through the authentication process, and then inform the Relying Party what happened. By taking advantage of existing specifications from the likes of the National Institute of Standards and Technology (NIST), Providers can also convey information as to the strength of a password or combination of a password and digital certificate or hardware device used. While the high-end of the specification may be beyond the uses of OpenID today, it certainly fulfills the scalable security vision that we have. Through this specification not only can I now strongly protect my OpenID identity, but let others know that I'm doing so and truly take advantage of a reduction in credentials needed when browsing the web.


So please, take the time to read over the specification and chime in on specs@openid.net if you have any feedback.

June 18, 2007

OpenID IPR: Past and Future

Last week, VeriSign issued a "non-assertion covenant" which promises that we will not enforce essential patents against developers implementing the OpenID Specification. This continues the path that Sun Microsystems announced at the Internet Identity Workshop a few weeks ago with their own promise.


Like Sun, we apply the condition that developers refrain from asserting their own (or others') patents against any other OpenID implementation developer. This thus means that developers do not need to do anything active in order to get this assurance; they do not need to obtain any license from us; they do not need to even think about licensing; they merely need to refrain from attempting to enforce their own (or others') patents against any developer implementing OpenID.


In addition to making existing OpenID specification safe for developers today, as part of the OpenID Foundation we're working with the wider Internet community to develop an Intellectual Property Rights Policy for future OpenID work. On June 5th I hosted a meeting with representatives attending from AOL, Microsoft, the OpenID Foundation, SUN, Symantec, VeriSign, and Yahoo! where we discussed the proposed IPR Policy. While there certainly is more work to do in this space, notes from the meeting can be found on the OpenID wiki.

February 06, 2007

VeriSign, Microsoft & Partners to Work together on OpenID + Cardspace

This week should be an exciting week for the OpenID community, with lots of things happening at the RSA conference going on in San Francisco. Here's an announcement between VeriSign and some of its partners in the OpenID effort announcing plans to work with Microsoft on making OpenID and CardSpace interoperable:
Microsoft to Work With the OpenID Community, Collaborating With JanRain, Sxip, and VeriSign

JanRain, Microsoft, Sxip, and VeriSign will collaborate on interoperability between OpenID and Windows CardSpace(TM) to make the Internet safer and easier to use. Specifically:

  • As part of OpenID's security architecture, OpenID will be extended to allow relying parties to explicitly request and be informed of the use of phishing-resistant credentials.
  • Microsoft recognizes the growth of the OpenID community and believes OpenID plays a significant role in the Internet identity infrastructure. Kim Cameron, Chief Architect of Identity at Microsoft, will work with the OpenID community on authentication and anti-phishing.
  • JanRain, Sxip, and VeriSign recognize that Information Cards provide significant anti-phishing, privacy, and convenience benefits to users. Information Cards, based on the open WS-Trust standard, are available though Windows CardSpace™.
  • JanRain and Sxip, leading providers of open source code libraries for blogging and web sites, are announcing they will add support for the Information Cards to their OpenID code bases.
  • JanRain, Sxip and VeriSign plan to add Information Card support to future identity solutions.
  • Microsoft plans to support OpenID in future Identity server products.
The four companies have agreed to work together on a "Using Information Cards with OpenID" profile that will make it possible for other developers and service providers to take advantage of these technology advancements.

Dick Hardt, Sxip Identity
Kim Cameron, Microsoft
Michael Graves, VeriSign
Scott Kveton, JanRain


We will have some extended commentary on this development here over the next several days. Suffice it to say, this is a significant step toward the convergence needed in the identity space and I'm excited to see what will proceed from this effort.

See related posts on this subject:

August 22, 2006

Stopping blog spam

On average a new blog is created every second. One in five of these is a spam blog.


If you chart the growth of blogs and associated spam, you'll find that spam grows faster than proper content.


The spam blogs ("splog") are often made from stolen content and contain a large amount of URLs to drive traffic and search engine rank. Blog comment spam has the same purpose.


We often discuss how to get rid of this spam. Today's solutions mostly fail since techniques used to combat mail spam don't work well for blog spam: white- and blacklists have legal and moral issues and blog network propagation is different from email's store-and-forward topology.


In essence, this is a problem about trust. If there is a way to assign levels of trust to blog content and coments, then the recipient can automatically weed out the wheat from the chaff. An old trust solution is to use PKI, but that idea is difficult to implement in the blogosphere with its explosive growth. No PKI administrator can successfully handle hundreds of thousands of new certificates a day.


But public keys are still usable. We have created a system where we combine the power of public key cryptography to assert ownership of comments as well as content. The system can also tie into a PKI-like trust hierarchy if so desired by its users.


The system is specified on http://signedping.com, where you can find specifications as well as freely available source code, blog platform plugins, pass-thru services, etc., to start experimenting.


Initial response to the signedping has been very positive and we're working with some of the world's big blog producers to expand this concept. We'd love to hear what you think.

July 21, 2006

Ruby For Rails

Coming from a PHP and Perl world, I've been working on learning Ruby on Rails since I joined VeriSign. Started writing an app awhile ago, but ran into not really finding a good succinct guide of how to go about it. Do you write your own SQL or use migrations and why is there no good guide to a one-to-one-to-one relationship of models, views, and controllers versus what I see being done in Rails apps? I never really got into the books Agile Web Development with Rails: A Pragmatic Guide or Programming Ruby: The Pragmatic Programmers' Guide. Both seemed to expect I already had a solid basic understanding of Ruby and Rails. I found a variety of tutorials around the web, but each contradicted the last. I saw the review of Ruby For Rails on Slashdot a few days ago and it looked interesting. Bought it overnight off of Amazon, had it shipped up to Portland where I was for a few days, and dug into it that night; it seems to be the exact book I was looking for.


It starts with a nice introduction to Rails, why it exists, what it does, and how it builds upon Ruby. It tells me enough to get started, but not too much to confuse me. It gives clear recommendations of how to get started and explains why it is making the recommendations that it does. It starts with a demo application, building the database schema, the models, the controllers, and the views. Then two chapters later revisits the app and adds to it.


So I know I'll get back to the Agile Development and Programming Ruby books, but I really recommend you take a look at Ruby For Rails if you’ve been like me and frustrated about figuring out how to get started.

June 22, 2006

My Identity on Rails

Mike Graves and I will be speaking at RailsConf on Friday. I am looking forward to three fun filled days in the windy city.
I don't want to sound like I am a programmer or a seasoned developer. I am not! But I have always been a hacker -- dangerous enough to build functional prototypes but not quite at the level of building full fledged applications. Big fan of working prototypes where end users can experience the solution first hand rather than see it in powerpoint slides. As a product manager in my previous life, I preferred building working wire frame prototype than writing long and detailed PRDs or MRDs. I feel it is important to involve the end users early and often. And in many cases the end users are not expert programmers, product managers or QA testers. They cannot take the leap from a powerpoint slide to the real system that will be delivered on their desktops. I like to keep things simple, focus on the end goal and not get too wrapped up into the weeds before an idea is vetted out. I feel it is important to experiment with different approaches before settling on a long term road map. All this is easier said than done, especially when building a small working application is an effort measures in "weeks". That's where you do a reality check and start compromising. I was looking for a "week-end" solution to prototyping. And then I discovered Ruby on Rails a few months back...

Read the full content »

June 20, 2006

Forward Looking Design Decisions

I wrote about the Identity necklace and did get some comments about the post. From a user standpoint, it is clear that carrying different IDs around is an annoyance, but there seems to be wide variation in how willing people are in putting up the inconvenience. From an application standpoint, there is a significant difference between retrofitting an existing system to inter operate with other systems and designing systems from the ground up to co-exist with other applications and services. The former can be a much involved problem based on the complexity of the existing system. As for new applications in the early stages of their development, it is not too late to make interoperability as a "must have" design goal.

Read the full content »

June 19, 2006

The Identity Necklace

I often ask folks about the number of different user IDs and passwords they have for the various web sites they regularly visit. The answer is almost predictable -- more than 10 (always given with frown or an annoyed look). Some folks though sheepishly admit that while they have 10 different web sites they visit, they use the same password at all the sites. They also pull out their key ring and show me the 10+ loyalty card their grocery stores, pharmacy stores, gas stations gave them. Some are bitter about the hassle and the extra junk they need to carry with them. Some on the other hand don't mind the annoyance in carrying the cards around to be able to save cash on their next purchase!

Read the full content »

Introducing Kiran Dandekar

I'm happy to welcome my VeriSign colleage Kiran Dandekar to the Infrablog. Kiran's working with me on the team here that is building infrastructure and tools around open identity. He's become increasingly central on our team and visible in the community in building technical consensus and business momemtum around OpenID and our Personal Information Provider. We'll be adding a handful of team members to the Infrablog in the next few weeks.

 

Kiran's just your run-of-the-mill-MIT-PhD Boston Red Sox fan and family man. He previously did some cool stuff over at MicroStrategy before coming to VeriSign a couple years ago to help build our supply chain business.

 

Welcome Kiran!

 

 

May 16, 2006

Introducing the VeriSign Personal Identity Provider (PIP)

You're invited to visit and try out a beta version of an identity service we've provided. It's called the VeriSign Personal Identity Provider (“PIP” for short), and you can find it at http://pip.verisignlabs.com. The VeriSign PIP is designed to provide a “home base” for users who want use OpenID applications. Users who register with the VeriSign PIP get an OpenID – a URL they can use to login and authenticate at sites that accept OpenID. In addition, the VeriSign PIP lets you store profile information, and control how, when and with whom that information can be shared.


What Can I Do With The VeriSign PIP?

When you register at the VeriSign PIP, your user name is used to generate a unique URL for your profile. My username is “mgraves”, so my OpenID is “http://mgraves.pip.verisignlabs.com”. Now when you go to a site that supports OpenID, you can provide your OpenID, and use it instead of having to register separately for each site. For example, if you're reading a blog at LiveJournal.com, and want to leave a comment, you can go register for an account at LiveJournal, or just use your OpenID. Enter your OpenID URL, and the LiveJournal will authenticate you with the VeriSign PIP (or any other compatible OpenID server).


You can go to http://www.schtuff.com and create your own wiki with your OpenID. Zooomr is a photo-sharing site that will not only let you log in with OpenID, but will let you auto-register at the site based on information in your VeriSign PIP profile. The Zooomr sign up process is quick, easy, and based on a profile you control. OpenID is already enabled in MovableType 3.2, and plugins for Wordpress and other blogging tools are either available now, or imminent.


What Is Our Goal?

At VeriSign Labs, we see an opportunity to do what we do best – develop and deploy “intelligent infrastructure” -- for the blogosphere, the Web2.0 community and beyond. In the past months, we've noticed the growing energy and consensus around universal identity in general, and OpenID specifically. In addition to the pioneering applications that are available now for use with OpenID, there are a lot of exciting applications in the pipeline, from a wide variety of companies and developers.


The VeriSign PIP is a free service. So what's in it for us? We believe that providing free, quality infrastructure for the OpenID-enabled community – identity services that are friendly, secure and user-empowering – will help create an environment in which a rich variety of applications and services will appear and prosper. As this ecosystem evolves and matures, the free, basic services offered by the VeriSign PIP and other OpenID servers will be able to enable more complex trust relationships and higher value transactions. There's a need now for basic functions that will improve the quality of the blogosphere: authenticated blog comments, open reputation systems, personalized tagging, social media filtering, etc. Over time, as the installed base of enabled users grows and the application set available for OpenID-equipped users broadens and deepens, the VeriSign PIP will be able to validate credentials and claims for it users that facilitate “heavy duty” transactions: blog based auctions and payments, age-based verification for dating and social websites, verified residency for surveys, polls and voting, etc. In some cases, the credentials and claims VeriSign provides for its users will be a fee to the user. In other cases, the subscribing applications will pay us a fee for qualifying and enabling users to participate and transact in a trusted, reliable context.


Whats Next?

The goal of enabling user-centric identity is becoming more of a reality every day. But significant challenges remain; getting enough users and enabled applications spun up so that the ecosystem reaches critical mass is going to take a lot of work. We aren't application providers – we're all about infrastructure. What we can provide , and are providing, is a solid, safe, friendly resource for equipping users for the OpenID ecosystem. The VeriSign PIP is being opened up for use as a public beta now as a way to help encourage and accelerate development of OpenID-enabled applications and services.


The VeriSign PIP is not complete, by any means. As of this release, it's a good resource for getting an OpenID you can use and login to other sites with. The PIP provides a way to enter a lot of additional information to be stored in your profile, and some basic tools to organize and manage it. Applications that provide rich integration with the user's profile information are just coming available – they need identity servers like the VeriSign PIP to be available to make things work. I'll point these applications out here and discuss how they work as they are made available over the next weeks and months.


The VeriSign PIP joins a number of other OpenID servers that are available now to facilitate OpenID authentication. The next big step forward for the VeriSign PIP will be to provide smooth auto-registration and trusted profile exchange between users and applications. If you are interested in establishing your own online identity – one that you control, and one that works with an ever-increasing array of Web2.0 apps – I hope you'll check out the VeriSign PIP, and give it a try. If you are an application provider, we're taking our first steps on the infrastructure side of things, and hope that our service will become a enabling resource for your OpenID-enabled applications.


Resources

  • The VeriSign PIP FAQ

  • OpenIDEnabled.com – all sorts of good information about OpenID specs, servers, software and applications

  • OpenID.net – the original and authoritative site for the OpenID specification

  • YADIS.org – the discovery protocol used with OpenID

     

May 12, 2006

Working Toward the Bang

I was at Internet Identity Workshop 2006 last week, and because it is a conference focused solely on the subject of identity, it served as a good opportunity to take stock of the situation. To be sure, a lot of progress has been made in the last year; if I have my facts right, YADIS – the lightweight discovery protocol for specifying capabilities for URLs – was conceived at last years IIW and has made it all the way to a 1.0 specification this spring. The ecosystem has come a long way towards the issue of identity in the past year too.

 

At Esther Dyson’s PCForum in Carlsbad, CA last month, the theme for the conference was “Erosion of Power: Users in Charge”. As with all forward-looking conferences there’s always an element of wishful thinking and projection in the conference themes. From the myriad conversations I’ve had at PCForum, IIW2006, and everywhere else in the past few months however, the idea of universal identity – names, attributes and policies managed by the users themselves instead of as part of someone else’s application – has clearly emerged from ubergeek fascination to an industry opportunity to improve both user experiences and application quality for the Internet services.

 

What’s the Big Idea, Again?

The rationale behind universal identity is that traditional web applications – “walled gardens” that implement a robust user profile system – are:

  • complex to build
  • a headache for users to register for and use
  • “one-off” implementations that are generally unable to interoperate with other applications

 

As a result, Internet applications either need to be sufficiently large and commercially robust to support the implementation of a user profile system, or the application needs to avoid user identity altogether.  So we end up with a relatively small number of big applications like Amazon.com that implement a full user management system on one end, and a lot of “anonymous” applications like del.icio.us on the other end of the spectrum.  There are applications in the “middle class” – applications which incorporate user identity in a lightweight way, but these applications end up investing an inordinate amount of resources into user profiles, at the expense of focusing on the value the application is supposed to provide.

 

Universal identity affords the application developer a “plugin API” for managing users in an Internet application. Given a set of open, free identity standards and protocols, and the available infrastructure to support them, applications can integrate user identity and profile information in a way that is:

  • much simpler to build than building it yourself
  • familiar and easy for users when registering with the application
  • interoperable with other applications – for free

 

Applications can harness the open APIs for universal identity, and quickly add the features and functionality needed to support user preferences and policy. In addition to incorporating user management into the application in a “component” fashion that eliminates the need to write it from scratch, the open APIs enable all enabled users in the ecosystem to quickly and easily register for the application. Over time, these APIs will provide an easy “on-ramp” for millions of equipped users who have IDs ready for use with applications that support the APIs.

 

Making It Happen

While the value proposition for universal identity has been largely accepted in the ecosystem now, there are significant obstacles to overcome. It’s a classic “double threshold” problem. On one hand if there aren’t sufficient applications that support universal identity, users won’t be motivated to sign up and configure their identities. On the other hand, if there aren’t enough enabled users in the system, application developers will have a hard time seeing the benefit of integrating with universal identity APIs, no matter how convenient they may be,

 

At VeriSign, we concentrate on delivering services that represent “intelligent infrastructure”.  In this space, we believe that one of the ways to help the ecosystem break out of the double threshold problem is to offer services and enabling infrastructure that will help bootstrap both the application and user community.  In talking with partners, customers, and stakeholders in the identity community, we’ve identified three resources that are needed to jumpstart the ecosystem for universal identity:

  1. An open, lightweight, comprehensive API for integrating with universal identity applications and service providers
  2. Available libraries and tools that implement the API in popular web development languages and frameworks
  3. An identity service that can serve as a solid, secure home base for users who want to create and manage their own online identities and profiles.

 

VeriSign has been working on all three of these items, and I’ll be announcing and discussing details of our efforts here in the coming days and weeks.

 

“The Bang?”

At conferences like IIW2006 and in forums, lists and discussions on this topic, the idea of the “Identity Big Bang” has emerged as a reference to the idea that once universal identity does reach critical mass, it will quickly begin to realize network efficiencies, according to Metcalf’s Law. Each new enabled user and application adds value to the ecosystem geometrically,  as opposed to linearly.   In a relatively short time, we might expect to see very broad adoption and integration with universal identity systems – a “big bang” that will unleash a whole new generation of applications, enabled and empowered by an common pool of users. For users, this “big bang” represents an important change in the balance of power between user and application. If universal identity becomes pervasive, users will be in control in a way they previously haven’t been; users will be empowered as “sellers” of their participation, which may include providing applications with basic personal information, demographic attributes, click stream and attention stream data, and tagging/reputation metadata.

 

Once a common practice and platform for universal identity is in place, applications that incorporate it won’t just benefit from easy registration. Applications that build on top of universal identity can be easily integrated as well: tagging, reputation, payment, professional qualification, social linking and a variety of other features can be overlaid on top of your application with minimal effort.

 

Will that produce a “big bang” – an explosion of innovation in internet applications? It’s easy to identify an element of hype in this phrasing – even on the Internet, the ecosystem doesn’t change overnight. However, although there’s a lot of hard work ahead for the providers in this space to get universal identity catalyzed, there’s good reason to see that it can and will introduce important new types of applications, transactions and online relationships.

 

March 31, 2006

Rails 1.1 Available

ActiveRecord gets a significant upgrade (polymorphic joins and bottomless eager loading for example) in the 1.1 release of Ruby On Rails. What's really impressive in this release though, is RJS -- the ability to write your JavaScript functions in Ruby. Rails was already a superior platform for writing Ajaxian web apps. With this release, the Ajax model stays the same, but you now have an elegant process for writing your JavaScript in Ruby.

I've only had the opportunity to get 1.1 installed and running on my personal machine, but it's clear from just a little exercise that 1.1 is going make a lot of teams that are humming along productively with 1.0 take a look to see when and how they can get 1.1 into their production platforms. I'm working on a couple Ajax things "the old way" -- Java back end and JavaScript front end -- and the new setup available from Rails now is going to make that hard to go back to.

February 20, 2006

Lightweight Signatures for XML

Check out this proposal published by Johannes Ernst of NetMesh. I challenged him a couple weeks ago to apply his skills at developing lightweight, straightforward solutions to the problems presented by XML Digital Signatures, which are too numerous to recount here. XMLDSIG is a powerful technology, but it's very heavy and quite complex, which works against its success in the marketplace, particularly in lightweight development environments.


Just as a gedankenexperiment for Johannes, we wondered what should be done if we wanted something besides XMLDSIG -- something much simpler and lighter -- for identity, publishing and social networking applications we've been looking at. Johannes idea is to forego XML canonicalization -- or transforms of any kind -- and simply sign a single node as a blob, signing the XML in a monolithic way, the way you'd sign a JPEG image.


The single element signing strategy won't work for a variety of existing and legacy XML document formats. But it may be that if one keeps the constraints applied in Johannes' proposal in mind, XML documents might be effectively designed to support this method. If so, it would create a much lower threshold for web apps to clear in order to support basic trust and cryptographic semantics in XML. Essentially, Johannes is asking what would happen if we did away with transforms.


In any case, if you're interested in this kind of thing, it's worth clicking over there to give it a read.

February 17, 2006

Sxip's Fourteen Requirements

Dick Hardt and John Merrells of Sxip recently published Fourteen Design Goals for web-based identity systems. As Dick says in his blog entry, these are offered with a nod to Kim Cameron's Seven Laws. I've pulled out the 14 requirements from the doc -- see the doc for more in-depth discussion:

Read the full content »

February 15, 2006

Comments?

Matt Mower brings up an issue that has come up a lot for me lately as we look for ways to tackle the problems of comment spam. I've looked at the solution offered by CoComment, and their approach pretty much convinced me that the blog comments, as they exist today, are a bad idea.

Don't get me wrong; I'm all for vigorous discussion, wide-ranging and free-wheeling. The idea behind blog comments is obvious and important. The implementation is just terribly flawed, however.

Read the full content »

Rails Does "Big Head" Apps Too

No sooner do I post about Rails powering the long tail of web apps then do I learn of Google's acquisition of MeasureMap (via DHH's LoudThinking blog).


MeasureMap is a Ruby on Rails app, and according to David Heinemeier Hansson, the first Rails app to get acquired in the Web2.0 era. Didn't even launch before getting acquired. Congrats to the MeasureMap team.


I'll be interested to see what happens to MeasureMap platform-wise as it gets grafted into the fabric of Google. But it serves notice that Rails isn't just about RAD, demos and weekend one-offs. There's a flurry of activity right now building heavy-duty Web2.0 apps like MeasureMap -- if you don't believe me, try and find a quality Rails developer for hire. Go ahead, try it.

The Long Tail of Web Apps

My colleague Kiran Dandekar has been doing something I've been doing lately: working with Ruby on Rails applications in the same way others work with PowerPoint, Visio, or Rational Rose. There's often a need to "sketch out" a web service, build some "wireframes" or "workflow diagrams" as a means to think through architectural and other issues, and also as a way to socialize the idea across the team. There are any number of tools available to facilitate this process, but Ruby on Rails is unique in its approach to sketching out a web application: build the web app itself.

I'll spare you the sermon on Rails; if you've tried it out, you don't need any convincing from me (and if you have been bitten by the Rails bug you aren't wasting time reading my blog, you're building web apps). If you're not familiar with Ruby on Rails, I'll just say this: Rails makes building basic, solid, functional web apps easier and quicker than anything else I've ever seen. By a long shot.

Read the full content »

Categories

Blog Tools | Blogosphere | Feeds | Identity | Miscellaneous | Ping | RailsConf | RailsConf2006 | RubyonRails | Tags | VeriSign |

Blogroll

Jeff Richards' Demand Insights

Web Security Blog

The Accountable Web

SSL Blog

Demystifying the Web's Secure Backbone

Powered by
Movable Type 3.2
Disclaimer: Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of VeriSign.

VeriSign Legal Notices

Read our Privacy Policy