Category: OpenID

draft.blogger.com betas OpenID for blogger

Blogger.com now supports OpenID on its beta site.  I have to congratulate the blogger.com team on the user experience they've created.  This is not necessarily their final kick-at-the-can, but I like what they've done so far.

Blog owners have a simple radio-button selection to determine who can comment: 

 

From then on, when someone visits the blog as a user and wants to make a comment, they are given the choice of how to identify themself.  Choose “Any OpenID” and you are given the chance to enter one.  Click on that, and you are redirected to your OpenID provider.

Here's what it looked like for me.  I wanted to congratulate the team for their great work, so I filled out a comment form like this:

 

Then I pressed “Publish Your Comment” and got this:

That's because I use myopenid.com, which for me is phishproof because of its great Information Card support (in other words, no password is involved and no credential can be stolen).

That's it folks.  I pressed send and got:

Why is this implementation so good?  Because it doesn't torment you, doesn't make you set up an account, doesn't make you create a password you don't need, and doesn't nag you to join Blogger when that isn't in the cards.  And it puts full control over the kinds of credentials to accept into the hands of the bloggers  themselves. 

This is the kind of experience I have envisaged and have been waiting for.  I think it is a sign of things to come, since many other sites are looking at the same concepts.  There is going to be a “conflagration” when people start to “get it”.  Just look at the comments.  There could be a lot of people who do join Blogger just because they've been handed a carrot, not given the stick.

One last aside on the low-friction thing.  Once I've gone through the dance above, I can continue to post at Blogger.com and all other sites with which I've established relationships – without further authentication.   That is very powerful.

MyOpenID.com supports Information Cards

