With the creation of the OpenSocial Foundation, the DataPortability Group (they'll need a Foundation soon), the Information Card Foundation and of course the now established OpenID Foundation... I'm getting "foundationed" out.
I wonder if the community couldn't do something closer to OASIS and have one over arching Foundation with sub-groups working in each of these important areas. The IPR could be consistent for all the groups, but each group would have it's own "board of directors" and control the results of specifications and other efforts.
All the different focuses are important, and new areas will arise as the identity layer grows across the internet. However, convincing "management" to join multiple different organizations is a deterrent to participation.
Thursday, March 27, 2008
Monday, March 24, 2008
Is AOL exploiting OpenID?
Today, Michael Arrington (of Tech Crunch) posted an article posturing that AOL (along with Microsoft, Google and Yahoo) are attempting to exploit OpenID by being OpenID Providers (OP) and not becoming OpenID Relying Parties (RP). I attempt to address a number of issues in this post below.
In addition to not being true (about AOL), the above statement doesn't make sense. There is little value in having to store a user's identity credentials and then verifying against them when it comes to identity management. A company's decisions around when to require a local account and when to accept 3rd party identities revolves around the risk of the resources being offered. If the 3rd party identity provider (in this case an OP) is trustworthy, then it's much preferrable to "outsource" the identity verification to that provider rather than deal with the security and privacy issues of storing credentials. Plus with OPs that support one-time-passwords, hardware tokens, etc, a RP can gain the benefit of strong authentication without having to implement the infrastructure themselves. So, it's not "all gain, no pain". In fact, requiring people to create account is PAINFUL (both for the company and for the user).
Actually, I would disagree with this statement. The point of OpenID is to provide a user with a few identities (maybe one) that they can use at many web sites across the internet. This means that many sites will just be RPs and won't need to support the OP parts of the protocol. I do agree that the next wave of adoption will be more sites (large and small) becoming RPs.
For AOL, being an RP is important because it allows more people to use our services without requiring them to create yet another account with another password to remember. The more people that visit and interact with AOL services, the more successful AOL will be. Both ficlets and Circa Vie are OpenID relying parties and a substantial number of their users are 3rd party OpenIDs.
I have two things in regards to this quote. First, it is not AOL's strategy to "own the identity of as many Internet users as possible". I've already stated why above. Second, there is another element that is key to the "Internet's very serious need" and that is "trust". Some call it reputation. It's great that OpenID 2.0 is open, distributed and secure (from a data-on-the-wire perspective). However, relying parties need to assess the business risk in regards to the resources (e.g. free storage, free domain names, free email) they are providing. With OpenID 2.0, it's possible to implement an OpenID Provider that claims using strong authentication to verify the user but in reality is not even requiring a password. This means anyone can sign up at any RP without needing an account at the OP. The RP needs to determine if the business risk to this kind of abuse is acceptable.
I believe it is this later case that is causing the larger companies to move more slowly when it comes to enabling all their services to 3rd party OpenIDs. Note that not even at Live Journal can you create an account with a 3rd party OpenID. What you can do at Live Journal is leave comments and be added to friend's lists.
[Disclaimer: For those that don't already know, I work for AOL.]
"By becoming Issuing parties, AOL and Yahoo hope to see their users logging in all over the Internet with those credentials. But they don’t accept IDs from anywhere else, so anyone that uses their services has to create new credentials with them. It’s all gain, no pain."
In addition to not being true (about AOL), the above statement doesn't make sense. There is little value in having to store a user's identity credentials and then verifying against them when it comes to identity management. A company's decisions around when to require a local account and when to accept 3rd party identities revolves around the risk of the resources being offered. If the 3rd party identity provider (in this case an OP) is trustworthy, then it's much preferrable to "outsource" the identity verification to that provider rather than deal with the security and privacy issues of storing credentials. Plus with OPs that support one-time-passwords, hardware tokens, etc, a RP can gain the benefit of strong authentication without having to implement the infrastructure themselves. So, it's not "all gain, no pain". In fact, requiring people to create account is PAINFUL (both for the company and for the user).
"Issuing parties make their user accounts OpenID compatible. Relying parties are websites that allow users to sign into their sites with credentials from Issuing parties. Of course, sites can also be both. In fact, if they aren’t both [OP and RP] it can be confusing and isn’t a good user experience."
Actually, I would disagree with this statement. The point of OpenID is to provide a user with a few identities (maybe one) that they can use at many web sites across the internet. This means that many sites will just be RPs and won't need to support the OP parts of the protocol. I do agree that the next wave of adoption will be more sites (large and small) becoming RPs.
For AOL, being an RP is important because it allows more people to use our services without requiring them to create yet another account with another password to remember. The more people that visit and interact with AOL services, the more successful AOL will be. Both ficlets and Circa Vie are OpenID relying parties and a substantial number of their users are 3rd party OpenIDs.
"It’s time for these companies to do what’s right for the users and fully adopt OpenID as relying parties. That doesn’t fit in with their strategy of owning the identity of as many Internet users as possible, but it certainly fits in with the Internet’s very serious need for an open, distributed and secure single log in system (OpenID is all three)."
I have two things in regards to this quote. First, it is not AOL's strategy to "own the identity of as many Internet users as possible". I've already stated why above. Second, there is another element that is key to the "Internet's very serious need" and that is "trust". Some call it reputation. It's great that OpenID 2.0 is open, distributed and secure (from a data-on-the-wire perspective). However, relying parties need to assess the business risk in regards to the resources (e.g. free storage, free domain names, free email) they are providing. With OpenID 2.0, it's possible to implement an OpenID Provider that claims using strong authentication to verify the user but in reality is not even requiring a password. This means anyone can sign up at any RP without needing an account at the OP. The RP needs to determine if the business risk to this kind of abuse is acceptable.
I believe it is this later case that is causing the larger companies to move more slowly when it comes to enabling all their services to 3rd party OpenIDs. Note that not even at Live Journal can you create an account with a 3rd party OpenID. What you can do at Live Journal is leave comments and be added to friend's lists.
[Disclaimer: For those that don't already know, I work for AOL.]
Wednesday, March 05, 2008
Authentication for clients
Today AOL relaunched the OpenAIM initiative. One of the key parts of this effort is supporting authentication for clients (whether those clients are native code or FLASH/AIR/Silverlight/etc). To enable this we added a 'clientLogin' API to our OpenAuth suite of APIs.
This support is to enable a user experience that comfortable to AOL's existing members. If a user installs a client application, it is expected that any authentication that is needed is done through the client. To secure this method we use the password and a session key (transfered via SSL) to sign all requests from the client application. This ensures that all valid requests are coming from a client where the user entered their password. In addition, all API calls are monitored for abuse.
For the signing mechanism we used the OAuth signature base string method. However, given that we already had parameter names (in existing APIs) that map to the OAuth parameter names, we used the existing parameter names in favor of the OAuth names. Otherwise, the logic is the same.
I realize that from a pure privacy and security perspective, the OAuth flow of "popping" a browser and having the user only enter their credentials at the "owning" IdP is better. However, for many of our customers this is an unexpected user experience. clientLogin enables the desired user experience.
This support is to enable a user experience that comfortable to AOL's existing members. If a user installs a client application, it is expected that any authentication that is needed is done through the client. To secure this method we use the password and a session key (transfered via SSL) to sign all requests from the client application. This ensures that all valid requests are coming from a client where the user entered their password. In addition, all API calls are monitored for abuse.
For the signing mechanism we used the OAuth signature base string method. However, given that we already had parameter names (in existing APIs) that map to the OAuth parameter names, we used the existing parameter names in favor of the OAuth names. Otherwise, the logic is the same.
I realize that from a pure privacy and security perspective, the OAuth flow of "popping" a browser and having the user only enter their credentials at the "owning" IdP is better. However, for many of our customers this is an unexpected user experience. clientLogin enables the desired user experience.
How times change
A couple nights ago my teenage son was on the family computer “working” on facebook.
I should have known.
So I asked him “How are your friends doing?” (trying to be a good parent and get my kids to talk:) ).
My son answers “I'm trying to help Judson and Samuel be friends” (names changed to protect the innocent).
I ask, “Why, are they not getting along? Did something happen?” (rather surprised).
“No”, he answers, “they can't find each other on facebook.”
I should have known.
Subscribe to:
Posts (Atom)