On 4/9/10 8:29 AM, "Evan Gilbert" <[email protected]> wrote:
>
>
> On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav <[email protected]>
> wrote:
>>
>>
>>
>> On 4/8/10 9:17 PM, "Evan Gilbert" <[email protected]> wrote:
>>
>>>
>>>
>>> On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav <[email protected]>
>>> wrote:
>>>>
>>>>
>>>>
>>>> On 4/7/10 9:20 PM, "Evan Gilbert" <[email protected]> wrote:
>>>>
>>>>> Authorization servers in the OAuth Web Callback flow and the User Agent
>>>>> flow
>>>>> should have the option to redirect back with access/refresh tokens without
>>>>> prompting the user, if the client has already been granted access to the
>>>>> protected resource.
>>>>>
>>>>> This is already implied by some of the text (3.4.3.1 "After receiving (or
>>>>> establishing via other means) an authorization decision from the resource
>>>>> owner", but is not supported by the example flows.
>>>>>
>>>>> Suggested changes
>>>>>
>>>>> 3.4.1 Web Callback Flow
>>>>>
>>>>> (B) The authorization server authenticates the end user (via
>>>>> the user-agent) and MAY prompt the end user to grant or deny the client's
>>>>> access request.
>>>>
>>>> How about instead:
>>>>
>>>> (B) The authorization server authenticates the end user (via the
>>>> user-agent)
>>>> and establishes whether the end user grants or denies the client's access
>>>> request.
>>>
>>> The end user doesn't always control the resource grant decision (as an
>>> example, a domain admin may grant access for users).
>>
>> No. Bu definition the end user (which is a specialized resource owner) is
>> the only party allowed to grant authorization. Whoever grants authorization
>> is the resource owner.
>
> Makes sense. To capture this, think we need to change
> "establishes whether the end user grants or denies" -> "establishes whether
> the resource owner grants or denies".
In this flow the resource owner is an end user. I have a problem with your
premise. No one should be granting client access to end user resources,
except for the end user. If this is a case where the end user is accessing
resources owned by someone else (the domain admin), the entire story is
broken (it has both a resource owner and end user who are different).
>>> Maybe "establishes whether the client has been granted access to protected
>>> resource"?
>>>
>>> However, looking at all of the variants, think these new phrasings leave
>>> some
>>> ambiguity. Ideally this will be clear to the reader that the user agent may
>>> return immediately or may interact with the end user.
>>
>> The spec should make the flow simple to understand to a first-time/casual
>> reader, and the basic scenario is where the user is prompted. As long as it
>> doesn't prevent other specializations, it should not become harder to follow
>> and more cryptic. It cannot tell a story without making some basic
>> assumptions.
>
> The basic scenario for the User Agent profile involves automatic redirects.
> The access tokens are short lived, and the profile is mostly useless unless
> authentication services support and clients use these redirects.
As soon as some security-minded folks review the proposal to add immediate
support for the user-agent flow, I'll add it in (I don't have objections).
EHL
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
