Pardon me if this seems naive, but if we're considering a solution in which the user enters a pin at both ends, perhaps a better solution to use an image instead, the way banks make show you some small thumbnail to verify that it is indeed their site you're looking at. Perhaps the provider could maintain a collection of such images (could easily generate a pretty huge sample from freely license flickr photos) and send them along with the unauthorized request token. Then at the authorization screen, the user would simply have to pick the right image out of a "lineup" and notified that if they have no idea what the image is, they have been duped. It requires changes to both the consumer and the provider and it requires that the provider maintain the image pool, but it is certainly quite a bit better than requiring a pin at both ends.
Once again, I'm quite the OAuth amateur, so I may be missing something significant. Cheers, Mike. On Sat, Apr 25, 2009 at 11:23 AM, Dossy Shiobara <[email protected]> wrote: > > On 4/25/09 1:33 PM, J. Adam Moore wrote: > > I'm writing a blog post to explain why I think I have a solution, but > > I believe it is as simple as moving the provider login to before the > > consumer token generation which is triggered by a provider-side > > redirect. > > Yes. This is exactly what I've been saying. Please, help me help > others understand this, too. > > > -- > Dossy Shiobara | [email protected] | http://dossy.org/ > Panoptic Computer Network | http://panoptic.com/ > "He realized the fastest way to change is to laugh at your own > folly -- then you can let go and quickly move on." (p. 70) > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
