On 4/9/10 1:58 PM, "Evan Gilbert" <[email protected]> wrote:
>
>
> On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav <[email protected]>
> wrote:
>>
>>
>>
>> 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).
>
> This use case mostly just works & we're excited about using the OAuth flow
> this way. The premise that "no one should be granting client access to end
> user resources,
> except for the end user" is incorrect - we already support variant of this
> today at Google and it's a requirement for almost all enterprise use cases.
The user delegation flows are about an end user (specifically a human
resource owner) actively approving access. The scenario you are describing
is where the end user is actually something else, it is not a resource owner
but just "an entity capable of authenticating with the authorization
server".
In your scenario (which can use the same technical flow, but is a different
construct), the resource owner (domain admin) grants client access before
the flow begins, the client then sends an end user to the authorization
server to authenticate (often blindly, and nothing else), then the
authorization server acting based on the resource owner's grant, provide
access.
Your resource owner is by definition not the end user, and your end user is
by definition on a 'human resource owner'. So while the HTTP calls still
work, the prose is wrong.
If you feel that the current prose *prevents* you from implementing it as
required by your use case (which I don't think it does), we can add a
paragraph noting the special case where the resource owner and end user are
split.
EHL
> I had assumed that this is why the definition of resource owner is "An entity
> capable of granting access to a protected resource" - this wording covers both
> cases.
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
