I agree with your statements below. I would remove the CAPTCHA concept from the document.
Ciao Hannes >-----Original Message----- >From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] >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 >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
