Subject: [OAUTH-WG] Freedom of assembly for response_type

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 10:29:42 -0800

- 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

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 14:51:50 -0700

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.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: [email-masked]
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:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

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

---

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 13:58:05 -0800

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <[email-masked]>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-masked] [mailto:[email-masked]] *On Behalf
> Of *Breno
> *Sent:* Thursday, February 17, 2011 10:30 AM
> *To:* [email-masked]
> *Subject:* [OAUTH-WG] Freedom of assembly for 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:
>
>
>

-- 
Breno de Medeiros

---

From: Mike Jones <[email-masked]>
Date: Thu, 17 Feb 2011 22:28:25 +0000

I also support the proposed refinement of the specification.

                                                            -- Mike

From: [email-masked] [mailto:[email-masked]] On Behalf Of Breno
Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> 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.

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-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Breno
Sent: Thursday, February 17, 2011 10:30 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] Freedom of assembly for response_type

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 17:12:45 -0700

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-masked]]
Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 16:22:00 -0800

The use case is very straightforward:

- SAML provides session management. Facebook Connect provides session
management. Both use cookies. These are authentication protocols but common
usages of both SAML and FB Connect imply authorization grants.
- OpenID2.0 does not provide session management. This has proven to reduce
the value of OpenID and make it unsuitable for many scenarios.

We would like federation protocols based on OAuth2 to be high-value. We
would rather that they not be be hacks built on top of OAuth2. That means
that we need a first-order concept of cookie. A cookie can be refreshed
independent of the grant associated with it. A cookie is something the
client holds on to that identifies the user (i.e., it's for user-client
authentication), but that the client is happy to outsource the management of
security/crypto/logged-in/logged-out state to the server.

The cookie is produced and returned by the server, in combination with a
grant, but it can be refreshed independently.

This is a solid and proven use case, and is of fundamental value to many
planned OAuth2 implementations.

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> 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-masked]]
> *Sent:* Thursday, February 17, 2011 1:58 PM
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]
> *Subject:* Re: [OAUTH-WG] Freedom of assembly for response_type
>
>
>
>
>

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 17:40:19 -0700

I am not questioning the use case, only how it fits within the OAuth framework.

I don't understand how such an extension is expected to work with the existing grant types. The response_type parameter is used to identify if the flow being used is for an implicit grant or authorization code. Are you suggesting a new grant type? Are you suggesting additional response parameters/headers (in the case of a cookie) with both grant types?

Without full requirements we can't design an extension point. Asking to make this parameter a free text field is not helpful.

EHL

From: Breno [mailto:[email-masked]]
Sent: Thursday, February 17, 2011 4:22 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

- SAML provides session management. Facebook Connect provides session management. Both use cookies. These are authentication protocols but common usages of both SAML and FB Connect imply authorization grants.
- OpenID2.0 does not provide session management. This has proven to reduce the value of OpenID and make it unsuitable for many scenarios.

