I think requests like this and the following discussions have scared away many of the original voices behind OAuth 2.0. As Eran said, the goal was never to create a new framework but standardize interoperable best practices that the industry was adopting. Under-defined extension points don't make this specification easier to adopt in a pragmatic fashion.
(Obviously my individual $0.02.) --David On Tue, Apr 19, 2011 at 9:26 AM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Hey Thomas, > >> -----Original Message----- >> From: Thomas Hardjono [mailto:hardj...@mit.edu] >> Sent: Tuesday, April 19, 2011 8:44 AM > >> If its ok with you, may I offer some friendly suggestion. >> Section 3 does not take away anything from your work and >> enormous contribution to the Oauth 2.0 main spec. > > This is not a personal issue... :-) > > Unlike the bearer token functionality which I consider harmful to the web and > refuse to have my name associated with it, this is just a case of poorly > defined functionality and the wrong way to define an HTTP authentication > scheme. IOW, this one is purely about the technical qualities of the > proposal. If my concerns are addressed, I don't have other external > objections to the functionality. > > The right example to compare this to is the discussion over the inclusion and > definition of the 'scope' parameter. While much less complex, the discussion > over how much to specify the 'scope' parameter is touching the same > interoperability concerns. > >> If anything, Section 3 shows that lots of people are >> interested in seeing OAuth 2.0 deployed in other environments >> and being integrated into other authentication >> infrastructures (eg. enterprise infra). >> I view this as a positive success point and achievement for Oauth 2.0. > > Yes and no. > > At some point, if you extend the reach of a protocol beyond its original > purpose you end up with a useless framework. I don't want to create another > SOAP or WS-*. > > Now, this is my personal view and I understand that in the context of an IETF > standard creation every community (consumer web, enterprise, telecom, > governmental, etc.) has a right to its voice. This is why I have not objected > to this addition on the basis of WG scope, use cases, or requirements (which > I could have easily done). My objection is purely on the technical quality of > the solution. > > The issue at hand is where to draw the line when it comes to defining > extensibility. This is the main theme behind other open issues as well. I > believe the document as currently defined provides sufficient extensibility > while still providing a complete authorization protocol. This proposal merely > takes that extensibility and moves it 1% forward with a tiny bit more > specialization for one use case. > >> And yes, further profiling & specs will be needed for each and every >> type of credential mentioned in Section 3 in order to get >> interoperability. That's always been my understanding (and >> I believe that is also the understanding >> of other folks who want Section 3 to stay). > > The only way we can test if the proposal works is by doing exactly that. The > same way we require multiple interoperable implementations before finish a > standard, we should require at least one published draft making use of this > extension point and complying with its requirements. How else would we know > that we got it right? > > For example, the SAML draft tested out the grant type and parameter extension > point. The bearer and MAC drafts tested out the token type extension point. > The UX draft tested out the error extension point (though not explicitly). > > So regardless of the text being incorporated at the end, someone will need to > publish a draft making use of it so that we can verify we have the right > solution specified. > >> Perhaps it would best to just leave Section 3 where it is, >> and to move on to other aspects of the draft. > > If you mean leave -15 section 3 as-is, I completely agree. :-) > > I think your draft has some new, useful prose that I plan to incorporate > either way (namely the new section about other authentication protocols). I > also think that we should go back to the previous text focusing on the HTTP > Basic scheme and defining the parameters alternative as just that (so as to > not create a new authentication scheme, but merely document how people are > "hacking" on Basic). I believe we have consensus to making those changed in > -16. > > Personally, I would go as far as to declare the two basic parameters as MAY > support for servers and NOT RECOMMENDED for clients. But we don't have > consensus for this yet (it wasn't framed this way before). > > So there is value in an overall review of section 3 which your contribution > has facilitated. > > Since no new voices have been added to this discussion since it was > originally introduced (on either side), the only next step with the new > functionality (client assertion credentials) is to wait for the chairs to > take over this discussion and outline how they want to gage consensus. > Further discussion between the same people is pointless - no one is saying > anything new, myself included. > > 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
