I don't think you understand what 'breaking' means. Breaking would be if we assigned a different meaning or syntax to the two parameters, or changed their name. Breaking requires code changes. There is nothing to prevent you from defining these parameters just like the SAML grant type did.
Was the relocation of the SAML assertion grant type to another document a "breaking" change? Clearly not according to the SAML grant type authors. The SAML specification is using the exact same extensibility framework this proposal can use. So technical issues aside, this is purely political to give this mechanism a stronger endorsement. My objections, on the other hand, are purely technical. As for consensus, (not wearing my editor hat) I am opposed to including that text. I have taken the time and effort to give my feedback in detail (more than once). So far no one has offered any rebuttals. I will hold off with any additional comments on this issue until the chairs decide how they want to proceed with this issue. EHL > -----Original Message----- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > Sent: Monday, April 18, 2011 3:55 PM > To: Eran Hammer-Lahav; Manger, James H; oauth > Subject: RE: Revised Section 3 > > > The claim that "removing is a breaking issue" is patently wrong. This claim > was made many times before and is baseless. A breaking change would > cause current implementations using these two parameters to break. This is > clearly not the case here since >the v2 specification already provides a > simple > method for defining additional request parameters as well as client > authentication methods. > > It's clearly the case that we are on v10 wanting to rev our implementation > and the removal is a breaking change for us. So it's not baseless as you > continue to say. I think that the text that Thomas has resurrected is just > fine > and I would support getting that text back into the document. > > > -----Original Message----- > From: Eran Hammer-Lahav [mailto:e...@hueniverse.com] > Sent: Monday, April 18, 2011 3:46 PM > To: Anthony Nadalin; Manger, James H; oauth > Subject: RE: Revised Section 3 > > There are two separate issues here, procedural and technical. We need to > address both. > > Procedural issue: > > The issue is how should this use case be addressed by this working group. > There were always three options: > > 1. Not address by the WG - leaving it up to those interested to submit an > individual I-D to register their extension parameters and use them as > defined. > 2. Address within v2 - add a section with similar functionality to the Client > Assertion Credentials section present in -11. > 3. Publish a companion specification - basically #1 and #2 combined, using the > text from #2, published as a standalone working group document. > > The *technical* end result of all three options is exactly the same. The same > two parameters (or any other solution) will be defined in the same way and > used the same way. The issue in picking an option from the above three is > purely *political* and is about giving the solution a higher degree of > endorsement. The companies interested in this work have already showed > interest in other companion specification so the argument of having to point > developers to multiple documents is completely without merit. Beyond that, > it is nothing but perceived level of endorsement. > > The benefit of going with #1 or #3 is that we can close this issue for v2 and > move on without delaying the publication of the specification. Again, all > three > options lead to the exact same end solution and same "compliant" > implementation. > > I would also point out that given the extensibility model we have adopted, > the authors of the proposed text could easily register the two parameters > without the need to build the same level of WG consensus. Publishing a > separate document is the only guaranteed method of getting the two > parameters to be officially registered (no RFC is required, just a > specification > published somewhere which can be anywhere). > > Technical issue: > > As documented in my reply to this thread, there are many issues with the > proposed text and solution which must be resolved before any route is > taken. The biggest issue is that inventing a new HTTP authentication method > based on assertions is clearly outside the scope of this working group. It is > also far from established that the proposed solution is the right solution for > authenticating HTTP requests using an assertion. > > It doesn't matter if this is defined narrowly for use with the OAuth token > endpoint because what it does in practice is invent a new HTTP > authentication scheme, and doesn't even use the existing HTTP > authentication framework. > > The claim that "removing is a breaking issue" is patently wrong. This claim > was > made many times before and is baseless. A breaking change would cause > current implementations using these two parameters to break. This is clearly > not the case here since the v2 specification already provides a simple method > for defining additional request parameters as well as client authentication > methods. > > EHL > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Anthony Nadalin > > Sent: Monday, April 18, 2011 2:53 PM > > To: Manger, James H; oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > >"3.3 Client Assertion Credentials". OAuth2 currently supports the > > >concept of > > a client app swapping an assertion for an access token. Do people want > > the additional functionality of using assertions for generic client > > authentication? I assumed servers would >prefer that clients swap an > > assertion for a token at one specific endpoint, then use the token for > > generic client auth in other requests -- in which case section 3.3 > > "Client Assertion Credentials" can be dropped. > > > > We have the case where signed assertions are used for authentication > > and other cases where just client_id and secrets are used. I don't > > agree that client assertion credentials should be dropped or that HTTP > > Basic Authentication can do everything that we want/need and having to > > go the route of suggesting a new HTTP Authentication scheme while nice > > does not help us with the current OAUTH that we have been developing. > > Removing is a breaking issue. > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Manger, James H > > Sent: Thursday, April 14, 2011 8:47 PM > > To: oauth > > Subject: Re: [OAUTH-WG] Revised Section 3 > > > > I'm certainly in favour of excluding client auth from OAuth. Dropping > > section > > 3 and just having a paragraph like the following would be preferable > > (with no capitalized keywords): > > > > In many cases an authorization server will require client > > authentication for requests to a token endpoint. > > Consequently, a client app that has credentials appropriate > > for that server should proactively use them for such requests. > > The actual mechanism for client authentication, and any > > provisioning of the associated credentials, is outside > > the scope of OAuth 2. > > > > > > I am not a fan of the client_id/client_secret parameters, but was > > resigned to their inclusion given existing deployments. Given those > > parameters are mentioned, OAuth2 should say: > > > > Various early deployments of the OAuth 2.0 concepts authenticated > > clients to the token endpoint using client_id and client_secret > > parameters in the request (alongside the grant_type parameter > > for instance). A server that accepts client_id/client_secret > > parameters MUST also accept the same credentials presented using the > > HTTP BASIC scheme instead (ie in an "Authorization: BASIC ..." request > > header). > > > > > > The last paragraph of Thomas's "3.2 Shared Secret Credentials" is > > crazy (typo?). A server supporting some strong authentication > > mechanism must not be mandated to also support weaker BASIC and > > client_id/client_secret mechanisms -- and certainly not with the same > secret! > > > > "3.3 Client Assertion Credentials". OAuth2 currently supports the > > concept of a client app swapping an assertion for an access token. Do > > people want the additional functionality of using assertions for > > generic client authentication? I assumed servers would prefer that > > clients swap an assertion for a token at one specific endpoint, then > > use the token for generic client auth in other requests -- in which > > case section 3.3 "Client Assertion Credentials" can be dropped. > > > > -- > > James Manger > > > > _______________________________________________ > > 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 > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
