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
