Re: [OAUTH-WG] Issue: 'username' parameter proposal

The scenario described by Evan is showing a real issue and the
username parameter is solving it. Not sure if there are other
implications, but definitely worth discussing.

Marius

On Mon, Apr 19, 2010 at 10:06 AM, Evan Gilbert <uidude@google.com> wrote:
> User 1 is logged into Client site
> User 2 is logged into IDP site
> This can happen quite frequently, as client sites often have long-lived
> cookies and may only be visited by one user on a shared computer.
> Right now client site has no way to ask for a token for User 1, and end
> result will be that User 1 starts seeing User 2's data.
> On Mon, Apr 19, 2010 at 8:37 AM, Eran Hammer-Lahav <eran@hueniverse.com>
> wrote:
>>
>> How can they both be logged in? I have never seen a case where two users
>> can be both logged into to the same service at the same time...
>>
>> EHL
>>
>>
>> On 4/19/10 8:33 AM, "Evan Gilbert" <uidude@google.com> wrote:
>>
>> More details on this enhancement.
>>
>> Goal: Make sure you get an access token for the right user in immediate
>> mode.
>>
>> Use case where we have problems if we don't have username parameter:
>>
>> Bob is logged into a web site as bob@IDP.com.
>> Mary (his wife) is logged into IDP on the same computer as mary@IDP.com
>> A request is made to get an access token via the User-Agent flow in
>> immediate mode (or with any redirect without prompting the user)
>> -ob now has an access token for Mary and (posts activities, schedules
>> events, gets contacts) as Mary
>> Hilarity ensues
>>
>> Secondary goal: Provide a hint for non-immediate mode
>>
>> On Thu, Apr 15, 2010 at 11:55 AM, Eran Hammer-Lahav <eran@hueniverse.com>
>> wrote:
>>
>> Evan Gilbert proposed a 'username' request parameter to allow the client
>> to
>> limit the end user to authenticate using the provided authorization server
>> identifier. The proposal has not been discussed or supported by others,
>> and
>> has not received a security review.
>>
>> Proposal: Obtain further discussion and support from others, as well as a
>> security review of the proposal. Otherwise, do nothing.
>>
>> EHL
>>
>> _______________________________________________
>> 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
>
>