We would like federation protocols based on OAuth2 to be high-value. We would rather that they not be be hacks built on top of OAuth2. That means that we need a first-order concept of cookie. A cookie can be refreshed independent of the grant associated with it. A cookie is something the client holds on to that identifies the user (i.e., it's for user-client authentication), but that the client is happy to outsource the management of security/crypto/logged-in/logged-out state to the server.

The cookie is produced and returned by the server, in combination with a grant, but it can be refreshed independently.

This is a solid and proven use case, and is of fundamental value to many planned OAuth2 implementations.

On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
You need to define how this proposed extension works with the overall architecture.

EHL

From: Breno [mailto:[email-masked]<mailto:[email-masked]>]
Sent: Thursday, February 17, 2011 1:58 PM
To: Eran Hammer-Lahav
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 16:50:27 -0800

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> I don’t understand how such an extension is expected to work with the
> existing grant types. The response_type parameter is used to identify if the
> flow being used is for an implicit grant or authorization code. Are you
> suggesting a new grant type? Are you suggesting additional response
> parameters/headers (in the case of a cookie) with both grant types?
>

It's a separate grant type that can be combined with either of the previous
types.

>
>
> Without full requirements we can’t design an extension point. Asking to
> make this parameter a free text field is not helpful.
>

The requirement is to allow another grant type, cookie.

- cookie can be used separately or in combination with code or token.

- if specified by itself or in combination with token, it's returned in the
End User Authorization Response, in analogy/in addition to the access_token

- If specified in combination with code, it's returned in exchange for the
code, in analogy with the access_token

> *Sent:* Thursday, February 17, 2011 4:22 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 17:56:00 -0700

Is cookie exchanged for an access token? Authorization grants are not meant to be useful by themselves, only exchanged for an access token.

Can you request only a cookie? Or is it always with either a token or code?

EHL

From: Breno [mailto:[email-masked]]
Sent: Thursday, February 17, 2011 4:50 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
I am not questioning the use case, only how it fits within the OAuth framework.

It's a separate grant type that can be combined with either of the previous types.

- if specified by itself or in combination with token, it's returned in the End User Authorization Response, in analogy/in addition to the access_token

- If specified in combination with code, it's returned in exchange for the code, in analogy with the access_token

EHL

To: Eran Hammer-Lahav

EHL

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 17:10:06 -0800

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Is cookie exchanged for an access token? Authorization grants are not meant
> to be useful by themselves, only exchanged for an access token.
>

In this scenario, grants are exchanged for access tokens and/or cookies.

> Can you request only a cookie? Or is it always with either a token or code?

The idea is that a grant can be exchanged for only a cookie in some cases.

> *Sent:* Thursday, February 17, 2011 4:50 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 20:31:37 -0700

So an implicit grant can produce just a cookie or both cookie and token, but not code?

EHL

From: Breno [mailto:[email-masked]]
Sent: Thursday, February 17, 2011 5:10 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Is cookie exchanged for an access token? Authorization grants are not meant to be useful by themselves, only exchanged for an access token.

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 21:29:34 -0800

> So an implicit grant can produce just a cookie or both cookie and token,

Yes, cookies would be returned in the same context of access_tokens, either
as the result of an implicit grant or resulting from an explicit exchange
from a code-type grant.

> *Sent:* Thursday, February 17, 2011 5:10 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 22:52:15 -0700

Ok.

So you want to request a cookie from both endpoints: the authorization endpoint and the token endpoint? How would that work? There is no response_type on the token endpoint.

EHL

From: Breno [mailto:[email-masked]]
Sent: Thursday, February 17, 2011 9:30 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
So an implicit grant can produce just a cookie or both cookie and token, but not code?

Yes, cookies would be returned in the same context of access_tokens, either as the result of an implicit grant or resulting from an explicit exchange from a code-type grant.

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Thu, 17 Feb 2011 22:06:40 -0800

On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> Ok.
>
>
>
> So you want to request a cookie from both endpoints: the authorization
> endpoint and the token endpoint? How would that work? There is no
> response_type on the token endpoint.
>

There is no need to. The grant carries the information.

> *Sent:* Thursday, February 17, 2011 9:30 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 23:47:57 -0700

You mean this is encoded into the authorization code?

EHL

From: Breno [mailto:[email-masked]]
Sent: Thursday, February 17, 2011 10:07 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Ok.

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 17 Feb 2011 23:48:28 -0700

Can you send an example wire interaction?

EHL

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Paul Madsen <[email-masked]>
Date: Fri, 18 Feb 2011 10:17:58 -0500

Breno, why are you using 'cookie' in this context?

SAML's  'session management' (I assume you are referring to SLO?) 
functionality does not rely on browser cookies, but rather on the 
participants sending a LogoutRequest carrying an identifier for the 
Subject in question (and possibly a session index)

Is it the session index that you are referring to as a cookie?

Of course, both IdPs and SPs typically use cookies for their own local 
state, but this is independent of SAML. The only application of cookies 
in SAML are for discovery (arguably deployed even less than the above SLO).

I confess I dont know how FB Connect does SLO

thanks

paul

On 2/17/11 7:22 PM, Breno wrote:
> management. Both use cookies. These are authentication protocols but 
> common usages of both SAML and FB Connect imply authorization grants.
> - OpenID2.0 does not provide session management. This has proven to 
> reduce the value of OpenID and make it unsuitable for many scenarios.
>
> We would like federation protocols based on OAuth2 to be high-value. 
> We would rather that they not be be hacks built on top of OAuth2. That 
> means that we need a first-order concept of cookie. A cookie can be 
> refreshed independent of the grant associated with it. A cookie is 
> something the client holds on to that identifies the user (i.e., it's 
> for user-client authentication), but that the client is happy to 
> outsource the management of security/crypto/logged-in/logged-out state 
> to the server.
>
> The cookie is produced and returned by the server, in combination with 
> a grant, but it can be refreshed independently.
>
> On Thu, Feb 17, 2011 at 4:12 PM, Eran Hammer-Lahav 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>     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-masked]
>     <mailto:[email-masked]>]
>
>     *Cc:* [email-masked] <mailto:[email-masked]>
>     On Thu, Feb 17, 2011 at 1:51 PM, Eran Hammer-Lahav
>     <[email-masked] <mailto:[email-masked]>> 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-masked] <mailto:[email-masked]>
>         [mailto:[email-masked]
>         <mailto:[email-masked]>] *On Behalf Of *Breno
>         *To:* [email-masked] <mailto:[email-masked]>
>         - 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:
>
>         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
>
>
>
>
> -- 
> Breno de Medeiros
>
>
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Breno <[email-masked]>
Date: Fri, 18 Feb 2011 13:52:59 -0800

