Friday, August 17, 2007

AOL OpenID provider whitelist

So there has been a lot of discussion regarding AOL's support for 3rd party OpenIDs and the fact that currently AOL has a whitelist of approved OpenID providers. A number of good points have been raised.

Kim Cameron writes...
What would make $$$ for AOL? To get my pretty eyeballs over there PDQ. What’s the best way to make that happen? Make it easy! Acquire new eyeballs! Acquire new eyeballs! Acquire new eyeballs! From anywhere and everywhere!

The secret? Auto-create an account on AOL no matter WHAT credential a user employs to get there. You need this anyway to manage their profile. Then get the user transparently to great experiences and start ringing up those eyeball seconds.

I fully agree with Kim that eyeballs are the desired commodity. In fact, that is the whole reason AOL is implementing open standards and allowing 3rd party identities. However, I do believe that accounts cost money (or at least can cost money depending on what that account is allowed to do at a service provider). Take a picture sharing site for example. The picture service will provide some amount of space for each account (this is true of email providers, etc). The picture service could charge for the space in which case the “real” accounts would be easily distinguished but most sites these days are trying the “free and paid by advertising” business model. Also, another indirect cost of an account comes from whether the account can publish content. Spammers love to create accounts for the sole purpose of posting one or two messages. They don't care that they are spinning through zillions of accounts. So yes, AOL is looking to get as many eyeballs as possible, but doing so carefully for this initial release.

Ashish Jain writes...
As it turns out, SignOn.com is not in their initial list. I talked to the AOL folks and they promised to add it during their update next week. Fair enough. However, this model isn’t scalable. Given the distributed nature of the protocol, it doesn’t seem right for IdP/OPs and RPs to individually contact each other to maintain this list. Isn’t there a need for an OP Reputation, a.k.a. qualification, a.k.a certification suite that the RPs can leverage?

Jeff Bohren writes...
In OpenID, there is very little perceived risk in being a provider. If a user compromises your site and uses your site to authenticate to a relying party as someone else, there is really very little consequence to you. After all you don’t have any agreements with any specific relying parties. Why not be a provider, if there is so little risk involved?

Being a relying party however is a different matter. If someone compromises a provider and falsely authenticates to your relying party, they are misusing someone’s resources. The sensitivity of these resources would make the difference between allowing unrestricted OpenID or white list controlled OpenID.

Ashish and Jeff both make great points. The crux of the issue is that all the risk is assumed by the relying party. That means the relying party needs to be able to detect “fraud” and take appropriate action. This could be done through a number of mechanisms like a “Provider” Reputation service or “fraud” detection infrastructure. The OpenID model is similar to the email model. Anyone can stand up a SMTP server and send mail. It's the receivers of the mail (ISP or individual) that have to filter the spam. In order to learn from our implementation and fix any bugs, we decided to take a cautious approach at first.

I would say this approach is actually very common in the Web 2.0 community. How many sites starting out are by invitation only? Do they do that to create buzz? Well maybe... but I suspect that the biggest reason is that it limits their exposure to invalid/spam accounts.

Finally, Carsten Pötter writes...
Is this the positive signal to send out to the community? Is there even a strategy at AOL? It seems like there is not much support for OpenID from within the company. But I may be wrong and see things too negative but I am actually really disappointed. :(

Well... I hope it is a positive signal to the community:) AOL is the first major provider to support OpenID as a relying party. As to strategy, yes there is one. It's one thing to implement the OpenID RP protocol. It's another to have all the associated infrastructure in place to detect and protect against “fraud”. As was pointed out earlier, the relying party assumes all the risk in the OpenID protocol. We are actively working on that infrastructure and process so that in the future we can remove the whitelist.

Wednesday, August 08, 2007

The lowered expectations of web applications


I find it interesting that consumers continue to put up with more and more “bugs” in the software and appliances we use. Today, in trying to publish my last post, I had to try 3 times to get blogger to accept the entry, including getting the wonderful page to the right.

While hardware appliances are better, I run into the same thing with my wide area wireless broadband connection. The first trouble shooting step is to reboot the wireless unit to see if that solves the problem.

Then just recently after getting back from vacation, I found that my satellite TV DVR service had been deactivated. When calling customer service to get it re-instated, it took the representative a couple tries to get it working. He finally had to first de-provision my DVR service and then re-activate it.

I guess the “benefit” for technologists is that we don't have to work so hard to build good products ;-)

Cardspace & Service Invocation

I got thinking about Cardspace the other day and it struck me that Cardspace does a great job of authenticating me to the relying party, but the relying party can't use that authentication for service invocations on my behalf.

For example...
  1. User browses to the relying party (RP) and is prompted by Cardspace to authenticate
  2. User selects one of their cards (that they've previously used with the RP) and is logged in to the site
  3. Next the RP wants to import the user's AIM buddy list in order to enhance the user's experience at the site (e.g. find other users who also use the RP)
  4. The RP either requests AIM credentials and uses a back-channel API call to authenticate the user separately, or it redirects the user to AIM to authenticate
  5. AIM validates the credentials and returns a service API token
  6. The RP uses the service API token to request the buddy list
  7. Note that the user now has two different and distinct authentication sessions (one with the Cardspace or Managed STS and one with AIM)

Now it would be nice if the RP could use the existing authentication “session” with the user (as represented by the Cardspace token) without forcing the user to re-authenticate to AIM. Of course, the RP has no way of knowing whether the token it has is valid at AOL, nor probably, how to transform the token it has into a token that is valid at AOL. I suppose that if the token is a SAML token, then the RP could look at the issuer of the token and check to see if it is the AOL STS and from that try to use the token at AOL. The problem for the RP is that it might need to interact with many different services. What kind of claims does the RP request of Cardspace in order to get a token with the desired capabilities (e.g. service invocation with either Google or AOL)?

In order to solve this problem, it is very common in today's web experience for relying party A to request relying part B's authentication credentials in order to provide a service to the user. However, I always feel very nervous about giving relying party B's authentication credentials to relying party A. As the number of identities that consumers have to manage shrinks, the overlap of an authentication session across multiple relying parties grows. The identity meta-system should allow for the re-use of the authentication session across multiple relying parties as approved by the consumer.

One workable model, though somewhat inefficient, is for relying party A to request a service invocation token from relying party B. Using OpenID as the authentication protocol, the flow goes something like this...

  1. User browses to relying party A (RPA) and enters their OpenID to login
  2. Relying party A invokes the OpenID authentication flow redirecting the user to their OpenID Provider (OP)
  3. The user authenticates to the OP and is redirected back to RPA
  4. RPA requests a service token from relying party B (RPB) using a browser re-direct
  5. RPB requests an authentication of the user via their OP
  6. Since the user is already logged into the OP, this authentication step could be “seamless” to the user
  7. RPB creates a service invocation token for RPA and redirects the browser back to RPA
  8. RPA requests the data from RPB using the returned service invocation token

All the front-channel redirects make it easy to get the user's consent as necessary. However, depending on the bandwidth of the consumer's internet connection, and the physical locations of RPA, RPB and OP, there can be some significant performance implications.