On Fri, Apr 9, 2010 at 10:08 PM, Eran Hammer-Lahav <[email protected]>wrote:
> > > > 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. > Not sure I parsed this. The only significant difference I'm suggesting to covert is to change "end user" to "resource owner", which I think is only additive in the use cases it supports. > 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. > The current prose doesn't allow for the domain user granting access. This limitation is one that authorization services in practice will likely ignore, but I'd rather the spec state more explicitly allow domain-admin granted access as an option. It's a really good thing that the spec would require such minimal changes to support the domain admin granted use case, and I think we can find terminology that supports both without confusing it for the end-user granting use case. Note that this flow is really important if you want OAuth 2.0 to be useful and relevant in the enterprise - end-users typically won't be given direct authority to share their data with 3rd parties. > 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