On Fri, Feb 18, 2011 at 7:17 AM, Paul Madsen <[email-masked]> wrote:

> participants sending a LogoutRequest carrying an identifier for the Subject
> in question (and possibly a session index)
>

Yes. As far as I understand it, it is often the case that websso deployments
based on SAML commonly use the SAML assertion for the session id as a
browser cookie in practice. Facebook Connect has an authenticated user_id
blob that can be used as a cookie (and the FB-provided js libraries
certainly do so).

I agree that 'cookie' is possibly a bad name (there's not a necessity to use
it as a browser cookie in the proposed OpenIDConnect interaction either,
though it will likely be used as such). However, names such as 'token',
'bearer', are already bound to other meanings in the OAuth2 spec. Another
name that I have referred to this in the past is 'session_token'.

> state, but this is independent of SAML. The only application of cookies in
> SAML are for discovery (arguably deployed even less than the above SLO).
>

See above.

>> 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
>> 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.
>>
>>
>>
> OAuth mailing [email-masked]://www.ietf.org/mailman/listinfo/oauth
>
>

-- 
Breno de Medeiros

---

From: Breno <[email-masked]>
Date: Fri, 18 Feb 2011 14:03:23 -0800

Example 1:

OpenIDConnect End User Authorization Request for '<other required OAuth2
parameters>&response_type=token+cookie'
OpenIDConnect End User Authorization Response  '<other required OAuth2
parameters>&access_token=foo&cookie=bar'

Example 2:

OpenIDConnect End User Authorization Request for '<other required OAuth2
parameters>&response_type=code+cookie'
OpenIDConnect End User Authorization Response '<other required OAuth2
parameters>&code=foo'

OpenIDConnect outcome of grant redemption ... '<other required OAuth2
parameters>[&refresh_token=foo]&access_token=bar&cookie=baz'

Example 3 (specific syntax still to be agreed upon):

OpenIDConnect End User Cookie Refresh Request '<other required OAuth2
parameters>&response_type=cookie&cookie=... '
OpenIDConnect End User Cookie Refresh Response '<other required OAuth2
parameters>&cookie=foo'

Example 4 (specific syntax still in the work):
OpenIDConnect End User Logout Request '&access_token=bar' (to new endpoint)
OpenIDConnect End User Logout Response '<something to mean ok>'

On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav <[email-masked]>wrote:

> *Sent:* Thursday, February 17, 2011 10:07 PM
>
> *To:* Eran Hammer-Lahav
> *Cc:* [email-masked]

-- 
Breno de Medeiros

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sun, 20 Feb 2011 17:06:02 -0700

I have a few issues/comments:

1.       The value 'cookie' is way to generic. What is the content of such cookie and what is the client supposed to do with it?

2.       Example 3 does not belong on the End user authorization endpoint as it does not produce a code or token (or any other grant type to be exchanged for a token). Is the user involved in this refresh?

3.       Are you going to have cookie versions in the future? Is this an extensible format?

Overall, this feels like 'BTW, while we're at it, also give me a cookie' which belongs in another extension request parameter. Just because we have a parameter called 'response_type' does not mean anything that impacts the response should be requested using it. Adding a new request parameter such as 'openid_cookie=1.0' to request version 1.0 of the cookie used by OpenID connect is one example.

My main objection to allowing response_type to be extensible is that it requires defining a registry for new values, a syntax for multiple values to combine them in one request, error codes to deal with unknown or unsupported response types (combined with supported ones), and defining other restrictions to make sure the endpoint remains an OAuth endpoint (i.e. results in a grant type exchanged for an access token or an access token).

By leaving response_type unchanged and adding another request parameter, all these issues are avoided when the cost to the OpenID Connect protocol is nothing more than a different way to add a cookie to the request.

EHL

From: Breno [mailto:[email-masked]]
Sent: Friday, February 18, 2011 2:03 PM
To: Eran Hammer-Lahav
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Freedom of assembly for response_type

Example 1:

OpenIDConnect End User Authorization Request for '<other required OAuth2 parameters>&response_type=token+cookie'
OpenIDConnect End User Authorization Response  '<other required OAuth2 parameters>&access_token=foo&cookie=bar'

Example 2:

OpenIDConnect End User Authorization Request for '<other required OAuth2 parameters>&response_type=code+cookie'
OpenIDConnect End User Authorization Response '<other required OAuth2 parameters>&code=foo'