If you use OpenID, you are propably running software developed by the gang of “Internet ninjas” at JanRain (yes, I've been there, and they actually do all wear black silk kung “foo” robes).  Besides writing software, JanRain runs one of the largest independent OpenID services: MyOpenID.com.  Today Jan Rain's Kevin Fox announced they had reached a major milestone:

The JanRain OpenID team is pleased to announce Information Card support has been added to MyOpenID.com

What is an Information Card?

What can I do with it? With a self-issued Information Card you can sign-in to MyOpenID, as well as sign-up and recover your account, without ever having to enter your password. Anywhere on MyOpenID that you can enter a password will now allow you to use an Information Card instead. With the addition of Information Card support MyOpenID is able to offer another solid option for people wanting to protect their OpenID account from phishing attacks and remember fewer passwords.

We were able to work with Microsoft’s Mike Jones and Kim Cameron who have both been long time proponents of OpenID  + Information Card support.

As noted by Kim Cameron “Cardspace is used at the identity provider to keep credentials from being stolen. So the best aspects of OpenID are retained.” While one of the less desirable aspects (confusing user experience) has been improved for someone using an  Information Card to login to their OpenID provider.

Support for Information Cards has been growing as more software projects implement the technology. It is important to note that this technology is being supported by many other organizations besides Microsoft. Information Card support is available for Windows platforms (Vista / XP) as well as Mac OS X and Linux.

Mike Jones beat me to the punch in heaping well-deserved praise on the Jan Rain group:

The JanRain team has done a fantastic job integrating account sign-up, sign-in, and recovery via Information Cards into their OpenID provider. I’m really impressed by how well this fits into the rest of their high-quality offering.

There’s another kind of integration they also did that makes this even more impressive in my mind: connecting their new Information Card support with their existing support for the draft OpenID phishing-resistant authentication specification. This is another significant step in fulfilling the promise of the JanRain/Microsoft/Sxip Identity/VeriSign OpenID/Windows CardSpace collaboration announcement introduced by Bill Gates and Craig Mundie at the RSA Security Conference this year. Because of this work, this sequence is now possible:

  1. A person goes to an OpenID relying party and uses an OpenID from MyOpenID.com.
  2. The OpenID relying party requests that MyOpenID.com use a phishing-resistant authentication method to sign the user in.
  3. The person signs into his MyOpenID.com OpenID with an Information Card.
  4. MyOpenID.com informs the relying party that the user utilized a phishing-resistant authentication method.

This means that MyOpenID users will be able to get both the convenience and anti-phishing benefits of Information Cards at OpenID-enabled sites they visit and those sites can have higher confidence that the user is in control of the OpenID used at the site. That’s truly useful identity convergence if you ask me!

Congratulations to all.

We need a spectrum

Stefan Brands runs off in the wrong direction in his recent treatise on OpenID.  Who really needs a “shock and awe” attempt to bonk the new OpenID “cryptographic primitives” back into the stone age?

It's not that you shouldn't read the piece; even though subtlety is not its strong suit, it brings together a lot of information about a threat model for OpenID.

The main problem is simply that it misses the whole point about why OpenID is of interest.
Continue reading We need a spectrum

Linkage with CardSpace in Auditing Mode

As we said here, systems like SAML and OpenID work without any changes to the browser or client – which is good.  But they depend on the relying party and identity provider to completely control the movement of information, and this turns out to be bad. Why? Well, for one thing, if the user lands at an evil site it can take complete control of the client (let's call this “extreme phishing”) and trick the user into a lot of evil.

Let’s review why this is the case.  Redirection protocols have two legs.  In the first, the relying party sends the user’s browser to the identity provider with a request.  Then the identity provider sends the browser back to the relying party with a response.   Either one can convince the user it's doing one thing while actually doing the opposite.

It’s clear that with this protocol, the user’s system is “passive”. Services are active parties while the browser does what it is told.  Moreover, the services know the contents of the transaction as well as the identities and locations of the other service involved.  This means some classes of linkage are intrinsic to the protocol, even without considering the contents of the identity payload.

What changes with CardSpace?

CardSpace is based on a different protocol pattern in which the user’s system is active too.  Continue reading Linkage with CardSpace in Auditing Mode

Including the whole spectrum of use cases

Mathew Martin, who writes Mostly Mr. SQL, clearly detests PKI certificates more than almost any living person.  He finds CardSpace guilty by association in a piece called GRRRR!  CardSpace.  What a useless steeming pile…

Ok. Cardspace/Infocard is like OpenId.  Password-less access to websites (or password-fewer access).

BUT

1. You must use SSL.  Even if you just want to secure your application against your clueless neighbor.  That is a minimum of $40.

2. You must decrypt the response on an account with NTFS access to the private key.  The NT Network Service account is not likely to have read access to the private key on a hosted account.  Good luck explain how and getting co-operation from your hosting provider.

3. Decryption must be done under FULL TRUST.  Many hosted accounts only let you run in medium trust and don’t let you create COM+ dlls, put stuff in the GAC, etc.

[Items 2 and 3 might not even be a good idea.  If the world at large manages to use your web application to maliciously download your SSL cert, I suppose they could do something evil, like pretend they are you]

4. To get rid of the “the website isn’t secure for banking or ecommerce” you have to spend $1000 on an EV SLL cert.  Oh, sure, pocket change.

5. And who is issuing managed cards? I can get an SSL based cert from Thawte that says I am the person that controls my email account, but I can’t find anyone who issues managed infocards anywhere.

I’ve about realize that I–a computer profession and programmer, will not be able to implement InfoCard/Cardspace in any form, not for my blog, not for my hobby website, nothing.  Either one has $1040 and ones own entire server or nothing.

If only the top 10 biggest websites can overcome the hurdles posed by infocard, what we are going to see is 5 websites accept infocard and everyone else (mom & pop websites) continue to use passwords and user ID’s. InfoCard will have a minimal impact on how authentication is done.

This is going to drive small websites into using OpenId.  Consumer will rapidly gain a few dozen OpenId cards.  The rising ubiquity of OpenId–which doesn’t try to be a waterproof authentication method–will take over the world, relegating InfoCard to “that way you logon to Live.com services”.

Come on Microsoft, when are we going to be able to run CardSpace/Info card in “real world” mode?

[Thanks to Self-issued.info for the logo]  [Actually, I take that back, it is a Microsoft trademark. The purple box is has a substantial amount of IP self legislation that goes with it.  According to MS’s lawyers, I am currently in violation of usage guide lines for the icon.  Let’s see how Microsoft silences critics of InfoCard.]

Let's start with the CardSpace requirement that a relying party support SSL.  I agree with Mathew that requiring use of SSL and PKI is overkill for the type of blogging and hobbyist use cases he describes.  While my identityblog certificate is fairly inexpensive (thanks to godaddy.com), the extra cost associated with it at textdrive (which hosts my system) is around $100.00 per year because of the need to have a dedicated outward facing IP address.  I don't mind the cost too much, since I know there are people who will hit on my site and I like the extra protection.  But this really isn't appropriate for everyone. 

This underlines the fact that identity and the identity metasystem involve a continuum of use cases and technologies – and we have to embrace the whole continuum.  By making certificates mandatory, we cut the continuum in half.  Luckily, we can fix that before we get into the wide deployment phase.

My conclusion is that rather than hard-wiring the requirements for identification of a relying party into the identity selector, we should have allowed each identity provider to decide what minimal requirements were appropriate. 

This ends up having advantages both at the low value and high value ends of the spectrum. 

For example, a bank's IP might decide to only release information to a relying party with an Extended Validation (EV) certificate.  If so, CardSpace would not illuminate the associated information card if an EV certificate were not in use at the relying party site.   [EV certificates are only granted to companies or other organizations after they follow an extensive procedure for proving their legitimacy.]

Meanwhile, a blogging reputation identity provider might be happy to release reputation to any site the user proposes, certificate or no certificate.

Of course, the relying party is always free to use a certificate and gain the extra protection that provides.

This change is actually part of CardSpace 1.1 – which people should be able to start experimenting with very soon now.  When combined with the release of great toolkits for all the important languages, I think this will bring quite a bit of lift-off.

As for point 4), let's look at what the CardSpace advisory actually says:

I think there's a big difference between “a major internet business” and a site doing “ecommerce”.  When I buy a tee-shirt from Mathew I don't expect him to be EV.  If he were trying to sell thousand dollar cameras, I would feel differently.  I'd want him to either be well identified, or to work through a site like eBay that would provide another way of establishing his reputation.  And in this case, I want to make sure I'm really talking to eBay, so once again would like to see an EV cert.

I don't think any “major internet business” or bank will have any difficulty whatsoever covering the cost of an EV cert.  The idea of using the superior certs came directly from them, since they're the ones whose users get phished.  I don't understand why, given his earlier rant against the poor validation proceedures in conventional certificates, Mathew rails against our support for EV.  Part of his earlier criticism of EV certs is that the browser doesn't show the meaning of the cert properly, a problem CardSpace has solved. Consider this recent Anti-Phishing Working Group report:

As for who is issuing managed cards, you'll be seeing many outfits doing it as we move toward the InfoCard tipping point.  We're in the sockets and ecosystem phase of Information Cards, but I can tell you many players get the potential of the technology and are integrating it into product.

As for OpenID versus Information Cards, I don't see them as opposites.  Go to signon.com today and you'll see it supports use of Information Cards for OpenID authentication.   This is nice because it gets you InfoCard safety along with OpenID long-tail support. Going forward, I think you'll see most OpenID vendors supporting OpenID managed cards that work with OpenID sites.

As for the Information Card Icon, our intention is that it be available to everyone who supports the technology.  There has been pushback on the language around the icon, and we'll be figuring out how we can get this thing right.  In the meantime, I wouldn't be worried about using it on a teeshirt or to criticise us – but I would be worried about using it at a phishing site. 

Catalyst Interopathon reveals sea change

Here are the logos of the projects participating in the Information Card Interopathon at the Burton Group's Catalyst Conference. Beyond that, people told me about at least half a dozen new open source projects (each with a unique mission) that are sitting in the wings getting ready to go public.  I'll try to keep you posted on these. 

We had a rehearsal for this a couple of months ago at Internet Identity Workshop, but something has changed since then:  many of the players seem to have made strides in getting concrete about how the technology would be used in their products.  That's the key.

According to the press release:

Participants include projects groups Eclipse Higgins Project, Internet2 Shibboleth Project, The Pamela Project, Ian Brown (OpenInfoCard), XMLDAP, and SocialPhysics and vendors BMC Software, CA, FuGen Solutions, IBM, Microsoft, NetMesh, Novell, Nulli Secundus, Oracle, Ping Identity, Sxip Identity, VeriSign, and WSO2.

The demonstration will be centered on a photo sharing application and will show the breadth and maturity of user-centric technologies by executing a variety of information card-based component capabilities including:

  • Protocol and wire format interoperability
  • Card format interoperability
  • Policy interoperability
  • Platform interoperability 

The interop event was organized by OSIS and identity commons and hosted by The Burton Group.  Thanks to all involved.

Bandits strike at BrainShare

Incredible news from Dale Olds’ VirtualSoul at Novell:

This week was Novell’s Brainshare conference. It’s a big deal for Novell folks and it’s a great event. It gives us a place to show off new technologies like the emerging Internet identity systems and some of the recent work that we have done on the Bandit team.

Our most significant demo this year was shown during the technology preview keynote on Friday. The whole series of demos is interesting — I especially liked some of the Linux desktop stuff — but if you want to just skip to the infocard stuff, it starts at about 40 minutes into the video.

For those who may want to know more detailed information about what the demo actually does, let me give some background information here:

There were 3 new open source components written by Bandits and made available this week:

  • A fully open source, cross platform identity selector service was contributed to Higgins. Written in C++, this Higgins ISS runs as a daemon (no UI) and provides core infocard selector service: it accesses multiple card stores, enumerates available cards, matches cards based on requested claims, and interacts with the appropriate STS to get a token. It is almost complete on support for personal cards, with an internal STS, etc. The real deal.
  • A UI process for the Higgins ISS. It is currently written in C#, runs on Mono, and leverages much of the management UI of the CASA component of Bandit.
  • A new OpenID context provider was contributed to Higgins. This context provider plugs into the Higgins IdAS and allows identity data to be accessed from any OpenID Provider. What this means is that, with no change to the Higgins STS code (since the STS uses IdAS), we could set up a demo such that infocards can be generated from any OpenID identity. In other words, using the Higgins STS and the new OpenID context provider, I can access any site that accepts infocards with my openID account.

So what Baber showed in the demo:

  1. A fully functional, native infocard selector running on the Mac.
  2. He accessed a shopping site with an infocard generated from an OpenID account. Put some things in the cart and logged out.
  3. Baber switched to a SUSE Linux Desktop machine. Fully functional infocard selector there as well. Accessed the same site with an OpenID infocard and see stuff in his cart from the Mac session.
  4. Goes to check out. The site asks for a card with different claims, needs a payment card.
  5. The Higgins Infocard selector supports multiple card stores. In this case Baber selects a credit card from a card store on his mobile phone via bluetooth.
  6. He authorizes a (hypothetical) payment and the online shopping site (the relying party) only gets his shipping address and an authorization code from the credit card.

It’s a simple demo, and easy to miss the number of technologies and interactions involved, but this is the kind progress that we have been working towards for a long time.

The Bandits are happy and tired.

Mozilla Links interview with Kevin Miller

Here is the Mozilla Links interview with Kevin Miller on his CardSpace selector, which will be included as an extension for Firefox 3. 

CardSpace, is Microsoft’s identity management system, a way of reducing the hassle of having as many identities (username/password credentials) as services we use and is already listed as a requirement for Firefox 3

Kevin Miller who has released Identity Selector, a Firefox extension that adds CardSpace support, tells us what his extension does and what identity management in general is about and what can users expect from this and other alternatives currently in development. For the record, Kevin notes he doesn’t work for Microsoft.

Mozilla Links: What exactly CardSpace is and how it works?
CardSpace is the method of implementing what Kim Cameron calls an Identity Metasystem. I would describe an Identity Metasystem as a protocol definition, or a pattern for secure identification on the internet trying to solve three problems:

  1. Phishing attacks
  2. Lack of trusted identity
  3. Proliferation of personal information

I don’t think we need to discuss phishing attacks. By now everyone should be familiar with them.

The second point, lack of trusted identity, is a bit more difficult. Web sites seeking to authenticate users have very few good options. They may require credit card numbers, which are verifiable. However, most users are reluctant to give their credit card numbers to just any site on the net. They may require a digital certificate, but these are difficult for the average user to maintain and verify.

For consistency with the documentation, I will refer to web sites as Relying Parties (RPs). I will refer to the users as users, although the Microsoft documentation calls them subjects. Please keep in mind that the users could be individuals, companies, or other computer systems. The RP need not be a web site. It could be a Windows client, a web service, or nearly anything.

The third point, proliferation of personal information, is a side-effect of the second point
first two items, and also contributes to identity theft. Because the RPs require users to register, they typically ask for a large amount of personal information, whether they need it or not. They may be selling this information, or they may be using it for marketing purposes. Or, they may just be collecting it because everyone else is and they think they might need it in the future. The problem for the users comes either from the sale of this information, or in the compromise of the servers (or laptops) on which this information is stored.

Now, the Identity Metasystem goes the distance on resolving all these issues.

  • Users now have easy-to-manage cards (InfoCards), instead of difficult to manage certificates.
  • The RP can ask for information relevant to the security level of the site.
  • For simple web sites, they may allow a self-generated card. This might be typical for many news sites where the company only asks users to register. Instead of typing the information into a form on the website, the user can self-generate a card and use it at multiple sites.
  • If the RP requires real authentication, they may accept cards from a number of valid Security Token Servers. These are third parties that host cards for users. The third parties must be trusted by both the user and the RP. This is similar to the concept of escrow. The user and the RP do not need to trust each other as long as they trust the third party.
  • The RP publishes the claims required for access.
  • The user decides what information to deliver. If the RP is asking for too much, the user can decline.
  • The user doesn’t have to fill out endless web forms.
  • The RP can customize the InfoCard request.
  • The user can customize the InfoCard response.
  • The RP can choose any available server implementation.
  • The user and site can agree on any Security Token Server.
  • The user can choose any Identity Selector.

All of these components can be provided or consumed in any language, browser,
or operating system, as long as they support the necessary components of the
Identity Metasystem.

This system directly answers points two and three, above, and indirectly reduces phishing attacks. It is also hoped that the trend will be for users to hand out less information, and the RP to ask for less. For example, consider two companies sharing information.

  • Company A has an information library that Company B wants access to.
  • Company B is willing to pay for the information, but doesn’t want to have to administer a list of user accounts. They also don’t really want to tell Company A the names of the employees accessing the data.
  • If Company A and Company B can agree on a common Security Token Server, Company B can simply provide valid InfoCards that indicate the user is an employee of Company B. The user can have access to Company A’s library without divulging any other information.

This is a bit of a contrived example. A real-world example may be a bar. The bar must make sure that you are of legal age to get in. The mechanism that most use now are driver’s licenses. In addition to your age, the license contains medical conditions, name, address, and description. Add to this the fact that some bars are now photographing licenses and storing the data. This means that now you are at risk of identity theft just to enjoy a night on the town. In an InfoCard world, you could simply provide an InfoCard validated by the government STS, and the bar would know that you are of legal age. No further information given or at risk.

Mozilla Links: How does CardSpace compares to OpenID, an open source identity management proposal?

There is only the most superficial comparison with OpenID. They both use third party sites to validate users. CardSpace, however, is all about authorizing and authenticating the user. OpenID provides only a unique ID (based on a URI). It does allow the third party to provide a variety of information, but does not provide the user an easy way to preview the information prior to each transaction. OpenID also relies on the honour of the implementers. There are no checks and balances to recover from a rogue provider.

CardSpace is designed to give both sides of a transaction (one or both of which may behave poorly given a chance) a way to verify the information requested and provided. Now, CardSpace won’t force an eBay seller to put your iPod in the mail, but at least you could get validation that you are dealing with a specific user.

Mozilla Links: What does your extension, Identity Selector, do?

My extension really does only a couple of things.

  • It parses the parameters representing the required and optional claims, and other key parameters.
  • It invokes CardSpace (or an alternative, such as Chuck Mortimer’s Identity Selector)
  • It passes the parameters from the web page back to CardSpace.

There’s a fair amount of validation, and some interfaces to allow developers to provide alternative implementations, but those three functions are the key pieces of the extension.

Mozilla Links: Why does Firefox need an extension to support CardSpace?

An extension is required in order to get the appropriate information from the browser and invoke CardSpace. Without the extension, Firefox has no mechanism to invoke CardSpace. We could theoretically generate some SAML code based on a web interface and hand that back to the relying party, but it would provide little benefit, at a large cost of effort.

CardSpace is hardened against attacks, provides a simple mechanism for choosing cards, and allows the user to verify the relying party. CardSpace also provides all the “plumbing” for handling and reading certificates, basic encryption, and writing SAML.

Mozilla Links: How much support does CardSpace have currently?

I’m not sure how many pages support this at the moment. The three I’m familiar with are the xmldap.org site, Kim Cameron’s sample page, and the official CardSpace sandbox (which, unfortunately, only supports IE 7. I’ve talked to some folks about sorting that out).

Essentially, xmldap.org allows you to create a managed card (or select a previously used one from the site), and then use that card to log in. If you’ve logged in correctly, you get a page that displays the SAML code sent, and displays the claims in the InfoCard. It doesn’t look very flashy, but trust me, the code underlying all this is very cool, and exciting to us security types.

Thanks to Kevin. If you want to learn more visit CardSpace web site.

CardSpace is still pretty bleeding edge, but the software is starting to get out there.  Having Firefox support is great for users, since the identity selection experience is consistent across IE or Firefox or “desktop” applications.  With respect to OpenID, clearly my view is that OpenID and CardSpace have a lot of synergy, and the identity community is working hard to maximize this.

AOL and “63 Million OpenIDs”

First Microsoft's announcement with JanRain, SXIP and Verisign at RSA.  Now news that AOL has launched an experimental system and announced it will support the next version of OpenID. 

The world streams by at breakneck speed.  We're getting some real momentum on this convergence thing.  I hear the identity big bang coming towards us.  Here's a fascinating post by panzerjohn at dev.aol.com. 

Yesterday, I blogged about AOL's work-in-progress on OpenID. It generated a lot of positive commentary. I realized after reading the reactions that I buried the lead: There are now 63 million AOL/AIM OpenIDs. Anyone can get one by signing up for a free AIM account. This is cool.

To address Paul's concern in Please delete my aol OpenID: We definitely want the user to be in control of their online presence. At the moment, the OpenID URL at openid.aol.com redirects you off to an AIM Profile. That's not necessarily the long term experience, though I think it should be one of the default options. George Fletcher has pointed out that it would be even better if we could redirect people off to whatever page they wanted, as long as they could verify that they owned the page. My take is, if you don't actually use the OpenID URL, it doesn't really exist. The same way a Wiki page doesn't exist until you edit it. On the other hand, having people go in and kick the tires to uncover issues is exactly why we're talking about this. So let us know what you think.

Another important point is that you can point at the AOL OpenID service from any web page you own in order to turn its URL into an OpenID. The minimal requirements are basically that you have some AOL or AIM account, and that you add a couple of links to your document's HEAD:

link href=”https://api.screenname.aol.com/auth/openidServer” mce_href=”https://api.screenname.aol.com/auth/openidServer” rel=”openid.server” 

link href=”http://openid.aol.com/screenname” mce_href=”http://openid.aol.com/screenname” rel=”openid.delegate”

We added this to our blogs product in a few minutes minutes and it's in beta now. You can also support YADIS discovery which gives additional capabilities. See Sam Ruby's OpenID for non SuperUsers for a good summary.

The detailed status from yesterday's post:

  • Every AOL/AIM user now has at least one OpenID URI, http://openid.aol.com/screenname.
  • This experimental OpenID 1.1 Provider service is available now and we are conducting compatibility tests.
  • We're working with OpenID relying parties to resolve compatibility issues.
  • Our blogging platform has enabled basic OpenID 1.1 in beta, so every beta blog URI is also a basic OpenID identifier.  (No Yadis yet.)
  • We don't yet accept OpenID identities within our products as a relying party, but we're actively working on it.  That roll-out is likely to be gradual.
  • We are tracking the OpenID 2.0 standardization effort and plan to support it after it becomes final.

(I should clarify that I really work in the social networking / community / profile / blogging groups at AOL rather than the identity group per se. You can look to see what I actually do on a day to day basis over at my personal blog.)

This is amazing stuff.

Ignite Deux Seattle

Jackson Shaw knows as much about identity management as anyone.  I very much value his thinking.  If that weren't enough, there is that irresistable love of life that sweeps everyone into his energy field.  I think it comes through in his new blog:

No, it's not another French post from Jackson. Tonight I did something a bit different. I headed over to the Capital Hill Art Center in downtown Seattle to watch . There were 21 speakers scheduled including Scott Kveton the CEO of the folks behind . As you probably know, my buddy Kim Cameron is the man behind the curtain for Microsoft's CardSpace initiative ( I guess I should stop calling it an initiative – it is actually part of Vista now) and at the RSA conference Microsoft announced that CardSpace would be interoperable with OpenID.

I thought since Scott was going to present I might as well go over and see what all the hub-bub was about. The format of the evening was interesting in itself. Presenters had 5 minutes – only – to present their 20 slides! That's 15 seconds a slide. Scott was third presenter in the first volley of speakers. The first talk was from Matthew Maclaurin of Microsoft Research on Programming for Fun/Children/Hobbyists/Hackers. The second was from Elisabeth Freeman (Author in the Head First Series, Works at Disney Internet Group) on The Science Behind the Head First Books: or how to write a technical book that doesn’t put your readers to sleep. Then Scott was to speak.

First, I was shocked to walk into this “art space” that was packed to the rafters with people. Was I in the wrong place? Apparently not. On the website they stated the space would hold 400 people and it was jam packed. I had this vision of a few people sitting around some tables chatting. Not so! It was pretty cool; folksy; kinda out there but very engaging. Second, what was I going to get out of a 5 minute talk? Well, the speakers kind of had the pressure on them to make their points. The ones that I saw all got to the point quickly and they all engaged the with the audience, did their thing and got off.

Check out my photos on Picasa if you want to see the shots I took which included many from Scott's talk. So, what did I learn from Scott's talk?

  • OpenID is single sign-on for the web
  • Simple, light-weight, easy-to-use, open development process
  • Decentralized
  • Lots of companies are already using it or have pledged support
  • 12-15M users have OpenIDs; 1000+ OpenID enabled sites
  • 10-15 new OpenID sites added each day
  • 7% growth every week in sites

Scott predicts that in 2007 there will be 100M users, 7,500 sites, big players adopt OpenID and that OpenID services emerge. Bold predictions but something that is viral, like OpenID has a shot at it.

I have to say I was impressed. Scott finished up with a call to action that included learning more about OpenID at openidenabled.com. I'm definitely heading over there to learn more.

I'll report back.

p.s. Here's an interesting read:

Jackson just “gets” the potential for contagion into the enterprise – assuming we can use OpenID in the proper roles and with the right protections.  Corroborates for me the possible “charging locomotive effect”.   People shouldn't be caught looking the wrong way.

As for the numbers Scott threw out, I think they are very achievable.