At least I finally got you to agree that this can be done in a separate specification. That's progress.
EHL > -----Original Message----- > From: Anthony Nadalin [mailto:[email protected]] > Sent: Monday, April 18, 2011 4:22 PM > To: Eran Hammer-Lahav; Manger, James H; oauth > Subject: RE: Revised Section 3 > > I'm certainly glad you gave us your definition of "breaking" but sadly your > definition is not in line with ours. When a developer sits down and codes to > the spec and then goes to rev the code with the latest spec and things are > removed the developer now either has to drop that feature or find an > additional specification that has the same feature. Can this be done in a > separate specification; sure it can just like we have been creating separate > specifications to make the base useable. > > -----Original Message----- > From: Eran Hammer-Lahav [mailto:[email protected]] > Sent: Monday, April 18, 2011 4:10 PM > To: Anthony Nadalin; Manger, James H; oauth > Subject: RE: Revised Section 3 > > 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:[email protected]] > > 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:[email protected]] > > 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: [email protected] [mailto:[email protected]] 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: [email protected] [mailto:[email protected]] 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 > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > > > > > > _______________________________________________ > > > OAuth mailing list > > > [email protected] > > > https://www.ietf.org/mailman/listinfo/oauth > > > > > > > > > > _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