OpenIDConnect outcome of grant redemption ... '<other required OAuth2 parameters>[&refresh_token=foo]&access_token=bar&cookie=baz'

OpenIDConnect End User Cookie Refresh Request '<other required OAuth2 parameters>&response_type=cookie&cookie=... '
OpenIDConnect End User Cookie Refresh Response '<other required OAuth2 parameters>&cookie=foo'

On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav <[email-masked]<mailto:[email-masked]>> wrote:
Can you send an example wire interaction?

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

To: Eran Hammer-Lahav

EHL

EHL

- Proposed solution:

E.g.:

response_type=code
response_type=token
response_type=code+token
response_type=cookie

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

--
Breno de Medeiros

---

From: Torsten Lodderstedt <[email-masked]>
Date: Sun, 27 Feb 2011 14:04:54 +0100

Hi Breno,

what is the difference between your cookie and any access token?

I'm asking because I'm under the impression the cookie is "just" another 
token for the purpose of securely communicating between the 
OpenIDConnect client and the OpenIdConnect server. If so, you could 
obtain this token using the standard response type.

regards,
Torsten.

Am 18.02.2011 23:03, schrieb Breno:
> Example 1:
>
> OpenIDConnect End User Authorization Request for '<other required 
> OAuth2 parameters>&response_type=token+cookie'
> OpenIDConnect End User Authorization Request for '<other required 
> OAuth2 parameters>&response_type=code+cookie'
> On Thu, Feb 17, 2011 at 10:48 PM, Eran Hammer-Lahav 
>     On Thu, Feb 17, 2011 at 9:52 PM, Eran Hammer-Lahav
>     So you want to request a cookie from both endpoints: the
>     authorization endpoint and the token endpoint? How would that
>     work? There is no response_type on the token endpoint.
>
>         On Thu, Feb 17, 2011 at 7:31 PM, Eran Hammer-Lahav
>         Yes, cookies would be returned in the same context of
>         access_tokens, either as the result of an implicit grant or
>         resulting from an explicit exchange from a code-type grant.
>
>             EHL
>
>             On Thu, Feb 17, 2011 at 4:56 PM, Eran Hammer-Lahav
>             Is cookie exchanged for an access token? Authorization
>             grants are not meant to be useful by themselves, only
>                 On Thu, Feb 17, 2011 at 4:40 PM, Eran Hammer-Lahav
>                 I don’t understand how such an extension is expected
>                 to work with the existing grant types. The
>                 response_type parameter is used to identify if the
>                 flow being used is for an implicit grant or
>                 authorization code. Are you suggesting a new grant
>                 type? Are you suggesting additional response
>                     Without full requirements we can’t design an
>                     extension point. Asking to make this parameter a
>                     free text field is not helpful.
>
>                 - if specified by itself or in combination with token,
>                 it's returned in the End User Authorization Response,
>                 in analogy/in addition to the access_token
>
>                 - If specified in combination with code, it's returned
>                 in exchange for the code, in analogy with the access_token
>
>                     EHL
>
>                     - SAML provides session management. Facebook
>                     Connect provides session management. Both use
>                     cookies. These are authentication protocols but
>                     - OpenID2.0 does not provide session management.
>                     This has proven to reduce the value of OpenID and
>                     make it unsuitable for many scenarios.
>
>                     We would like federation protocols based on OAuth2
>                     to be high-value. We would rather that they not be
>                     be hacks built on top of OAuth2. That means that
>                     we need a first-order concept of cookie. A cookie
>                     can be refreshed independent of the grant
>                     associated with it. A cookie is something the
>                     client holds on to that identifies the user (i.e.,
>                     it's for user-client authentication), but that the
>                     client is happy to outsource the management of
>                     The cookie is produced and returned by the server,
>                     in combination with a grant, but it can be
>                     refreshed independently.
>
>                     This is a solid and proven use case, and is of
>                     fundamental value to many planned OAuth2
>                     implementations.
>
>                     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
>
>                     The best approach (at this point) is to leave the
>                     spec unchanged. However, another spec can update
>                     the definition of the response_type parameter,
>                     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
>                     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
>                     I do not think that extension parameters can
>                     handle this cleanly. In particular, if the
>                     response_type is neither code nor token.
>
>                         EHL
>
>                         - 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:
>
>                         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
>
>
>
>
>                     -- 
>                     Breno de Medeiros
>
>
>
>
>                 -- 
>                 Breno de Medeiros
>
>
>
>
>             -- 
>             Breno de Medeiros
>
>
>
>
>         -- 
>         Breno de Medeiros
>
>
>
>
>     -- 
>     Breno de Medeiros
>
>
>
>
> -- 
> Breno de Medeiros
>
>