Blaine, Thanks for your clarification.
I think the key point you bring up is still missing from the spec: " server-side implementations should only allow requests that are made with an access token and the consumer key that was used to issue the access token. " If I as a consumer just assume that this is true, I could store the Access keys in a less secure manner since I think protecting my Consumer Secret is the main thing I need to focus on. I think the advantage of having this clearly pointed out in the spec is that Consumers would not need to worry about this, since Service Provider will need to take this into account to be OAuth compliant. Don't you agree? Thanks, - Ali On Feb 2, 3:42 am, Blaine Cook <[email protected]> wrote: > On 1 February 2010 19:58, Onmyouji <[email protected]> wrote: > > > It looks like to me that in the spec there is no requirement for some > > affinity between the Consumer Key/Consumer Secret, and the Access > > token. > > > Is this something that is considered out of scope? > > You're right, there's no spec-mandated affinity. However, server-side > implementations should only allow requests that are made with an > access token and the consumer key that was used to issue the access > token. We didn't specify this because there are viable scenarios where > you want access key portability. > > b. -- 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.
