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
