On Sun, Oct 4, 2009 at 5:02 PM, Richard Barnes <[email protected]> wrote: > > Hey James, > > [copying IETF list since we're starting to get into protocol design stuff] > >> Is there really a requirement to make sure a Consumer can't hand off the >> access token? > > It's a question security requirements, i.e., what attacks the SP is > worried about, i.e., how strongly they want to protect their users' > data. If they allow Consumers to hand off access tokens, then they're > opening themselves up to Consumers that hand off tokens to bad people.
Nothing can prevent a Consumer acting as a proxy for a third party. So, in practice, once you've given the access token to the Consumer, you've given him the ability to delegate - albeit painfully. Given that reality, it might make sense to formalise delegation, and allow a Consumer to generate a delegated token, perhaps with reduced authority, e.g. a read-only token from a read-write one, which he could then pass on to the third party. Presumably from the keeping-the-user-informed perspective, requiring the Consumer to go back to the SP would allow the SP to track (and revoke) delegations. > >> Of course, neither the Service nor the User can prevent the Consumer handing >> off the access token and Consumer credentials to another party. > > That's true; the best a security protocol can ever do is reduce a > problem to the security of keys. Usually this is enough, especially > if keys are hard for the Consumer to replace (e.g., if they're tied to > an expensive certificate). Expensive certificates, I am told, are bought with stolen credit cards by the bad guys. So, they're free, pretty much, for the bad guys and expensive for the good guys. Which seems the wrong way round. >> I am particularly interested as I believe request signing would be >> significantly improved if it only used the access token (and not the >> Consumer credentials). The Consumer is implied as they were authenticated >> when the access token was issued. > > Again, it's a question of the SP's security requirements. IMHO, > authenticating access requests makes for a more secure protocol with > not much more cost (the credentials are already there, since Consumer > already has to authenticate to the SP to get the request token). But > YMMV. Maybe we need an "OAuth Security Requirements" draft? Or just > a rev/clarification to draft-barnes-oauth-model? > > --Richard > > > >> >> >> James Manger >> [email protected] >> Identity and security team — Chief Technology Office — Telstra >> >> >> > >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
