I guess if making things complicated and dropping features and now having to go through the process of creating yet another specification is progress than maybe we are, but on the other hand looks like we are making reverse progress.
-----Original Message----- From: Eran Hammer-Lahav [mailto:[email protected]] Sent: Monday, April 18, 2011 4:24 PM To: Anthony Nadalin; Manger, James H; oauth Subject: RE: Revised Section 3 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
