Just a quick shout-out to Yahoo! for releasing in beta OpenID relying party support for Yahoo! Stores. Now new store customers can sign-in and purchase products using an identity they already have. Check out this blog post for more details.
Showing posts with label AOL. Show all posts
Showing posts with label AOL. Show all posts
Monday, August 23, 2010
Friday, August 06, 2010
Webfinger enabled for @aol.com
Being able to discover meta-data about an identity (via the identity's identifier) is an important piece of the Federated Social Web. Evan Prodromou recently wrote...
An important part of identity is addressability – having a machine readable address that computers and people can use to find you, and only you.As a way to enable "addressability" for AOL users, Webfinger discovery is now available for all email addresses in the aol.com domain. Discoverable information includes the identity's OpenID provider and profile URL.
Friday, March 12, 2010
OpenID 2.0 Provider support live @ AOL
I'm excited to announce that the AOL Identity Services team has fully deployed OpenID 2.0 Provider support. Directed identity flows are now enabled so just entering 'aol.com' into an OpenID field will start the authentication flow. In addition to directed identity, this release also supports "check immediate" flows, SREG, AX, UI (popup browser), PAPE (as required by the ICAM OpenID 2.0 Profile) and of course the ICAM OpenID 2.0 Profile itself.
We have also improved the UI making it much cleaner and easier to follow. One feature of this new UI is a page that allows the user to choose, when first visiting a new site, whether to use their public OpenID (http://openid.aol.com/<username>) or an opaque one. Of course, this choice isn't necessary if the user provides the relying party their full OpenID or the relying party specifically requests an opaque identifier (via PAPE policy). I'd really appreciate feedback on whether this "privacy" feature is helpful to users or just adds more confusion.
In addition to the existing SREG support, the same attributes will be supported via Attribute exchange. There is equivalent support for the http://axschema.org URIs but only partial support for the Information Card URIs as there weren't direct equivalents for all of the attributes. Here is what is currently supported.
Suggestions or requests for specific attributes are always welcome. One point of clarification regarding email addresses and verification. The current implementation defaults the email address to the user's AOL provided email address but does allow the user to change the value returned to the relying party.
While there is still a lot to do, it feels really good to finally reach this milestone.
We have also improved the UI making it much cleaner and easier to follow. One feature of this new UI is a page that allows the user to choose, when first visiting a new site, whether to use their public OpenID (http://openid.aol.com/<username>) or an opaque one. Of course, this choice isn't necessary if the user provides the relying party their full OpenID or the relying party specifically requests an opaque identifier (via PAPE policy). I'd really appreciate feedback on whether this "privacy" feature is helpful to users or just adds more confusion.
In addition to the existing SREG support, the same attributes will be supported via Attribute exchange. There is equivalent support for the http://axschema.org URIs but only partial support for the Information Card URIs as there weren't direct equivalents for all of the attributes. Here is what is currently supported.
http://axschema.org/namePerson/friendly
http://axschema.org/contact/email
http://axschema.org/birthDate
http://axschema.org/person/gender
http://axschema.org/contact/postalCode/home
http://axschema.org/contact/country/home
http://axschema.org/pref/language
http://axschema.org/pref/timezone
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country
Suggestions or requests for specific attributes are always welcome. One point of clarification regarding email addresses and verification. The current implementation defaults the email address to the user's AOL provided email address but does allow the user to change the value returned to the relying party.
While there is still a lot to do, it feels really good to finally reach this milestone.
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.]
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...
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...
Jeff Bohren writes...
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...
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.
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.
Tuesday, May 22, 2007
AOL supports simple federation with SAMLv2
In addition to the work AOL is doing to support OpenID, we've also been working with SAMLv2 to provide a simple federation profile for our partners. This allows users to federate an account at a partner to an account at AOL so that SSO is enabled from the partner to AOL or vise-versa.
This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.
The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...
Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.
This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.
The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...
- User goes to browser and loads site A
- User authenticates at site A using the account credentials associated with site A
- User clicks on link to partner site B
- Site A generates the SSO Assertion for site B using site B's pre-determined federation identifier
- Site A uses the http POST method to post the SSO Assertion to site B
- Site B validates and verifies the SSO Assertion
- User is “signed-on” to site B with site B's federated identifier
Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.
Monday, April 16, 2007
AOL releases OpenAuth
As has been blogged by Praveen Alavilli and John Panzer, today AOL released a set of http-rpc based API's for authenticating AOL identities and leveraging that authentication to access AOL services. These API's fill a niche in the existing http based web protocols by supporting the concept of authenticated service access and user consent. As many web based applications move to an AJAX model, being able to expose identity based services in a user-centric way becomes very important. Hence the importance on user consent for access to a user's data by a 3rd party application.
There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).
The basics for web developers are...
Much more detailed documentation is available at http://dev.aol.com/openauth.
Full disclosure: I work for AOL but not directly as part of the Authentication team.
Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF
There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).
The basics for web developers are...
- Provisioning
- At runtime
- requires both authentication and consent from the user before returning the authentication token
- requires user consent (can be remembered) before returning requested data
1. Get a provider id (called a developer key)
2. Request an authentication token
3. Invoke AOL identity based service
Much more detailed documentation is available at http://dev.aol.com/openauth.
Full disclosure: I work for AOL but not directly as part of the Authentication team.
Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF
Thursday, February 15, 2007
OpenID and AOL Consumers
As has already been noted by John Panzer, Kevin Lawver and others, AOL is providing an OpenID URL for all AOL & AIM members. This enables a significant number of consumers with an OpenID URL. I hope this encourages greater participation amongst existing services on the web. I find that many of the services I want to try out, don't support OpenID and hence I tend not to go through the whole registration process just to see if the site offers the services I'm interested in. Greater participation by relying parties will be key for adoption and use of OpenID by the "mass market".
In the "adoption and use" department... Given that many AOL users will not realize they have an OpenID, it would be great if the help text for "what is an OpenID?" on relying party "login" screens would mention that if you have a LiveJournal or AOL account, you already have an OpenID. This isn't very inclusive so maybe there could be a link ("Do I already have an OpenID?") to a wiki page or something that could be updated as more OpenID Providers become available. This isn't that important for those who explicitly create OpenID's at OpenID providers, but is important for those consumers who have an OpenID by virtual of having an account for other services.
Tags: OpenID, AOL
In the "adoption and use" department... Given that many AOL users will not realize they have an OpenID, it would be great if the help text for "what is an OpenID?" on relying party "login" screens would mention that if you have a LiveJournal or AOL account, you already have an OpenID. This isn't very inclusive so maybe there could be a link ("Do I already have an OpenID?") to a wiki page or something that could be updated as more OpenID Providers become available. This isn't that important for those who explicitly create OpenID's at OpenID providers, but is important for those consumers who have an OpenID by virtual of having an account for other services.
Tags: OpenID, AOL
Subscribe to:
Posts (Atom)