On Fri, Apr 9, 2010 at 11:02 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> > > > On 4/9/10 8:29 AM, "Evan Gilbert" <uid...@google.com> wrote: > > > > > > > On Thu, Apr 8, 2010 at 11:50 PM, Eran Hammer-Lahav <e...@hueniverse.com> > > wrote: > >> > >> > >> > >> On 4/8/10 9:17 PM, "Evan Gilbert" <uid...@google.com> wrote: > >> > >>> > >>> > >>> On Thu, Apr 8, 2010 at 12:22 AM, Eran Hammer-Lahav < > e...@hueniverse.com> > >>> wrote: > >>>> > >>>> > >>>> > >>>> On 4/7/10 9:20 PM, "Evan Gilbert" <uid...@google.com> 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. 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. > > >>> 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 OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
