+1
On Thu, Jun 10, 2010 at 5:50 PM, Luke Shepard 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 June
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 wrote:
> +1 for moving immediate here as well.
>
>
> On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav
> wrote:
>> Since these are all extensions to the end-user
Hi Thomas,
Some responses inline...
On Thu, Jun 10, 2010 at 1:27 PM, Thomas Hardjono 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 was
>
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
mailto:sakim...@gmail.com>> wro
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 wrote:
On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz
wrote:
On Wed, Jun 9, 2010 at 4:05 PM, John Panzer
wrote:
So the thinking is that this is just a
+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 f
+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 i
+1 for moving immediate here as well.
On Thu, Jun 10, 2010 at 4:18 PM, Eran Hammer-Lahav wrote:
> Since these are all extensions to the end-user endpoint, I'd suggest we move
> the 'immediate' parameter here as well.
>
>
>
> OPTIONAL. The parameter v
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 with
+1.
On Thu, Jun 10, 2010 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.
It seems that token encryption spec has been removed between OAuth 2.0
draft 05 and draft 06
The related diff : http://tools.ietf.org/rfcdiff?url2=draft-ietf-oauth-v2-06.txt
Is it intended ?
Can we expect to have these encrypted token stuff back in security
paragraph (currently in TODO status) for
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-registe
+1
On Thu, Jun 10, 2010 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.
+1
On Thu, Jun 10, 2010 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.
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 limit
+1
=nat @ Tokyo via iPhone
On 2010/06/11, at 7:18, Brian Eaton wrote:
+1.
On Thu, Jun 10, 2010 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 si
+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 thi
+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 re
We've talked about issuing different client secrets for use with
different flows. We haven't actually implemented it yet and prefer
using something like TPM on devices which support it. A different
secret is at least better than nothing for apps which can't reliably
keep secrets and don't have some
Since these are all extensions to the end-user endpoint, I'd suggest we move
the 'immediate' parameter here as well.
OPTIONAL. The parameter value must be set to true or
false. If set to
true, the authorization server
Some of the flows require/allow a client secret while others disallow it (when
the client has no secure means to keep it secret). My question is, do you plan
to issue different credentials for different flows (with or without secret) or
allow the same set to be used, sometimes with and sometimes
+1 with optional extension for XML encoded
-cmort
On 6/10/10 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
+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.
>
>
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 the
+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
> r
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
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" wrote:
Anyone wants to turn this into an actual proposal with list of changes to the
current flow?
EHL
On 5/23/10 7:13 PM, "Luke Shep
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: [OAUTH-
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 wro
On Thu, Jun 10, 2010 at 10:52 AM, Eran Hammer-Lahav wrote:
> Pick or suggest new ideas:
>
> * Endpoint used to interact with the end-user
>
> End-user Endpoint
-1
> Front Channel Endpoint
> Authorization Endpoint
+1
> End-User Authorization Endpoint
> User-Agent Endpoint
not bad, but it con
My vote:
> * Endpoint used to interact with the end-user
> Authorization Endpoint
or
> End-User Authorization Endpoint
> * Endpoint used to interact directly with the client
> Token Endpoint
-- Justin
___
OAuth mailing list
OAuth@ietf.org
https:
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 u
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
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 r
On Thu, Jun 10, 2010 at 10:42 AM, Eran Hammer-Lahav 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 [mailto:msc
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 Endpoint
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
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: [OAU
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 wrote:
> I am talking about the resource server. Specifically I want to be able to
> quickly dete
On Thu, Jun 10, 2010 at 8:35 AM, Andrew Arnott wrote:
> Thanks Marius.
>
> I've answered your question below.
>
> On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu
> wrote:
>>
>> > I've always considered an authorization as a tuple of
>> > client_id,user,scope,issue_date. If an authorization has
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 t
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 ea
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
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
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 para
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
wrote:
> no one in the WG ha
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 issu
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: [OAUTH-
Thanks Marius.
I've answered your question below.
On Wed, Jun 9, 2010 at 9:35 AM, Marius Scurtescu wrote:
> > 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 authorization for a subse
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
by
On Thu, Jun 10, 2010 at 8:27 AM, Dirk Balfanz wrote:
>
>
> On Wed, Jun 9, 2010 at 4:05 PM, John Panzer 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 als
51 matches
Mail list logo
