I had this as a draft in my Gmail for a while - never had time to finish it, but since you asked, here you go ;)
I'm digging into OAuth Core specification <http://oauth.net/core/1.0> and OAuth Discovery extension <http://oauth.net/discovery/1.0> trying to understand the use case where OAuth Consumers are not registered in any way with OAuth Service Provider before they make requests and knowing only Data Resource URLs (called "Protected Resource endpoint" in the Discovery extension document), but having no idea about which Request URLs they use. My interest is in using OAuth with arbitrary RDF resource (encoded in RDF/XML, n3, RDFa or whatever). I noticed an inconsistency in specification when looking at it from this point of view: "Service Providers *SHOULD NOT rely on the Consumer Secret as a method to verify the Consumer identity*, unless the Consumer Secret is known to be inaccessible to anyone other than the Consumer and the Service Provider. The Consumer Secret *MAY be an empty string* (*for example when no Consumer verification is needed* ...)" (section 4 paragraph 2) and still "The Consumer Developer *MUST *establish a Consumer Key and a Consumer Secret with the Service Provider." (section 4.3). What's the point to mandate register of a Consumer with Service Provider if there are cases when no Consumer verification is needed? I think it's not necessary to require this kind of registration upfront in cases when Service Provider does not need to verify a Consumer. Also, in "The Service Provider *verifies the signature and Consumer Key*. If successful, ..." (section 6.1.2) it's not clear if Consumer key only verifies the signature or if it also required to be verified against the Consumer registration entry. Same goes for the assumption in "The Service Provider presents to the User information about the Consumer requesting access (*as registered by the Consumer Developer*)." (section 6.2.2) which is probably worthless as this registration does not mandate any information that can properly identify the Consumer (or any other way fight fake consumers). Spec also doesn't require knowing the identity of the Consumer: "When displaying any identifying information about the Consumer to the User based on the Consumer Key, the Service Provider MUST inform the User *if it is unable to assure the Consumer's true identity*." (section 6.2.2) Having said all of this, I have a few questions: 1. If it's safe to remove the assumption that Consumer is registered with the Service Provider prior to the phase when it is requesting first Request Tocken (see my rationale above regarding section 4 paragraph 2 of the spec)? 2. If it's OK to do, then what are the implications for such implementation? Is it just putting more responsibility on a User when he accepts access for not really verifiable provider? What kind of attacks are possible in this case? And what might be the best practices to minimize a risk of fake Consumers (can we call it "phishing"?)? Will be happy to answer any questions regarding this use case. As more generic question for post-discussion - why do consumers need to know anything other then URL when they talk to producers? Most of the time they just need read-only access to data in some format that they can assume or auto-detect... Thank you, Sergey On Tue, Feb 24, 2009 at 6:25 PM, Eran Hammer-Lahav <[email protected]>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 > > > > > -- Sergey Chernyshev http://www.sergeychernyshev.com/ --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
