Using the current draft, SPs now have to be able to determine/detect
the spec version being used (1.0 or 1.0a). This can be achieved by
either sending the oauth_callback when a request token is obtained or
by using alternate endpoints as you suggested. The SP now has to
essentially store the
On May 2, 2:19 am, Brian Eaton bea...@google.com wrote:
On Fri, May 1, 2009 at 1:43 AM, Blaine Cook rom...@gmail.com wrote:
1. None. Applications that cannot receive callbacks (or that have
static callback endpoints) should be configured as such in an
out-of-band flow, along with the
Option 3
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
OAuth group.
To post to this group, send email to oauth@googlegroups.com
To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com
For
else would it be about?).
EHL
-Original Message-
From: oauth@googlegroups.com [mailto:oa...@googlegroups.com] On Behalf
Of David Parry
Sent: Friday, May 01, 2009 5:57 PM
To: OAuth
Subject: [oauth] Re: Version Preference
Let's play devils advocate for a minute, considering
] On Behalf
Of David Parry
Sent: Friday, May 01, 2009 6:51 PM
To: OAuth
Subject: [oauth] Re: Version Preference
You're trying to maximize interoperability between the new and flawed
spec.
ie.
SP 1.0 - Consumer 1.0a
SP 1.0a - Consumer 1.0
On May 2, 11:22 am, Eran Hammer-Lahav e
Not incrementing the oauth_version for the new spec is a mistake imho.
It seems kinda flaky to me to switch between the specs 1.0/1.0a purely
based on whether the oauth_callback is sent when a consumer obtains a
request token.
--~--~-~--~~~---~--~~
You received
As a Service Provider, I want to be able to run both 1.0 and 1.0a (or
1.1) concurrently for a period of time while my consumers implement
the new version. Then disable 1.0 and return an error if a consumer
attempts to use the old version.
At least to me, this provides the easiest and most fail
