On Wed, Apr 7, 2010 at 10:46 PM, Evan Gilbert <uid...@google.com> wrote:
>
>
>
> On Wed, Apr 7, 2010 at 9:29 AM, John Panzer <jpan...@google.com> 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.
>
Sorry, I was unclear. In the scenario I'm imagining, the boss has delegated
calendar access to his secretary, who uses this delegated access to hook up
an app to the calendar. The boss is very happy with this situation because
now his Zombieville reminders show up on his calendar. If the token is tied
to the secretary, and the secretary's account is shut down when the
secretary leaves, then the boss no longer sees the Zombieville reminders pop
up. He then complains that this sort of thing never happened with
password-based access!
I can imagine either scenario upon termination of the secretary -- you may
want to revoke all the tokens, some of the tokens, or none of the tokens.
>
> 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 <uid...@google.com> wrote:
>>
>>>
>>>
>>> On Wed, Apr 7, 2010 at 12:08 AM, Eran Hammer-Lahav
>>> <e...@hueniverse.com>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" <uid...@google.com> wrote:
>>>>
>>>>
>>>>
>>>> On Tue, Apr 6, 2010 at 11:07 PM, Eran Hammer-Lahav <e...@hueniverse.com>
>>>> wrote:
>>>>
>>>>
>>>>
>>>>
>>>> On 4/6/10 5:24 PM, "Evan Gilbert" <uid...@google.com> 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
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>>
>>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
