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. > 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). > 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 -~----------~----~----~----~------~----~------~--~---
