On Wed, Apr 7, 2010 at 9:29 AM, John Panzer <[email protected]> wrote:
> 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.
Note that the "resource owner" in this case is the secretary, not his boss.
Resource owner is "An entity capable of granting access to a protected
resource."
Since access tokens are bound to the resource owner ("A unique identifier
used by the client to make authenticated requests on behalf of the resource
owner."), I think in this case the system would have a clear way to revoke
access to the document.
Updating the wording on the proposal slightly to clarify (also changing
format to new parameter formatting)
Before:
username
The resource owner's username. The authorization server MUST only send
back refresh tokens or access tokens for the user identified by username
Current:
username
OPTIONAL. The resource owner's username. The authorization server MUST
only send back refresh tokens or access tokens *capable of making requests
on behalf of* the user identified by username
>
> 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
