Subject: [OAUTH-WG] The verification URL and CAPTCHA responses for username/password profile?

From: David Recordon <[email-masked]>
Date: Mon, 8 Mar 2010 20:53:39 -0800

I'm spending some time with the spec this evening and am having a hard time understanding the need for the verification URL and CAPTCHA responses which are part of the username and password profile.

My criteria for using this profile is that 1) the authorization server generally trusts the client to temporarily collect the end-user's username and password and 2) it is impossible to use one of the other authorization profiles.  This means that the client cannot interact with or embed a web browser.  Given that...

The client would not be able to send the user to the verification URL in the response anyway (otherwise they would have picked the rich app profile). If the client were to encourage the user to use a nearby computer, then it could use the upcoming device API which should be based on the Netflix flow.

The CAPTCHA response verifies that there is a human, not that it is the human who the username and password belong to. Wouldn't bot attacks be mitigated via aggressive rate limiting techniques which reject authorization requests?  This response seems to be more complex than the benefit and hasn't been successfully implemented at scale AFAIK.

--David

---

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Tue, 9 Mar 2010 09:26:52 +0200

I agree with your statements below. I would remove the CAPTCHA concept
from the document. 

Ciao
Hannes

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] 
>On Behalf Of ext David Recordon
>Sent: 09 March, 2010 06:54
>To: OAuth WG
>Subject: [OAUTH-WG] The verification URL and CAPTCHA responses 
>for username/password profile?
>
>I'm spending some time with the spec this evening and am 
>having a hard time understanding the need for the verification 
>URL and CAPTCHA responses which are part of the username and 
>password profile.
>
>My criteria for using this profile is that 1) the 
>authorization server generally trusts the client to 
>temporarily collect the end-user's username and password and 
>2) it is impossible to use one of the other authorization 
>profiles.  This means that the client cannot interact with or 
>embed a web browser.  Given that...
>
>The client would not be able to send the user to the 
>verification URL in the response anyway (otherwise they would 
>have picked the rich app profile). If the client were to 
>encourage the user to use a nearby computer, then it could use 
>the upcoming device API which should be based on the Netflix flow.
>
>The CAPTCHA response verifies that there is a human, not that 
>it is the human who the username and password belong to. 
>Wouldn't bot attacks be mitigated via aggressive rate limiting 
>techniques which reject authorization requests?  This response 
>seems to be more complex than the benefit and hasn't been 
>successfully implemented at scale AFAIK.
>
>--David
>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth
>

---

From: Peter Saint-Andre <[email-masked]>
Date: Thu, 11 Mar 2010 11:34:35 -0700

<hat type='individual'/>

Agreed.