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' > 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. > 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? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
