On May 2, 10:01 am, Joseph Smarr <[email protected]> wrote:
> Erna-just getting to a detailed review of the diff now. Generally it looks
> good but here are a couple of things I think we should change:
>
> 1) If no oauth_token is provided on the authorization URL in 6.2.1 (e.g. the
> mobile/device case where the Consumer is unable to open a web browser
> directly), then I don't think the Provider should return an oauth_verifier
> to be enterered into the Consumer. Basically I'm suggesting we stick to
> OAuth 1.0 here, and the reasons are: a) the attack we're patching is much
> harder to pull off if you have to get the victim to go to a URL and then
> manually enter a request token, and b) many devices won't provide a way to
> enter text into them, so requiring the verifier be manually entered will
> exclude those valuable use cases.
No need to address this directly. Providers can just do it, they can
ignore the verification code, etc. Also, as noted in a different
thread, while I don't want to give up on such limited devices, are
there any using OAuth today? Trying to design a flow for a device we
don't know is hard. Trying to design user experience by starting from
a protocol is doomed to fail. I refuse to work on theoretical use
cases. If there are real ones (that is, actual products looking to use
OAuth on such a platform) out there, THEN we should discuss this.
> 2) I agree with commenters below that providing oob for oauth_callback feels
> dirty and ideally there would be a better way to distinguish 1.0A and 1.0
> Consumers. I really don't want to change version numbers to accomplish this,
> but maybe if we think a bit harder, we can come up with a good situation.
> For instane, if the Consumer sends oauth_callback on the authorization page,
> but not in the request token call, you know it's 1.0. I guess the hard part
> is if they don't send oauth_callback in either place, and you still respond
> with the verifier, how do you know when to expect it back or not. Hmm...
Yeah, it is a hack. We need a way to say "give me a verification code,
but I can't accept callbacks" and there is a real concern about using
empty parameters. We can make it less hackish by using some kind of
special URI scheme like 'info:oauth:oob' but then the ':' needs to be
encoded, we waste a few more bytes, and machines really don't care how
pretty the string is. Its a string literal.
The easiest alternative is to simply fork the endpoints. If any
provider looking to offer both flows (1.0 and 1.0a) is required to
support each flow under a different set of endpoints, this problem
goes away. In fact, I like this approach so much better, that I am
going to start a new thread about it.
> Which brings me to the discussion we had last week (but which I believe has
> NOT made it to the list) about how Providers can support both 1.0A and 1.0
> simultaneously for a while (which many will have to do). I would suggest
> adding this as an appendix (much as OpenID has a section on supporting both
> 1.1 and 2.0):
Meh. No new providers should support 1.0. There is absolutely no
reason for it. Since there is not discovery for OAuth, there is no
automatic interoperability. This means anyone writing applications
against new OAuth APIs using 1.0a will use 1.0a libraries. And are
there 1.0 providers out there who need the specification to help them
out? I find that hard to believe. There is simply no audience for such
a section.
> 3) Another suggestion we made last week was that rather than adding a *new*
> parameter to the Access Token request call (for oauth_verifier), which has
> the downside that it no longer matches the normal "oauth-signed URL call"
> signature of (token+secret+url) like request token and access token and
> protected resource access used to all share, instead you just append the
> oauth_verifier to the request token and send that up as before. This is more
> backwards-compatible in my mind and will make for a smoother transition of
> libraries and implementations. And it does not reduce the security at all.
> Anyone think this is a bad idea, and if so, why?
If anything, we should replace the Request Token with the verification
code (and use it with the existing Request Token Secret). But this is
just a bad idea all around. Everyone seems to figure out 'add a new
parameter', but we know all too well how 'concatenate these two
values' confuses the shit out of developers... (I can see the
questions now: "so do I encode each value first before I concatenate
them?").
EHL
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---
