where is the relation between token version and HTTP authentication
scheme version?
regards,
Torsten.
Am 15.07.2010 23:34, schrieb Naitik Shah:
I though we'd come to a decision on the versioning too :) IMHO, it's
better to push this burden of versioning into the token itself if
necessary. I think it's better from a developers perspective to pass
an oauth_token, because it's cleaner. Most deployments will already
have versioned tokens to enable upgrading these for internal changes,
so why can't the OAuth version be contained in there too? Given the
option to simplify the implementation for a API provider (Big Company,
or someone who has to know how OAuth works) vs API consumer
(Developer, or someone who usually just wants some data), I hope
everyone agrees our focus should be the Developer.
While we (Facebook) didn't have OAuth 1.0 tokens to deal with and so
don't have the same backward compatibility issues, we've already
changed our tokens and introduced new ones a couple of times and this
had no impact on the parameter name being used.
-Naitik
On Thu, Jul 15, 2010 at 10:51 AM, Justin Richer <jric...@mitre.org
<mailto:jric...@mitre.org>> wrote:
It was discussed before, but I don't remember there being any
consensus
in the group. What are the practical reasons for not using "oauth2"
namespacing in the one place we still use namespacing? Most of
what I've
heard seems to sound like "I don't like it to have a 2 on it".
I don't want to have to set up the OAuth 2 system to have to catch
failed cases of the OAuth 1 protocol. A good OAuth 2 call and a bad
OAuth 1 call should be distinguishable from the start. Also, what
about
when we finally get a signed-request going? I would assume that that's
going to add back in things like oauth_signature, oauth_nonce, and the
other parameters whose absence you should filter on.
-- Justin
On Thu, 2010-07-15 at 13:37 -0400, David Recordon wrote:
> I thought this topic had been beaten to death before. An OAuth 1.0
> protected resource request includes a variety of oauth_ parameters
> whereas OAuth 2.0 just has oauth_token.
>
>
> --David
>
>
> On Thu, Jul 15, 2010 at 10:12 AM, Brian Eaton <bea...@google.com
<mailto:bea...@google.com>>
> wrote:
> On Thu, Jul 15, 2010 at 7:59 AM, Justin Richer
> <jric...@mitre.org <mailto:jric...@mitre.org>> wrote:
> > +1 on OAuth2 header, and I also want to see oauth2_token in
> URI and form
> > parameter methods.
>
>
> Good point about the query parameter names needing to be
> unambiguous.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
_______________________________________________
OAuth mailing list
OAuth@ietf.org <mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
