I've been thinking about the note that Dick sent out proposing a
special error code for captcha rate limiting when a client is trying
to exchange a username and password for a delegation token.  This is
very similar to Google's ClientLogin interface.  I talked to a couple
of folks here to find out how many developers have actually handled
captchas in their ClientLogin implementations.  Not many.  Most just
fail.

Even developers who have taken the time to handle captchas tend to do
so by opening up a web browser rather than displaying the captcha
themselves.

We clearly need rate limiting on this kind of API, and we do need a
way for users to recover when their accounts are rate limited
accidentally.  But full-on captcha support seems unlikely.

I think we should just return some error text with a URL to the client
instead.  Developers can ask the user to visit that URL.

Note that this also lets us add audio captchas/cookie reputation
checks/etc... pretty easily.

Cheers,
Brian

Hi Brian

It was actually Allen's idea to use captcha rate limiting. On our call, we concluded that including the captcha rate limit as an option made sense. Thanks for the data point that not many developers support the captcha interface you expose.

We also were going to make it optional to include a URL in the results that the app could send the user. This is clearly easier for apps that can launch a browser. Those apps though are likely better served by the Rich App profile rather than the Username and Password profile.

Making it optional enables a consistent means of doing captcha, and then implementers can decide if that works for their situation.

In other words, I think it is best to define a number of standard mechanisms for resolving the problem so that whichever one(s) become popular, there is a defined way to do it instead of a million slightly different snowflakes. Does that work?

-- Dick

Hi Dick,

I would like to see an optional CaptchaRequired similar to what Google
has for ClientLogin:
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html

Yahoo has a virtually identical "CaptchaRequired" error response for our
APIs that take the username/password as inputs. When the CaptchaRequired
error is returned, the client is expected to display the captcha to the
user, and then resubmit the username/password along with the captcha and
captcha solution.

We do have another error response similar to the one Brian proposed,
where the client is expected to tell the user to go login to Yahoo using
a regular web browser. This error response is returned when the user's
account is locked for whatever reason, including suspected password
cracking.  This workflow doesn't work as well as the CaptchaRequired
flow because the user's account could get locked again between the time
the user logs in via a browser and and the time the client resubmits the
request.

Allen

Sorry if I was not clear. I plan on including a number of mechanisms, including the captcha one.

-Dick

From: WRAP-WG@googlegroups.com [mailto:WRAP-WG@googlegroups.com] On Behalf Of Allen Tom
Sent: Monday, October 19, 2009 11:18 AM
To: WRAP-WG@googlegroups.com
Subject: [WRAP] Re: captcha prompts

Hi Dick,

I would like to see an optional CaptchaRequired similar to what Google has for ClientLogin:
http://code.google.com/apis/accounts/docs/AuthForInstalledApps.html

Yahoo has a virtually identical "CaptchaRequired" error response for our APIs that take the username/password as inputs. When the CaptchaRequired error is returned, the client is expected to display the captcha to the user, and then resubmit the username/password along with the captcha and captcha solution.

We do have another error response similar to the one Brian proposed, where the client is expected to tell the user to go login to Yahoo using a regular web browser. This error response is returned when the user's account is locked for whatever reason, including suspected password cracking.  This workflow doesn't work as well as the CaptchaRequired flow because the user's account could get locked again between the time the user logs in via a browser and and the time the client resubmits the request.

Allen

Hi Brian

It was actually Allen's idea to use captcha rate limiting. On our call, we concluded that including the captcha rate limit as an option made sense. Thanks for the data point that not many developers support the captcha interface you expose.

We also were going to make it optional to include a URL in the results that the app could send the user. This is clearly easier for apps that can launch a browser. Those apps though are likely better served by the Rich App profile rather than the Username and Password profile.

Making it optional enables a consistent means of doing captcha, and then implementers can decide if that works for their situation.

In other words, I think it is best to define a number of standard mechanisms for resolving the problem so that whichever one(s) become popular, there is a defined way to do it instead of a million slightly different snowflakes. Does that work?

-- Dick