The biggest complaint I hear about is the confusion around "consumer key" vs. "oauth token".
For Netflix, the problem is determining who the consumer is, often with the individual creating the third party app to be sold on iPhones inevitably getting it wrong. We use API Key and secret for the Consumer Key and Shared Secret along with Access Token and Access Secret for the OAuth Token and OAuth Secret. We do that because we use two legged OAuth for information that doesn't involve our customers and three legged for info that does. By and large, most folks get it. Obviously "API Key" doesn't work for services that don't provide them, but they should be named something a bit more descriptive and less confusing, possibly "primary" and "secondary" to indicate how they're generally used. Eran Hammer-Lahav wrote: > I am getting ready to making a complete rewrite of the current OAuth spec. > The idea is to make it much easier to read without changing anything that > will impact implementation. This will be useful both for clarity but also as > a better starting point for the upcoming OAuth effort at the IETF. > > What I would like to ask people who have read the spec or implemented it to > share as many problems, errors, failures, mistakes, misunderstandings, > wasted time, etc. caused by the spec not being clear enough. > > You can simply describe the error (did not sort parameter, did not %-encode, > %-encoded twice, etc.) or the section of the spec you had to read 325 times > before it made any sense. > > Please reply to this thread so we have a public inventory of OAuth FAILs. > > EHL > > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
