I'm assuming that tokens need not be bound to a specific user (typically they are, but imagine a secretary granting an app access to his boss's calendar and then leaving the company and therefore being removed from the calendar ACL, but the app still keeping access by virtue of the capability granted by the token). In this case, the proposed wording seems kind of problematic for a MUST.
On Wed, Apr 7, 2010 at 8:22 AM, Evan Gilbert <[email protected]> wrote: > > > On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav <[email protected]>wrote: > >> What about an attacker changing the username similar to the way a >> callback can be changed? >> > > I don't think there is a danger here. > > We still use all of the safeguards in place from the rest of the flow - > adding this parameter never log you in when omitting the parameter would not > have. It will just create more error responses. > > >> >> EHL >> >> >> >> On 4/6/10 11:14 PM, "Evan Gilbert" <[email protected]> wrote: >> >> >> >> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <[email protected]> >> wrote: >> >> >> >> >> On 4/6/10 5:24 PM, "Evan Gilbert" <[email protected]> wrote: >> >> > Proposal: >> > In 2.4.1 & 2.4.2, add the following OPTIONAL parameter >> > username >> > The resource owner's username. The authorization server MUST only send >> back >> > refresh tokens or access tokens for the user identified by username. >> >> What are the security implications? How can the client know that the token >> it got is really for that user? >> >> >> Think the client has to trust the auth server, in the same way as with the >> username + password profile. The auth server can always send back a scope >> for a different user. >> >> Worst case is that there is an identity mismatch between client and the >> identity implicit in the authorization token. This mismatch is already >> possible, and I don't think the username parameter makes the problem worse. >> >> >> EHL >> >> >> >> > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
