You could imagine the use case of a licensing server sitting separate
from the service provider that validates whether someone has the
proper rights to view certain content.
That's one possibility...
Sent from my iPhone 2G
On Feb 2, 2010, at 9:44 AM, Richard Barnes <[email protected]>
wrote:
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
.
--
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.
