What if the username/password (or PIN) was used to release a secret (located in an OTP dongle) or to exercise a secret key (symmetric or asymmetric) located in a smartcard or TPM chip?
Reading Section 3.8, it seems it covers these cases already (or am I reading the wrong section). In Figure 6, the "Client" would be the code contained in the auth-device (or the code that invokes the underlying auth-device). Section 3.7 on device flows does not look as if it was written with these portable auth-devices in mind. /thomas/ __________________________________________ From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Dick Hardt Sent: Monday, June 07, 2010 2:40 PM To: Luke Shepard Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Username and Password flow: no captcha? Background: The username / password flow can be used to brute force attack a system to find valid credentials. A captcha is presented to slow the attack down -- similar to what happens when you log in with an invalid password on a webpage. The captcha would be displayed by the app for the user to enter in if the AS thinks it is getting attacked from that IP or whatever. The captcha does not require a web browser -- it actually does make sense for most of the Facebook clients. The captcha was dropped because there were a number of aspects that had not been standardized, so it was decided to drop it from the core. On 2010-06-07, at 11:30 AM, Luke Shepard wrote: The username/password flow is designed to work in a situation where there is no web browser available. At least at Facebook, none of our clients implement captcha - it doesn't really make sense in many contexts. A provider is still welcome to offer a non-standard captcha support but it shouldn't be part of the core spec. On Jun 7, 2010, at 8:40 AM, Andrew Arnott andrewarn...@gmail.com<mailto:andrewarn...@gmail.com> wrote: In WRAP, there was a CAPTCHA in this profile, but I don't see it in the latest OAuth 2.0 draft. Since I've already implemented the CAPTCHA stuff from WRAP, I'll leave it there if the OAuth 2.0 is likely to pick it up, or rip it out now if OAuth 2.0 decided it wasn't necessary. Does anyone from the WG have something they can say on the subject? -- Andrew Arnott "I [may] not agree with what you have to say, but I'll defend to the death your right to say it." - S. G. Tallentyre <ATT00001..txt> _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
