I also support the proposed refinement of the specification.
-- Mike
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Breno
Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type
On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav
<e...@hueniverse.com<mailto:e...@hueniverse.com>> 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: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>
[mailto:oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org>] On Behalf Of
Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: oauth@ietf.org<mailto:oauth@ietf.org>
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
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
