Sure, but it's not easy to early branch, you have to actually parse the
whole header. It's also fragile if extensions are not careful.
________________________________
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On
Behalf Of Naitik Shah
Sent: Thursday, July 15, 2010 4:38 PM
To: Torsten Lodderstedt
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] OAuth vs OAuth2 in Authorization header
The formats for 1.0 and 2.0 are sufficiently different that it
is possible to unambiguously figure out what version is being used.
-Naitik
On Thu, Jul 15, 2010 at 3:56 PM, Torsten Lodderstedt
<tors...@lodderstedt.net> wrote:
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> 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>
> wrote:
> On Thu, Jul 15, 2010 at 7:59
AM, Justin Richer
> <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
>
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
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
