I would be unhappy if things were sugarcoated any further. This is definitely a rare specification where OPTIONAL parameters in the API can be REQUIRED by a conforming implmentation (as I discussed in my note on the scope parameter for which the proposed modification does not really change much)
I appreciate that there is a cautionary statement that this specification may produce non-interoperable client / server implementations, as I discovered upon writing my first client. The cautionary statement would be invaluable to programmers in the wild who are not used to the unusual semantics of this particular specification. Hence I strongly support (if it counts) keeping the language the way Eran Hammer has suggested. On Fri, Jan 27, 2012 at 5:12 AM, Eran Hammer <e...@hueniverse.com> wrote: > The specification already has informative references to the two token > types. From purely practical standpoint, I am not adding any more > references because that creates more dependencies and longer wait time. > > There is nothing factually incorrect about the current text. It already > makes it clear that additional work is required and expected. It is also a > fact that it will produce a wide range an non-interoperable > implementations unlike, say, HTTP. We have to make this clear to the > reader upfront because every reader outside this WG has exactly the > opposite expectation, especially coming from 1.0. > > I'll make the small tweak proposed below before this goes to the RFC > editor, but am not making any other changes to the text unless you can > show it is factually incorrect or incomplete. > > EHL > > > > On 1/26/12 1:21 PM, "Justin Richer" <jric...@mitre.org> wrote: > > >I really don't see it this way, as a failure. Instead, I think we've > >managed to successfully scope the document to address important > >practices and bits of the protocol that will work in tandem with other > >documents to solve different use cases. One of the biggest problems that > >we saw coming in from OAuth1.0 was that it tried to be all things to all > >people all at once, which also didn't help interoperability. I think > >that what we have is a more composable UNIXy approach here. Namely, > >OAuth 2 core/framework/whatever does one thing and does it well: it > >outlines a standard means and structure for getting a token. Does that > >help you use the token against a web service, do service discovery, pack > >information into the token itself? No, but it wasn't meant to. It was > >meant to leave enough space for other docs to take care of that. > > > >But I do not think that it's gone so far as to leave a morass of > >unusable components, much in the way that WS-* did, and I don't think > >the comparison is a fair one. I think the separations are clean and the > >usage profiles are clear. > > > >By pointing developers to other specifications, most of which are > >products of this very working group or members of this working group > >under other umbrellas, we *can* provide a wider view of the world. At > >the absolute least, I think it needs to point to the two token type > >docs, and I'd suggest at least keeping the two token format docs as > >well. And as was pointed out by Phil Hunt, this notion of loosely > >coupled specs and components is actually *beneficial* to today's web > >environment. This is another way that this work differs from WS-*: if > >you're doing one part of WS-*, you're not going to get away without > >doing the rest of it too if you want to have a working system. As you > >point out, and somewhat lament, this is not the case with OAuth 2. You > >can do some parts, and not others, and utalize just the bits that you > >need. The fact that I can use the same endpoints and mechanisms for > >user-delegated auth and machine-directed auth is very powerful, and the > >fact that I can use the same exact client libraries to fetch and use > >both random-hex tokens and signed JWTs is equally powerful. The fact > >that I can reuse 90% of that code and also get signed MAC tokens is > >likewise powerful. > > > >Thus, I stand by my originally-suggested text and respectfully submit it > >to the editor and working group for consideration of inclusion in this > >section. > > > > -- Justin > > > >On 01/26/2012 12:49 PM, Eran Hammer wrote: > >> > >>> -----Original Message----- > >>> From: Justin Richer [mailto:jric...@mitre.org] > >>> 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 > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
