For 1), the community needs to make a concious decision to turn our backs on
a set of use cases for devices that can't take direct input. These include
smart picture frames that come with a pre-generated request token on a
piece of paper and instructions to go activate them (e.g. so you can give
1.) Well we should really not use a three legged approach for these devices.
Reason: these consumers are not going to have multiple users. I suggest
a two legged approach instead.
2.) I don't see it as a hack. We are telling the SP hey, we don't want to
use a callback. This parameter is
I would prefer it to have a value - for .net the usual way of
accessing the form and querystring parameters returns null if the
parameter is not there or has no value. To implement an empty value
we would have to make two checks to see if the key is present and then
check to see if it has a
On Fri, May 1, 2009 at 9:07 AM, chris.s.ad...@googlemail.com
chris.s.ad...@googlemail.com wrote:
I would prefer it to have a value - for .net the usual way of
accessing the form and querystring parameters returns null if the
parameter is not there or has no value. To implement an empty value
On Thu, Apr 30, 2009 at 5:28 PM, Josh Roesslein jroessl...@gmail.comwrote:
Dirk,
I see now what you are getting at. Yes I guess the SP could use a signature
to generate the verifier, so it would not need to persist it.
As long as the signature secrete changes ever so often, I don't think an
On 4/30/09 3:25 AM, Eran Hammer-Lahav wrote:
2. Since this change is small, I would like to give it a short review
period before another draft. Please submit all your comments by May
8th.
Looks fine! Nicely done.
--
Dossy Shiobara | do...@panoptic.com | http://dossy.org/
On Thu, Apr 30, 2009 at 9:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Please review:
http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html
I did my best to keep the changes to a bare minimum and to avoid any
editorial changes to make comparison trivial:
I believe oob stands for out-of-band here, meaning the consumer cannot handle
callbacks so an out-of-band mechanism should be used.
I think the modifs are clear enough, with a preference to leave the
oauth_callback
set to an empty string instead of oob (as Blaine indicated).
One nitpick: a
On Thu, Apr 30, 2009 at 2:29 PM, Hubert Le Van Gong hubert...@gmail.com wrote:
One nitpick: a non-guessable value is not very precise. Why not saying
something like a UUID (even though it may not have to be unique).
because in those cases where it has to be manually inputted by the
user it
I was say that 'oob' would mean that the new auth.-flow, which means
that any callback received on the authentication-page would be
ignored..
A non-'oob'/non-url/non-existing callback received in the request-token
step means the usual flow, which means that callbacks received on the
auth.-page
On Thu, Apr 30, 2009 at 12:25 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Please review:
http://oauth.googlecode.com/svn/spec/core/1.0a/drafts/1/oauth-core-1_0a.html
Nice changes. A few points
* oob: Can it be described at first use or renamed to something
that makes immediate sense?
On 4/30/09 7:19 AM, Blaine Cook wrote:
Looks good, with the exception of the 'oob' value – why not just say
that an empty OR absent callback parameter fulfills the same role as
'oob'? There are also plenty of service providers that require static
configuration of the callback, and in those
Dossy Shiobara wrote:
On 4/30/09 7:19 AM, Blaine Cook wrote:
Looks good, with the exception of the 'oob' value – why not just say
that an empty OR absent callback parameter fulfills the same role as
'oob'? There are also plenty of service providers that require static
configuration of
On Thu, Apr 30, 2009 at 5:38 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Also, do we need another value to indicate a desktop client that doesn't need
the verifier?
Will the revised protocol allow for (desktop) consumers who *don't
need* the verifier or should the protocol ask for
@googlegroups.com
Subject: [oauth] Re: OAuth Core 1.0 Rev A, Draft 1
On Thu, Apr 30, 2009 at 5:38 PM, Eran Hammer-Lahav
e...@hueniverse.com wrote:
Also, do we need another value to indicate a desktop client that
doesn't need the verifier?
Will the revised protocol allow for (desktop
On Thu, Apr 30, 2009 at 6:11 PM, Blaine Cook rom...@gmail.com wrote:
No version changes required, no oob value for the callback parameter
required, either.
wouldn't it help with detecting the consumers that are able to follow
the revised protocol even if unable to get the redirect? i.e. those
On Thu, Apr 30, 2009 at 5:23 PM, Luca Mearelli luca.meare...@gmail.com wrote:
wouldn't it help with detecting the consumers that are able to follow
the revised protocol even if unable to get the redirect? i.e. those
able to close the loop passing the verifier code but requiring the
user to
On Thu, Apr 30, 2009 at 7:02 PM, Mike Malone mjmal...@gmail.com wrote:
oauth_callback in 2nd step:
- Present and wasn't in 1st step - no verifier requirement if allowed by
the server, potential stronger warning (should be deprecated eventually)
...
So there's a loophole.
A more draconian
From Eran's summary of the proposal there are three ways to close the loop:
(1) Verifier + Callback
(2) Verifier + Manual entry
(3) No verifier + manual 'continue'
The options for the SP would be:
oauth_callback in 1st step:
- Present with value - do (1)
- Present with empty value - do
On Thu, Apr 30, 2009 at 5:50 PM, Breno de Medeiros br...@google.com wrote:
I do not see how an empty value is an improvement from a non-valid
URI. It may not cause problems, but we don't know that. Let's play
safe and if people are unhappy with 'oob', then say 'outofband' or
something.
Not
Eran,
Great stuff, I like the direction of this fix.
My only worry is calling it 1.0a. I'd rather see this called 1.1. Two
arguments:
1) this is an important change to the protocol.
2) there needs to be a clear message for providers who have upgraded
to the latest protocol. The difference
On Thu, Apr 30, 2009 at 7:08 PM, Mike Malone mjmal...@gmail.com wrote:
I don't know, is it? I was under the impression that the rev was designed to
preserve backwards compatibility and leave the decision up to SPs.
Right; (I think) the 1.0 consumers will only break if an SP has
upgraded to
SP's could run both version at the same time to allow consumer time to
upgrade to the new spec.
The version being used can be detected with the oauth_version parameter.
On Thu, Apr 30, 2009 at 1:22 PM, Blaine Cook rom...@gmail.com wrote:
On Thu, Apr 30, 2009 at 7:08 PM, Mike Malone
On Thu, Apr 30, 2009 at 7:55 PM, Blaine Cook rom...@gmail.com wrote:
In cases where callbacks are not supported, there should never be the
option to flip back and forth. Either the application supports
callbacks, or it doesn't, end of story.
agreed, this is the most secure way.
Do you think
On Thu, Apr 30, 2009 at 8:08 PM, Mike Malone mjmal...@gmail.com wrote:
On Thu, Apr 30, 2009 at 10:57 AM, Blaine Cook rom...@gmail.com wrote:
On Thu, Apr 30, 2009 at 6:54 PM, Mike Malone mjmal...@gmail.com wrote:
This would break the web flow for 1.0 (non Rev. A) consumers.
I think that's
How 1.0a should deal with 1.0 is outside the scope of the spec. The only thing
we need to make sure is that a 1.0a server can detect which flow the client is
trying to use, and make its own decision on how to handle it.
The best tool we have is the oauth_callback parameter in the first step. We
Section 6.3.2: The verification code received from the Consumer is
identical to the verification code provided to the User via the redirection
or manually.
I'm not sure this is the right way to describe what the SP needs to do. When
they redirect the User back to the Consumer in step 6.2.3, they
To me this wording makes sense.
Basically it's saying the verification code the consumer submits to exchange
for an access token must match the verifier the SP generated for the
callback.
This verifies the user returning to the consumer is the same user who
authorized the consumer on the SP.
The
Dirk,
I see now what you are getting at. Yes I guess the SP could use a signature
to generate the verifier, so it would not need to persist it.
As long as the signature secrete changes ever so often, I don't think an
attacker could compromise this method. But to me the wording of that section
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
Proposed Google searches:
jar+version+nightmare
dll+version+nightmare
development framework of choice+version+nightmare
On Thu, Apr 30, 2009 at 7:17 PM, Josh Roesslein jroessl...@gmail.com wrote:
How will calling this 1.1 slow down the upgrade process? All libraries need
to change to cover
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
For what it's worth, this draft looks good to me.
Agreed that oob is a bit obscure. The first hit for a google search
on oob lists a page with a dozen possibilities (including the right
one), and the other hits on the first page are red herrings. Some
suggestions:
oauth_callback=none
Actually I kind of like none, but that might just be the python talking in
me. none might make it more clear the parameter isn't used, but I would be
fine with oob.
On Thu, Apr 30, 2009 at 11:49 PM, Brian Slesinsky bslesin...@gmail.comwrote:
For what it's worth, this draft looks good to me.
34 matches
Mail list logo
