On Tue, Apr 6, 2010 at 12:21 AM, Eran Hammer-Lahav <e...@hueniverse.com>wrote:
> Hi Evan, > > On 4/5/10 4:28 PM, "Evan Gilbert" <uid...@google.com> wrote: > > > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > > In both flows, the authorization server should be able redirect back to > the > > callback URI without interacting directly with the resource owner if > access > > has already been approved. This is not ruled out in the current language > but > > it could be made cleaner. > > > > Suggested rewording - change > > > > "After receiving an authorization decision from the resource owner, the > server > > redirects the resource owner to the callback URI." > > > > to > > > > "If the client is already approved or denied for access to the protected > > resource, the authorization service MAY redirect the resource owner to > the > > callback URI immediately. If not, the authorization service SHOULD ask > the > > resource owner for an authorization decision and after receiving the > > decision redirect the resource owner to the callback URI." > > I opted for a simpler change: > > 'After receiving (or establishing via other means) an authorization > decision' > Sounds great > > > 2.4.1 Web Callback Flow & 2.4.2 Web Client Flow > > We should have an OPTIONAL username parameter: > > username > > The resource owner's username. The authorization server MUST only send > back > > refresh tokens or access tokens for this user. > > > > This is useful for clients where a user is already logged into a 3rd > party web > > site with a specific account, and the client wants the authorization to > match > > the specific user. > > I think introducing the concept of user identity is more complex than just > a > username parameter. I agree that it can be useful but we need a more > detailed discussion about this before we add it. > I agree issues around user identity are complex. Would it help to spin up a separate discussion thread on this one issue? > > 2.4.2 Web Client Flow > > Sending an access token as a query parameter is dangerous from a security > > perspective - these tokens are leaked via referrers and server logs. In > > previous WRAP discussions, it was felt that we should have a strong > > recommendation to use the URL fragment. > > > > Suggested wording: > > Client SHOULD send a callback URI with a query fragment, and > authorization > > server MAY reject callback URLs without a fragment for security reasons. > > Why not require it? I made the assumption that someone had use cases that drove the examples in the spec. I would be OK with requiring it. > EHL > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
