That's right. It would help various extensions as well.
On Thu, Jun 10, 2010 at 8:05 AM, John Panzer jpan...@google.com wrote:
So the thinking is that this is just a generic include or one level of
indirection feature that is orthogonal to other flows?
FWIW, I really like that notion. It's
On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz balf...@google.com wrote:
On Wed, Jun 9, 2010 at 4:05 PM, John Panzer jpan...@google.com wrote:
So the thinking is that this is just a generic include or one level of
indirection feature that is orthogonal to other flows?
FWIW, I really like
Hi,
As I've been working through our oauth2 implementation I've noticed that
it's not easy to disambiguate OAuth 1.0a vs 2.0 API calls based on the
request parameters alone. Based on some investigative at the Shindig
project it appears that the only standard way to to determine 1.0a vs 2.0 is
Thanks Marius.
I've answered your question below.
On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu mscurte...@google.comwrote:
I've always considered an authorization as a tuple of
client_id,user,scope,issue_date. If an authorization has been approved,
and
another request for
The request is very different on the resource server. On the authorization
server, why would you use the same endpoint?
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul
Lindner
Sent: Thursday, June 10, 2010 8:24 AM
To: OAuth WG (oauth@ietf.org)
Subject:
no one in the WG having an opinion on this topic?
Am 09.06.2010 12:19, schrieb Torsten Lodderstedt:
Hi all,
I would like to see support in OAuth2 for the authorization of
arbitrary scopes in a single authorization flow for all kinds of
deployments. In some deployments this may require to
I strongly believe that it should be an extension. Even optional
response parameters increase the complexity for client developers and
this in particular affects the data model used to store access tokens.
--David
On Thu, Jun 10, 2010 at 8:46 AM, Torsten Lodderstedt
tors...@lodderstedt.net
I am talking about the resource server. Specifically I want to be able to
quickly determine if an incoming request is 1.0a vs 2.0. And since this is
a library it can't make a lot of assumptions about the specific environment
it's running in.
At first I thought I would check the oauth_version
I thought I had already written this, but I guess the e-mail never went
anywhere...
I do have a strong opinion on Torsten's proposal, and it is POSITIVE.
A nit pick: I would replace Array with List, to read A list of
access tokens issued...
Igor
Torsten Lodderstedt wrote:
no one in the
The proposed error codes all seem reasonable but it would be good to call them
out in the spec so there are common understandings of how to handle the
situation.
RFC 5746 matters because the TLS renegotiation attack is particularly potent
against exactly the kind of web services that would use
There are two requests that have type=web_server (but they are
directed to different endpoints):
- 2.5.1. Client Requests Authorization
- 2.5.2. Client Requests Access Token
The is the only case when a type is used for more than one request.
While the spec can work perfectly fine like this, if
I agree. Clarity is essential, and if this is not fixed now, it will
stay like that forever.
In fact, I would define 'type=web_server_auth' for 2.5.1 and
'type=web_server_token' for 2.5.2.
Igor
Marius Scurtescu wrote:
There are two requests that have type=web_server (but they are
directed
On Thu, Jun 10, 2010 at 8:35 AM, Andrew Arnott andrewarn...@gmail.com wrote:
Thanks Marius.
I've answered your question below.
On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu mscurte...@google.com
wrote:
I've always considered an authorization as a tuple of
I run into the same issue. In section 4.2. URI Query Parameter, it
would help if the parameter name, oauth_token, was different from
OAuth 1.
Marius
On Thu, Jun 10, 2010 at 9:41 AM, Paul Lindner lind...@inuus.com wrote:
I am talking about the resource server. Specifically I want to be able to
But in that case, all the other oauth_* parameters are missing. It's trivial.
EHL
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, June 10, 2010 10:39 AM
To: Paul Lindner
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re:
I am implementing an OAuth 2 library and the format parameter does not
feel right.
If a client is using a library then the response format should be
totally transparent to the client. The library may have a setting if
the client wants to force a format for whatever reason, but individual
messages
Pick or suggest new ideas:
* Endpoint used to interact with the end-user
End-user Endpoint
Front Channel Endpoint
Authorization Endpoint
End-User Authorization Endpoint
User-Agent Endpoint
* Endpoint used to interact directly with the client
Token Endpoint
Client Endpoint
Back Channel
On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav e...@hueniverse.com wrote:
But in that case, all the other oauth_* parameters are missing. It's trivial.
An OAuth 1 filter will interpret this as broken OAuth 1 authentication.
Marius
EHL
-Original Message-
From: Marius Scurtescu
Which is fine if it doesn't support 2.0.
EHL
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Thursday, June 10, 2010 10:53 AM
To: Eran Hammer-Lahav
Cc: Paul Lindner; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Identifying OAuth 2.0 vs 1.0
If you're routing requests with a load balancer it's not so trivial.
Instead of a substring match you're talking about a regex with negative
lookahead matching -- that's why the presence of the signature param is
essential to distinguishing between 2.0/1.0a.
On Thu, Jun 10, 2010 at 10:42 AM, Eran
One of the things that I found particularly useful with working with
OAuth1 was the ability to perform an entire transaction through URL
parameter manipulation. This is why I wholly support keeping the client
id and secret fields in the client auth flow and the username and
password fields in the
Another alternative idea -- designate the 'format' param as an accept-header
override. This technique has been successful for the X-Method-Override
header and cements the Accept header syntax as the proper mechanism for
selecting output format.
On Thu, Jun 10, 2010 at 10:59 AM, Justin Richer
There is a bigger issue with even having multiple formats. If only we can
decide between form-encoded and JSON...
EHL
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Paul
Lindner
Sent: Thursday, June 10, 2010 11:19 AM
To: Justin Richer
Cc: OAuth WG
Subject: Re:
Did anyone ever write up the specifics of this? I've seen general support,
and would like to see it added.
-cmort
On 5/24/10 2:22 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
Anyone wants to turn this into an actual proposal with list of changes to the
current flow?
EHL
On 5/23/10
I strongly believe that it should be first presented as an I-D. This is true in
general for most proposed changes of this size. It is hard to tell how big of
an impact a change like this will have without some actual text. Once proposed,
the WG can decide if this is of interest as a WG item. If
+1 for MUST JSON response, MAY form-encoded (and xml, etc etc) response via
extension (response_format parameter?)
-- Justin Hart
-- jh...@photobucket.com
On Jun 10, 2010, at 2:29 PM, Eran Hammer-Lahav wrote:
After taking a break from our previous debate(s) on the issue of which
If you want to introduce the notion
of non-repudiation (meaning that the client
cannot deny issuing an access request to the resource
server), then you need to get the client
to exercise its secret (eg. by using it
in some crypto computation).
When a flow does not include the exercise/usage
of
+1
On 2010-06-10, at 1:29 PM, Eran Hammer-Lahav wrote:
After taking a break from our previous debate(s) on the issue of which
response format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment)
using JSON.
My
+1 with optional extension for XML encoded
-cmort
On 6/10/10 1:29 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
After taking a break from our previous debate(s) on the issue of which response
format to support, I would like to suggest the following:
- Support a single response format
+1
Propose we have other encodings as extensions, then.
-- justin
On Thu, 2010-06-10 at 16:29 -0400, Eran Hammer-Lahav wrote:
After taking a break from our previous debate(s) on the issue of which
response format to support, I would like to suggest the following:
- Support a single
+1
Am 10.06.2010 22:29, schrieb Eran Hammer-Lahav:
After taking a break from our previous debate(s) on the issue of which response
format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment) using
JSON.
My reason for
+1
=nat @ Tokyo via iPhone
On 2010/06/11, at 7:18, Brian Eaton bea...@google.com wrote:
+1.
On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
After taking a break from our previous debate(s) on the issue of
which response format to support, I would like to
After taking a break from our previous debate(s) on the issue of which response
format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment) using
JSON.
My reason for this is very simple, while right now we have a very
+1
On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
After taking a break from our previous debate(s) on the issue of which
response format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment)
+1
On Thu, Jun 10, 2010 at 1:29 PM, Eran Hammer-Lahav e...@hueniverse.com wrote:
After taking a break from our previous debate(s) on the issue of which
response format to support, I would like to suggest the following:
- Support a single response format (including in the user-agent fragment)
Andrew, Marius,
Comments in-line.
-Original Message-
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Marius Scurtescu
Sent: Thursday, June 10, 2010 1:35 PM
To: Andrew Arnott
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] User-agent flow and pre-registered
Am 10.06.2010 19:52, schrieb Eran Hammer-Lahav:
Pick or suggest new ideas:
* Endpoint used to interact with the end-user
End-user Endpoint
Front Channel Endpoint
Authorization Endpoint
End-User Authorization Endpoint
+1
User-Agent Endpoint
* Endpoint used to interact directly
+1
--
James Manger
--
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of Eran
Hammer-Lahav
Sent: Friday, 11 June 2010 6:29 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Proposal for single JSON response format
- Support a single response format (including
+1
On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
+1
--
James Manger
--
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf Of
Eran Hammer-Lahav
Sent: Friday, 11 June 2010 6:29 AM
To: OAuth WG (oauth@ietf.org)
Subject: [OAUTH-WG] Proposal for single
One more good thing:
5) We can move almost all the params into JSON.
=nat @ Tokyo via iPhone
On 2010/06/10, at 16:27, Nat Sakimura sakim...@gmail.com wrote:
On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz balf...@google.com
wrote:
On Wed, Jun 9, 2010 at 4:05 PM, John Panzer
I like this idea. Hadn't thought about the security benefits, thanks for
enumerating Nat.
On Jun 10, 2010, at 6:26 PM, Nat wrote:
One more good thing:
5) We can move almost all the params into JSON.
=nat @ Tokyo via iPhone
On 2010/06/10, at 16:27, Nat Sakimura
Hi Thomas,
Some responses inline...
On Thu, Jun 10, 2010 at 1:27 PM, Thomas Hardjono hardj...@mit.edu wrote:
The issue_date enables to scenarios: expiring tokens and token
revocation.
Here's how, for each scenario:
Obviously to know if a token has expired you need to know when it
http://github.com/daveman692/OAuth-2.0/raw/master/draft-recordon-oauth-v2-ux-01.txt
On Thu, Jun 10, 2010 at 5:32 PM, David Recordon record...@gmail.com wrote:
+1 for moving immediate here as well.
On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav e...@hueniverse.com
wrote:
Since these
+1
On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard lshep...@facebook.com wrote:
+1
On Jun 10, 2010, at 5:46 PM, Manger, James H wrote:
+1
--
James Manger
--
From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf
Of Eran Hammer-Lahav
Sent: Friday, 11
44 matches
Mail list logo
