Re: [PROPOSAL] Handle "http://user@example.com" Style Identifiers

[Praveen Alavilli]

[Please pardon me if I am spamming the spec mailing list with general comments/issues that might have been discussed before] It's not the problem of just making AOL users OpenId enabled, so they can access 3rd party RPs (use http://www.aol.com/<loginId> or http://aimpages.com/<loginId> or http://journals.aol.com/<loginId>, etc....) - as someone else said it's a matter of educating the users (even if it takes long time based on user's geek level - because pretty much every IDP out there today tries to educate users about how to make sure they are not entering their credentials at a phishing site, but it still happens). It's more of a problem with how we can accept 3rd party OpenId users at AOL (we as an RP). Obviously for simple use cases like leaving comments on blogs it wouldn't really matter as long as the user is identified by someone (and someone doing rate limiting or something else to prevent spamming - otherwise I still can't see how it reduces spam anyway) - but when we want to take it to the next level - provide more services to these users (photos/calendar/etc.. ) we want to limit it to only a few IDPs whom we trust. (due to both security and business reasons). So this is the problem we are trying to figure out how we can message the users that we support OpenIds from certain providers (say Verisign PIP) but not from all. Obviously we can just follow the existing model of a free form field that says "Enter your OpenId" but most of the time we will end up failing the users saying "we don't accept your OpenId". Just bad user experience in our opinion. So instead we want to somehow message the user saying these are the only IDPs we trust - whether showing a drop down list of IDPs on the login form or something else, we want to see a standard way of doing it so user's don't feel like they are in an alien world from one RP to another (ofcourse keeping aside the phishing issues). We totally agree that adding another option to the already confusing list of account types is a bad idea. Another area where we want some more clarification (if it already exists) or support is about how we can have a persistent handler (apart from URI) for a given user so it would help in cases when a user's account gets reclaimed by someone else. Instead of it being an additional attribute that IDP can advertise as supported (which an RP can get via the Attribute Exchange protocol), if it can be baked into the "authentication" response, itself as a required field, it would help in having a common way of doing a locally stored identity discovery. If it can be generated similar to how PPID (Private Personal Identifier) is generated dynamically by Infocard it would be a great addition to OpenId IMO. thx =Praveen.alavilli [EMAIL PROTECTED] wrote: On 20-Oct-06, at 12:17 PM, John Panzer wrote: Kaliya * wrote on 10/20/2006, 11:57 AM: I think it is a terrible idea. 1) If you put something out into the market that looks like an e- mail it will be used like an e-mail. I have personal experience with this. I had a AIM handle for the Mac part of the universe [EMAIL PROTECTED] (it was not an e-mail address) but because it looked like one people used it like one and I basically had to go to .mac and pay for an account so that the wires did not cross. This came out of the discussions we have about a smooth migration path for our users at AOL. In our case the [EMAIL PROTECTED] nickname is also a resolvable email address, though it may not be the primary mail account of the user. I'd suggest that as a best practice, anywhere that a [EMAIL PROTECTED] nickname is used, it should also be a resolvable email address. And there should always be an option to not use something that looks like an email address. 2) I think OpenID is new and needs a new way to identify folks. And it is our job to teach people about this new way. Lots of services give people homepages within their spaces...myspace, AIMpages etc. so they can use those URL's if they don't have one yet they can get one. There's a bootstrapping problem here. It's very, very hard to promote the use of something that requires a more complex login flow to replace something that is very simple (albeit limited and in its own silo). How can we cross this chasm? Our suggestion is to support existing practice of [EMAIL PROTECTED] in a standard way, while being open to new practices. Once we can support both we can gain experience and start gradually migrating people over to the new world. At least that's my take. I empathize with your problem John, but I agree with Kaliya and others. Lets take another step back and envision what the login box prompt will say. In OpenID 1.x it was: "Enter your OpenID" With some text to explain what an OpenID was. With OpenID 2.0, we have something like: "Homesite | i-name | OpenID" (Homesite being more user friendly then IdP) All of these items are new things to users, and the user either has one or does not. If we support email addresses, then the prompt may look something like this: "email | Homesite | i-name | OpenID" Now any user with an email address thinks they can type it into the box and login. This of course is not going to be the case. I think the most straightforward method for your users is to educate them that AOL is now a homesite, and they can type in aol.com into the box. This user experience then is very similar to the user typing in aol.com into the address bar. They get sent to aol.com which will then prompt them for [EMAIL PROTECTED]. Given that you need to educate them that they can do something new to begin with, this seems to be the most straightforward path. -- Dick _______________________________________________ specs mailing list specs@openid.net http://openid.net/mailman/listinfo/specs

_______________________________________________
specs mailing list
specs@openid.net
http://openid.net/mailman/listinfo/specs