You need to define how this proposed extension works with the overall architecture.
This is not just an endpoint people can bastardize (I am not suggesting *you* are) as they see fit. It must fit with the overall model which is that this endpoint returns either an access token or an authorization grant. An authorization grant has to be exchanged for an access token. If you are going to return something else, instead or in addition to the token/code options, you need to explain how it fits within the model. I am opposed to an open-ended extension point that is not consistent (and restricted) to the model we spent a year to define and refine. The token+code response type was well defined (it was the use case that wasn't). To move this forward, you need to come up with specific requirements, not just making something extensible without understanding what it is you are trying to extend. That's like the OAuth 1.0 utterly broken oauth_version parameter and the long confusion it created later on. EHL From: Breno [mailto:[email protected]] Sent: Thursday, February 17, 2011 1:58 PM To: Eran Hammer-Lahav Cc: [email protected] Subject: Re: [OAUTH-WG] Freedom of assembly for response_type On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <[email protected]<mailto:[email protected]>> wrote: The best approach (at this point) is to leave the spec unchanged. However, another spec can update the definition of the response_type parameter, including defining a registry or other methods for extensibility. We can define this now, and it will not have any impact on existing code, but I am leery of adding yet another extensibility vector without sufficient requirement. I also think that adding extension parameters can handle this cleanly. The spec, as currently written does not imply that the only possible values are 'code' and 'token'. The only concern is that libraries may implement such restriction and make extending this behavior different. I do not think that extension parameters can handle this cleanly. In particular, if the response_type is neither code nor token. EHL From: [email protected]<mailto:[email protected]> [mailto:[email protected]<mailto:[email protected]>] On Behalf Of Breno Sent: Thursday, February 17, 2011 10:30 AM To: [email protected]<mailto:[email protected]> Subject: [OAUTH-WG] Freedom of assembly for response_type - Problem 1: Several WG participants are working on deploying a federated signon protocol based on OAuth2 (aka OpenIDConnect) and would like to return an additional 'session cookie' together with the auth_token. Or sometimes return only a cookie as the result of authorization, since cookies will likely have shorter lifetimes than access tokens, for security and usability reasons, and require more frequent refresh requirements. In any case, there aremultiple reasons for making the cookie separate from the auth_token, including both security and flexibility of deployment. However, there is no way to express this except adding an arbitrary extension parameter (to effectively express a different response type). - Problem 2: Codification of code_and_token created controversy as there was not enough traction among participants to put it in the core. However, it is entirely possible that deployment experience will lead players to revisit this topic. - Proposed solution: 1. Allow response_type to be a space separated list of arbitrary strings E.g.: response_type=code response_type=token response_type=code+token response_type=cookie response_type=code+cookie response_type=token+cookie response_type=foo+bar Would all be syntactically valid responses from the perspective of OAuth2.0 Core response_type values. 2. Define behaviors in the core only for values 'code' and 'token'. Allow extensions to define what do with 'code+token' or with any other values or combinations of values. -- Breno de Medeiros -- Breno de Medeiros
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
