I can live with SHOULD.
> -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] > On Behalf Of Eran Hammer-Lahav > Sent: Tuesday, July 13, 2010 10:30 AM > To: Colin Snover; David Recordon > Cc: OAuth WG > Subject: Re: [OAUTH-WG] ' force_auth' request parameter > > > > > On 7/13/10 10:24 AM, "Colin Snover" <ietf....@zetafleet.com> wrote: > > > The problem I see with pushing this up into an identity > layer is > > that providers that choose to implement their own identity > layer (or > > no identity > > layer) may still end up doing this implicit authorization > thing. We¹re > > neither providing a specific identity to connect nor are we > requesting > > identity information from the provider<we simply want to make sure > > that the provider is not re-using any previous authorizations (a > > session cookie is just an authorization key by another > name), because > > doing so leads to the scenarios I¹ve written about (and > probably others that I have not considered). > > > > Under an authorization system that did not require the use > of a Web > > browser, I would agree much more strongly with the notion that this > > should be part of a separate layer, but the problem is that > the spec > > *does* utilize Web browsers heavily, and so we need to make > > considerations for the spec keeping that in mind. > > > > To address Eran¹s concern about overstepping bounds, perhaps the > > language could be changed from MUST to SHOULD, which would > leave it up > > to the provider to make the ultimate decision whilst still > being in compliance with the spec? > > I certainly don¹t want to step on any toes in that regard, > but I also > > don¹t want providers to think they can ignore this just > because it¹s a > > little easier to do so. > > A SHOULD directive works better with an extension than core. > Inclusion in core means it is, well, core... > > EHL > > > Regards, > > > > > > On 13/07/2010 11:57, David Recordon wrote: > >> I support immediate and a form of forced auth (ala > OpenID's PAPE) but > >> not in the core spec. They both should be part of an > identity extension. > >> > >> > >> > >> On Tue, Jul 13, 2010 at 9:51 AM, William Mills > <wmi...@yahoo-inc.com> wrote: > >> > >>> > >>> > >>> I agree with Colin that some form of force_auth is needed. I > >>> haven't read enough on the "immediate" proposal, but I > know that we > >>> have run into the problem of trusting currently set > cookies in the > >>> browser (even when we're actually sending a username/password and > >>> really do want to have an authentication). > >>> > >>> > >>> > >>> I'm a +1 on the force_auth proposal. > >>> > >>> > >>>> > >>>> > >>>> > >>>> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > >>>> Behalf Of Colin Snover > >>>> Sent: Tuesday, July 13, 2010 9:23 AM > >>>> To: Eran Hammer-Lahav > >>>> Cc: OAuth WG > >>>> Subject: Re: [OAUTH-WG] ' force_auth' request parameter > >>>> > >>>> > >>>> > >>>> > >>>> On 22/07/28164 13:59, Eran Hammer-Lahav wrote: > >>>>> The following was submitted via the shared-copy page > but does not > >>>>> belong with editorial feedback. This needs to be discussed and > >>>>> supported on the list before added the specification. I > think it > >>>>> belongs where Oimmediate¹ is specified. > >>>>> > >>>>> EHL > >>>>> > >>>>> ------ Forwarded Message > >>>>> > >>>>>> From: An anonymous reader <mail...@sharedcopy.com > >>>>>> <http://mail...@sharedcopy.com> > > >>>>>> Date: Sat, 10 Jul 2010 11:01:11 -0700 > >>>>>> To: Eran Hammer-Lahav <e...@hueniverse.com > >>>>>> <http://e...@hueniverse.com> > >>>>>> > > >>>>>> Subject: Re: draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > >>>>>> > >>>>>> > >>>>> > >>>>> > >>>>>> "Colin Snover" left these comments on your copy: > >>>>>> > >>>>>> draft-ietf-oauth-v2-09 - The OAuth 2.0 Protocol > >>>>>> <http://r6.sharedcopy.com/6bnqq8v> > >>>>>> > >>>>>> > >>>>>> As proposed on the ML, a new parameter to counteract the > >>>>>> current behaviour of OAuth 1.0a authorization servers > which is to > >>>>>> assume that the account logged into the user-agent is > the account > >>>>>> that should be checked for access: > >>>>>> > >>>>>> force_auth > >>>>>> OPTIONAL. The parameter value must be set to > "true" or "false". > >>>>>> > >>>>>> If set to "true", the authorization server > MUST prompt > >>>>>> the end-user to authenticate and approve access. The > >>>>>> authorization server MUST NOT make any assumptions as to the > >>>>>> identity of the entity requesting access, even if > another automatic mechanism is available to do so (e.g. > >>>>>> browser cookies). > >>>>>> > >>>>>> If set to "false" or not present, the authorization > >>>>>> server MAY automatically grant access to the client if > it is able > >>>>>> to determine that access was previously granted. > link » > >>>>>> <http://r6.sharedcopy.com/6bnqq8v#shcp21> > >>>>>> > >>>>>> > >>>>>> tools.ietf.org/html/draft-ietf-oauth-v2-09 > >>>>>> <http://tools.ietf.org/html/draft-ietf-oauth-v2-09> > >>>>>> <http://r6.sharedcopy.com/6bnqq8v> · Original page > >>>>>> <http://tools.ietf.org/html/draft-ietf-oauth-v2-09> > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>> via sharedcopy.com <http://sharedcopy.com> > >>>>>> <http://sharedcopy.com/?ef> > >>>>>> > >>>>>> > >>>>> > >>>>> ------ End of Forwarded Message > >>>>> > >>>> > >>>> Hi Eran, > >>>> > >>>> Sorry if that was not the right place for that to go; I didn¹t > >>>> know what else to do. I have tried to solicit feedback > from the ML > >>>> regarding this parameter twice and nobody seems very keen in > >>>> providing any, which is kind of a bummer. I waited until > the last > >>>> possible moment to add it in the hopes that someone > would notice my > >>>> messages and discuss it, but you made it sound like your > plan was > >>>> for draft 10 to be potentially final so I wanted to get > it in before the deadline. > >>>> > >>>> I¹m sure this is not a big deal for most applications > that expect > >>>> at most a single connection, but for me this is a huge > deal since > >>>> it completely immolates our application¹s authentication > flow, and > >>>> I can¹t go to every provider asking them to please > change the way > >>>> they implement the authentication portion of their OAuth API. > >>>> > >>>> In contrast to Oimmediate¹, which had some concerns vis à vis > >>>> security, force_auth is actually safer than the current > normal flow > >>>> used by most OAuth providers since it requires the > provider to make > >>>> no guesses about who is trying to authorize the app. > >>>> > >>>> Frankly, I think that OAuth providers do the wrong thing now in > >>>> all cases by assuming that browser cookies are a safe way of > >>>> confirming the identity of the end-user making an authorization > >>>> request (they aren¹t!), but the spec says the way the > authorization > >>>> server authenticates the end-user is outside the scope > of the spec. > >>>> I have no objection to this<OAuth *should* be > >>>> authentication-agnostic<but at the same time this is a very real > >>>> and present implementation flaw and the only way to > solve it is to > >>>> make sure the spec defines a way for an application to > say ³hey, I > >>>> know you *think* you know who should be authenticated, > but *I* know > >>>> that the user has requested to connect a *new* account, > so don¹t use any automatic authentication method². > >>>> > >>>> I think it is incredibly important that the OAuth spec gets > >>>> providers to distinguish between automatic & potentially unsafe > >>>> authentication methods (like session cookies) versus more > >>>> ³guaranteed² authentication (like password), especially since > >>>> 99.999% of the time OAuth relies on the end-user¹s Web browser > >>>> which is all but guaranteed to contain some cookies for > the provider that are unrelated to the requesting application. > >>>> > >>>> Examples: > >>>> > >>>> 1. Multiple end-users with malicious intent. User 1 is > logged into > >>>> their Facetweetr account. User 2 wants to do bad things > using User 1¹s account. > >>>> Because the user-agent has cookies for user 1, user 2 gets to > >>>> authorize their account with our app. Even when user 1 changes > >>>> their password, unless the provider automatically > invalidates their > >>>> existing connections (the spec does not even mention > doing this in > >>>> an informative manner as far as I can tell), they are almost > >>>> certainly unaware that the linked application is still > able to perform actions on their behalf. > >>>> > >>>> 2. Single end-user with multiple accounts. User is logged into > >>>> Facetweetr account 1, but they want to authorize account > 2. They go > >>>> to authorize the application and are presented with a > confirmation > >>>> for account 1. They log out (because this is the only > way to switch > >>>> accounts on the provider) and suddenly the authorization flow is > >>>> dropped on the floor. The user may not know immediately > what they > >>>> need to do at this point. They will need to manually > return to the > >>>> original application and restart the authorization request. > >>>> > >>>> 3. User has two accounts that they want to authorize with a > >>>> provider. User authorizes account 1 successfully, then > wants to authorize account 2. > >>>> Because account 1 is still logged in, and because the > application > >>>> already has a link to the account, it automatically > redirects back > >>>> to the application¹s redirection URI. In order for the > user to get > >>>> what they want, they are forced to manually navigate to the > >>>> provider¹s site, log out, > >>>> *then* begin the authorization request. > >>>> > >>>> These aren¹t imaginary scenarios; they are things that > are going > >>>> on *right > >>>> now* with several different OAuth providers. > >>>> > >>>> The original request: > >>>> <http://www.mail-archive.com/oauth@ietf.org/msg02331.html> > >>>> > >>>> Regards, > >>>> > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
