There are potentially three names for access tokens in this spec:
- token
- access_token
- oauth_token
You hit the /oauth/access_token endpoint, and get back access_token=blah. Then
you take that string and pass it to the protected resource as oauth_token=blah.
Developers that have prototyped t
On Apr 20, 2010, at 12:46 AM, Peter Saint-Andre wrote:
> On 4/18/10 6:46 PM, Dick Hardt wrote:
>
>> Given the practice that the authorization endpoint and the redirect_uri
>> can contain URI query parameters, then differentiating between
>> application specific query parameters and OAuth protocol
On 4/19/10 11:01 PM, Marius Scurtescu wrote:
> On Mon, Apr 19, 2010 at 9:50 PM, Dick Hardt wrote:
>>
>> On 2010-04-19, at 9:46 PM, Peter Saint-Andre wrote:
>>
>>> On 4/18/10 6:46 PM, Dick Hardt wrote:
>>>
Given the practice that the authorization endpoint and the redirect_uri
can contain
It's kind of hard to follow the discussion and to argue when the text being
discussed changes without notice. Uploading draft versions to tools.ietf.org is
really easy and the diff display is nicer. Btw, is it a working group draft
already? If it is, it really should be on tools.ietf.org so we g
> -Original Message-
> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
> Of John Kemp
> Sent: Tuesday, April 20, 2010 3:38 AM
> To: Peter Saint-Andre
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Issue: prefixing parameters with oauth_
>
> On Apr 20, 2
There is an explanation (I'm not defending it, just explaining).
In the flow endpoint I chose 'access_token' over token because of the refresh
token. It seems better to talk about two different kinds of tokens than to have
one generic 'token' and one with special meaning 'refresh_token'.
The pr
This attack is why the flow requires the client to present the callback it used
again when getting the token.
EHL
From: Evan Gilbert [mailto:uid...@google.com]
Sent: Monday, April 19, 2010 5:17 PM
To: Eran Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Issue: 'username' parameter proposal
There seems to be support for this idea with some concerns about complexity.
Someone needs to propose text for this including defining the request parameter
and schema of the various reply formats.
EHL
> -Original Message-
> From: Torsten Lodderstedt [mailto:tors...@lodderstedt.net]
> S
> -Original Message-
> From: Luke Shepard [mailto:lshep...@facebook.com]
> Sent: Monday, April 19, 2010 10:21 AM
> To: Eran Hammer-Lahav; OAuth WG
> Subject: RE: 'Scope' parameter proposal
>
> This seems pretty elegant to me. I like that in the general case, the
> protected
> resource c
- How is this proposal *better* than a separate scope parameter?
Instead of giving developers an outline of how to implement scope, you are
basically saying that they can already do with without an extra protocol
parameter and should go figure it out on their own (your proposal is pattern,
not
> -Original Message-
> From: Dick Hardt [mailto:dick.ha...@gmail.com]
> Sent: Monday, April 19, 2010 8:07 PM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: Re: [OAUTH-WG] 'Scope' parameter proposal
>
>
> On 2010-04-19, at 9:25 AM, Eran Hammer-Lahav wrote:
> > 2. Server requires authe
I'm normally no fan of namespaces or other forms of needless complexity, and
it's true that PoCo dropped the pdata_ prefixes to all its query parameters
that we'd originally proposed, but I do think there's something helpful and
and clear about oauth_ because it makes it so clear which parameters a
+1 to nailing down how to pass scopes, as Eran suggests (I think
space-delimited URLs is best, but that's a detail). Having implemented OAuth
with probably a dozen different providers (while at Plaxo), scopes were
always one of those things that just didn't fit cleanly into my libraries
and abstrac
+1 to including JSON format, and perhaps making it the required format. In
my experience helping numerous developers debug their OAuth implementations,
url-encoding/decoding was often a source of bugs, since a) the libraries are
usually hand-built, b) url-encoding is known to be funky/inconsistent
...and of course by "request format", I mean "response format". :)
BTW, note that the "trailing newline problem" with url-encoding is
particularly pernicious because a) it messes up the signature, and b) you
often can't see it when you print out your variables, so everything looks ok
and yet the s
Just to add some more context from experience, this "two users getting mixed
together" problem happens a lot in practice, esp. when you have a mix of
server-side and client-side auth. For instance, we saw this in our Facebook
Connect integration in Plaxo--normally the user connects and Plaxo stores
How about encoding requests as well. The request json blob could be
then URL encoded and added to the endpoint/callback URL with a
parameter like "oauth_json_request". This would solve the
prefix/collision problem.
Marius
On Tue, Apr 20, 2010 at 9:27 AM, Joseph Smarr wrote:
> ...and of course
In my experience, a frequent source of bugs/frustration for developers
implementing OAuth 1.0 was the fact that we have multiple "tokens" that are
easy to mix up and use in the wrong place. For instance, when I helped Dave
Winer debug his implementation (see
http://josephsmarr.com/2009/02/17/implem
I know we are all identity geeks and love to know the protocol we're using, but
most developers will just want to get the auth token and be done with it. They
don't care that they are using OAuth. There's no reason to beat them over the
head with it all over the place.
Having just implemented t
In an effort to move one:
Does anyone have a *blocking* objection to not adding a parameter name prefix
to the authorization and token endpoints? In other words, are you going to
block the specification (ask the chairs not to issue a consensus call) if it
doesn't have a prefix?
EHL
From: Luke
I still don't know where you stand on the actual proposal. Is the spec
currently confusing? If it is, please suggest alternatives.
EHL
From: Joseph Smarr [mailto:jsm...@gmail.com]
Sent: Tuesday, April 20, 2010 9:42 AM
To: Eran Hammer-Lahav
Cc: Luke Shepard; oauth@ietf.org
Subject: Re: [OAUTH-WG]
I'm not aware of anyone arguing against this feature. The only issue is a full
security review before we add it to the spec. If one of the security experts
here can spend a few minutes to review this, we can move forward and add it to
the draft.
EHL
From: Joseph Smarr [mailto:jsm...@gmail.com]
On Tue, Apr 20, 2010 at 10:23 AM, Eran Hammer-Lahav wrote:
> I’m not aware of anyone arguing against this feature. The only issue is a
> full security review before we add it to the spec. If one of the security
> experts here can spend a few minutes to review this, we can move forward and
> add it
Having examined the draft on github, it looks to me like the document
should be much more specific about the character encoding of
parameters that require internationalization. These include username,
password, and realm. I see a UTF-8 reference in the footnotes, but it
isn't used anywhere in the d
Is that an objection to including a username parameter in the spec?
EHL
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Tuesday, April 20, 2010 11:04 AM
> To: Eran Hammer-Lahav
> Cc: jsm...@stanfordalumni.org; OAuth WG
> Subject: Re: [OAUTH-WG] Issue: 'username
On Tue, Apr 20, 2010 at 11:16 AM, Eran Hammer-Lahav wrote:
> Is that an objection to including a username parameter in the spec?
Damn skippy.
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
In my experiences, such a review takes much longer than a few minutes.
I think the whole specification should be subject to a comprehensive and
in-depth security analysis (threat modeling, counter measures and so
on). So why not adding this parameter and examine its implications in
this contex
Because the rest of the spec did receive extensive review from both early
adopters and from the previous drafts it borrowed from. Nothing so far is a new
concept. The concept of an identity is new in OAuth, and while offers important
benefits, should not be added to the spec when there are actua
Having written an implementation last night against the web server
flow, I'm worried about adding JSON as a requirement for the response.
While it might be easier for environments with JSON libraries, it's
drastically more complex for environments (like embedded hardware)
which doesn't support JSON
I'm struggling to imagine hardware that on the one hand would support
OAuth, but on the other would be incapable of supporting JSON...
-Original Message-
From: David Recordon
To: jsm...@stanfordalumni.org
Cc: OAuth WG
Subject: Re: [OAUTH-WG] application/x-www-form-urlencoded vs JSON
Date
Hi all,
I would like to propose an additional variant of the Web Server Flow w/o
the need for direct communication between client and authorization
server in order to obtain authorized access/refresh tokens. Instead
access and refresh tokens should directly be send back with the redirect
to t
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
wrote:
> As a major advantage the authorization server can be stateless with respect
> to authorization transaction data because there is no need to hold such data
> until the client obtains the tokens from the authorization server (callback,
>
On the one hand, I'm sympathetic to the "easy to write a parser yourself"
argument for url-encoding, since in general I think you want to minimize any
toolchain/library requirements to maximize adoption. On the other hand, I'd
argue that OAuth 1.0 has shows url-encoding to be "deceptively easy" to
All the issues around encoding in 1.0 were about signatures. This is no longer
an issue.
EHL
On Apr 20, 2010, at 14:19, "Joseph Smarr"
mailto:jsm...@gmail.com>> wrote:
On the one hand, I'm sympathetic to the "easy to write a parser yourself"
argument for url-encoding, since in general I think
+1 to JSON as the one and only response format.
It is common enough. It is simple enough. It is flexible enough. It is
unambiguously specified enough.
I suggested a structure in the “application/credentials” thread.
http://www.ietf.org/mail-archive/web/oauth/current/msg01920.html
--
Jam
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt <
tors...@lodderstedt.net> wrote:
> Hi all,
>
> I would like to propose an additional variant of the Web Server Flow w/o
> the need for direct communication between client and authorization server in
> order to obtain authorized access/refresh
The OAuth 2.0 draft uses HTTP status code 400 for access token
requests that are denied.
Here is the definition of 400:
The request could not be understood by the server due to malformed
syntax. The client SHOULD NOT repeat the request without
modifications.
Status 400 should be used f
Folks-- I'm desperately trying to catch up on the list traffic after an
enforced couple of weeks away (pity me :-). This seems to be the freshest
scope thread; let me know if I'm missing a newer one. I just wanted to remind
people about the previous JSON-flavored proposal from the UMA group for
Eran,
>> "authz-uri=http://as.example.com/?scope=x2";
>> vs "authz-uri=http://as.example.com/"; and "scope=x2"
> - How is this proposal *better* than a separate scope parameter?
1 field is simpler than 2.
> Your proposal will produce a shorter specification,
> but not a simpler developer experi
FYI.
Original Message
Subject: RFC 5849 on The OAuth 1.0 Protocol
Date: Tue, 20 Apr 2010 16:58:22 -0700 (PDT)
From: rfc-edi...@rfc-editor.org
To: ietf-annou...@ietf.org, rfc-d...@rfc-editor.org
CC: rfc-edi...@rfc-editor.org
A new Request for Comments is now available in online
Am 21.04.2010 02:45, schrieb Evan Gilbert:
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
mailto:tors...@lodderstedt.net>> wrote:
Hi all,
I would like to propose an additional variant of the Web Server
Flow w/o the need for direct communication between client and
auth
I'm indetermined. Using JSON exclusively instead of form encoded
parameters would give us the possibility to use structured parameters
(in and outbound) instead of a flat parameter list, which I would like
very much. But there are propably use cases where form encoded
parameters are better suit
+1
I would propose to use appropriate HTTP status codes where possible.
Especially wrong parameters (violated precodition) and
authentication/authorization related errors should be signaled
differently. I think status code 400 is ok for the first category,
status codes 401 and probably 403 ar
+1, but why "where possible" (vs always)?
Igor
Torsten Lodderstedt wrote:
+1
I would propose to use appropriate HTTP status codes where possible.
Especially wrong parameters (violated precodition) and
authentication/authorization related errors should be signaled
differently. I think status
44 matches
Mail list logo
