Category: AOL

OpenID Thoughts

Trust (using the word here in a broad, abstract way) has been one of the strongest reason for the OpenID adoption. The spec does not require for OPs and RPs to get together and discuss key exchange, business value, liability issues, attribute data and so forth. OPs and RPs work independently of each other and as long as they adhere to the core specification, things just work.

Trust has also been one of most critiqued area of OpenID. As an RP, why should I outsource my user authentication to someone I have never even interacted. Call me crazy but I don’t feel like accepting users from Iwillstealyourusers.com. There have been suggestions that it should be acceptable for the low-value transactions. But then, there is no definition of a low value transaction. And beauty value lies in the eyes of the beholder.

All that led to the discussion of OpenID whitelist. One might argue that it’s against the spirit of OpenID. Anyone should be allowed to run an OP without contacting all the RPs to be added to their whitelist. On the other hand, it gives a cozy feeling to the RPs to only have a handful of trusted OPs (which by the way there is no way to determine; but that’s a topic for some other day).

One of the ways the concept of whitelist can manifest itself is for OPs to provide an ‘OP Button’ for the RPs. Yahoo did exactly that couple of months ago. It’s good for the users since they don’t have to remember their OpenID URL and the user experience is much better. Most of the RPs (at least the current crop) won’t mind accepting users from Yahoo. I figured sooner or later, Google and Microsoft will join the OP list (along with AOL), have their own set of buttons that RPs will happily accept;practicality will take over; the OpenID identifier as we know today will go under the covers; the small OPs will cease to exist. We’ll all wait for a couple of years and then start over.

Except…ClickPass launched last week with it’s own button. There are still some discussions on the what and the why of ClickPass. But beyond that, it does paint the picture of what the future RPs might look like – a Nascar billboard (with buttons and branding from every OP)…or something like this building.

dish

This is where the discussions get into discovery, which is a really hard issue to address.

  • This is how social news sites address this:

social bookmarking

  • This is how RSS Readers address this:

RSS

  • This is how SAML address this : Okay…let’s not go there :-)

The common pattern – a Nascar billboard.

So… David and I spent some time talking about this. This is still a ‘thought in process’ but I wanted to write it down before I get heads down into the RSA preparations.

The requirements:

  • The user shouldn’t need to type the OpenID identifier.
  • There should be one OpenID button. Not two. Not three.
  • The RPs shouldn’t need to host the Nascar billboard (and hence add an icon every time a new OP comes on board).
  • The user should be in control of his identifier and who to share it with.

IMHO, this is how it should work from a user’s perspective:

  • I signup with any OP of my choice. Or setup my own OP.
  • I enter my identifier once. On a client side component. Either a browser extension/plugin or a desktop client.
  • I visit the RP and click on the single OP button. It invokes the client component and verifies if I want to share my idenifier.
  • On clicking okay, it redirects me to the OP and rest of the OpenID flow resumes.
  • If I don’t have the extension or haven’t picked an OP yet, it redirects me to a central (OIDF/Community hosted) Nascar page.
  • The central Nascar page should host the OPs logos/buttons. It should allow me to pick my OP and redirect me back to the RP.
  • Additionally, the central Nascar page should allow me to signup with a listed OP (redirect);add the selected OP to my client component; And allow me to enter my own OP(text field).
  • No registration should be required by the Nascar page.
  • What should be done to be listed on the Nascar page? – Well..that’s where some of the existing work that’s being done by SpreadOpenID, OpenIDDirectory and Nat comes into play.

Thoughts?

As I write this, I do notice the similarities with the CardSpace flow. Ergo…it will be interesting if MS (now member of OIDF) adopts OpenID in the client.

Identity Mashup

A while ago Paul and I had a conversation about how the neighborhood kid teases his daughter Ophelia Pauline Edna Nicki Irene Daphne for the lack of certification. And how I was concerned that my son, San Ashish Mator Lester  gets picked since his friends think he is fat and difficult to understand.
It’s refreshing to read that compared to Higgins, San…Lester is considered sexy. It’s about time our kids hook up. In case you are interested,  Inspired by Intellectual Women in December is planning to have a speed dating event. There are couple of other dating services, Open Source Invitation for Singles  as well as Contrasting but Cordial where San…Lester normally shows up.

However, the word on the street is that Ophelia…Daphne doesn’t believe in pair wise relationship or trust. Ours is a conventional family. It’s not like we are asking for exclusivity but at least some kind of white list will be nice.

adult77-502.jpg

OpenID Whitelist

AOL announced yesterday that they are going to start accepting 3rd party OpenID logins. This is a great milestone since I believe this is the first big RP to do so. However, they also adopted the concept of ‘OpenID Whitelist’ which brings up a couple of interesting questions:

  • Is this the right thing to do? OpenID strength lies in it’s ‘distributed nature’ and the ability for the user to control his own identity. Only allowing ‘selected providers’ negates that. I personally believe that “if OpenID has to move up the value chain then ‘whitelisting’ is inevitable”. However, I mentioned this in a barcamp a few months ago and most of the participants disagreed. They thought it’s against the spirit. The ability to run their own OP is why they like it more than the other identity systems. At the end of the day, it has to be the RP’s decision. AOL approach, however, might set a precedent for other RPs .
  • The second issue is a follow up on the first one – ‘As an RP, how do you decide which OP to add to your whitelist?’

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? There can be some objective analysis for the OPs:

  • How long have you been in existence?
  • What form of authentication do you support?
  • Do you support https?
  • What’s your account recovery process?
  • What’s your privacy policy?
  • How do you handle spamming?
  • Do you support Attribute exchange?
  • Do you support PAPE?
  • What’s your registration process?
  • Are you OpenID compliant (wait…that’s another big topic)?
  • Do you charge your users?
  • Do you have a cool logo?

So far the adoption for OpenID has been driven by the IdPs/OPs (it’s pretty apparent by the imbalance in the number of OPs and RPs). However, I believe the OP Reputation suite has to be driven by the RPs. They are closer to the problem and have a real need to filter out the unreliable OPs. I hate to volunteer others (well..not really ?), but it will be great if the AOL folks can take this initiative.

Image | WordPress Themes