Hey Thomas, > -----Original Message----- > From: Thomas Hardjono [mailto:[email protected]] > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
