On Wed, Apr 7, 2010 at 11:40 PM, John Panzer <jpan...@google.com> wrote:
>
>
> 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.
>
This seems to be an issue with all of the delegation profiles, and not
related to the username parameter.
Note that expected behavior in this case is unclear. If the secretary has
installed an app on her cell phone to view his boss' calendar, you clearly
do want to revoke access.
>
>
>>
>> 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
