Blaine, Could you briefly describe what those cases are? I'm imagining something where you have one box that does the OAuth stuff and a separate one that actually accesses the resources; is that on the right track?
--Richard On Tue, Feb 2, 2010 at 6: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. > > -- 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.
