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
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
-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, 2010, at
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
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
-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 can give
- 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
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
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 jsm...@gmail.com wrote:
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
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:
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
On Tue, Apr 20, 2010 at 10:23 AM, Eran Hammer-Lahav e...@hueniverse.com 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
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
On Tue, Apr 20, 2010 at 11:16 AM, Eran Hammer-Lahav e...@hueniverse.com 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
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
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
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 record...@gmail.com
To: jsm...@stanfordalumni.org
Cc: OAuth WG oauth@ietf.org
Subject: Re: [OAUTH-WG]
On Tue, Apr 20, 2010 at 12:57 PM, Torsten Lodderstedt
tors...@lodderstedt.net 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
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
jsm...@gmail.commailto: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
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
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
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 experience.
It is
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
tors...@lodderstedt.net 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
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
29 matches
Mail list logo
