If an app developer writes their own client, than their OAuth code becomes bound in with the code connecting to the underlying resource API which may or may not be standardized. Regardless the tight coupling of OAuth plus an API can only be inter-operable in that specific combination.
This will be mitigated through the eventual emergence of client toolkits which keep the resource API and the authorization API cleanly separated. This may lead to further specs and refinements to OAuth2 down the road. But we don't have enough data for that today. IMHO I think for RESTful services, fuzzy interoperability is the nature of the technology for now because of its other benefits. Phil @independentid www.independentid.com [email protected] On 2012-01-26, at 9:49 AM, Eran Hammer wrote: > > >> -----Original Message----- >> From: Justin Richer [mailto:[email protected]] >> Sent: Thursday, January 26, 2012 6:07 AM >> To: Eran Hammer >> Cc: OAuth WG >> Subject: Re: [OAUTH-WG] AD Review of -22 (part II) >> >> I realize that -23 is already published with the below text, but since this >> is a >> whole new section and nobody else seemed to bring it up, I wanted to make >> sure it wasn't missed by the WG. > >> I think it's a good idea to call it out, and I don't want to "sugarcoat" it >> either, >> but the phrase "this specification is likely to produce a wide range of non- >> interoperable implementations" is a bit overdramatic in its tone. Instead, I >> think we should point to other documents that are being developed explicitly >> along side of this, such as at the beginning of RFC2904 >> (http://tools.ietf.org/html/rfc2904). I suggest text like the following >> instead: >> >> OAuth 2.0 provides a rich authorization framework with well-defined security >> properties. However, as a rich and highly extensible framework with many >> optional components, this specification does not seek to define all >> components needed for a fully interoperable deployment within this >> document. Instead, this specification is intended to work with complimentary >> documents that define token types [MAC] [Bearer], token formats [JWT] >> [SAML], client registration [Dynamic Reg?], endpoint discovery [XRD] [SWD], >> and other considerations. >> This protocol was designed with the clear expectation that future work will >> define prescriptive profiles and extensions necessary to achieve full web- >> scale interoperability. > > This does sugarcoat the fact that 2.0 does not provide *any* guaranteed > interoperability. The implementations I've seen so far have simply adopted a > *profile* of this document along with bearer tokens. We've already seen > feedback on this list where client developers were surprised and frustrated > with such implementations when trying to reuse code across providers and this > is only going to get more noticeable. And then of course we have the insane > complexity of the over-architected solutions, adding layer after layer to > solve problems that are as simple as making a parameter required and well > specified. > > We've also seen questions about providers looking to claim OAuth 2.0 support > while maintaining all their existing architecture and security properties, > seeking to push the boundaries of what is permitted by the specification. > We've gone to a place where *anything* can be made to look like OAuth. We've > seen implementations doing nothing but exchanging SAML assertions for > JSON-formatted assertions (or other SAML assertions), without any actual > resource owner participation, calling itself OAuth. And sadly, it can. > > I'm against adding such a laundry list of references. I am also opposed to > implying that using these extensions will achieve interoperability because > they will not in their current state. The only way to achieve > interoperability at this point is by getting rid of most of the optional > components (removed or made required), and tightening the definition of > others. Or alternatively, come out with a full blown discovery and > negotiation protocol - something that would be extremely premature at this > point. How can you design a good discovery/negotiation protocol before you > have even a partial picture of what it is you want to discovery/negotiate. > > Instead, I proposing a small tweak (marked with [[ ]]) to the language: > > --- > 1.7. Interoperability > > OAuth 2.0 provides a rich authorization framework with well-defined > security properties. However, as a rich and highly extensible > framework with many optional components, [[ on its own, ]] this > specification is likely > to produce a wide range of non-interoperable implementations. In > addition, this specification leaves a few required components > partially or fully undefined (e.g. client registration, authorization > server capabilities, endpoint discovery). > > This protocol was designed with the clear expectation that future work > will define prescriptive profiles and extensions necessary to achieve > full web-scale interoperability. > --- > > I can appreciate feeling a little sting from such a disclaimer but we all > deserve it for failing to do our job. We took on a successful, simple, > narrow, and useful protocol and turned it into mush because after more than 2 > years we have failed to find common ground on almost anything that is > required to achieve interoperability. Instead we now rely on popular > providers such as Facebook and Twitter to set the tone for the rest of the > industry, filling in the gaps. > > My personal frustration is from the fact that a significant number of working > group members put the interest of their corporate overlord above what is good > for the web. They have aggressively promoted an agenda based on product lines > already in advance stages of development and refused to compromise if that > meant making changes to their products. We have produced the closest heir to > WS-* I've seen in many years, and that's nothing to be proud of. > > The result is pretty obvious: claiming OAuth 2.0 support or even compliance > is meaningless. It's the difference between dancing the tango and dancing to > rock music. One gives you a beautifully synced performance while the other > put personal expression on a pedestal. Which one do you think is better for a > web protocol? > > It's time to own the results of our work and to clearly state that this is > the best we were able to produce, and let the industry take over and solve > through running code the problems we were too fragmented to solve here. > > EHL > > > > > > > > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
