On Fri, Feb 18, 2011 at 7:17 AM, Paul Madsen <paul.mad...@gmail.com> wrote:
> 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? > 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'. > > 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). > See above. > > I confess I dont know how FB Connect does SLO > > thanks > > paul > > > On 2/17/11 7:22 PM, Breno wrote: > > 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 <e...@hueniverse.com>wrote: > >> 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:breno.demedei...@gmail.com] >> *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> >> 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] *On Behalf >> Of *Breno >> *Sent:* Thursday, February 17, 2011 10:30 AM >> *To:* 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 >> > > > > -- > Breno de Medeiros > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://www.ietf.org/mailman/listinfo/oauth > > -- Breno de Medeiros
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
