You are a bit behind. -08 added it back as grant_type which works better with
the current explanation.
EHL
From: Dick Hardt [mailto:dick.ha...@gmail.com]
Sent: Tuesday, June 22, 2010 1:29 PM
To: Brian Eaton
Cc: Eran Hammer-Lahav; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07
Per an earlier comment, "type" might not be the best name for the parameter.
Perhaps "method" might work and adds a clear extension point for other types
of calls?
On Tue, Jun 22, 2010 at 1:22 PM, Dick Hardt wrote:
> One of the modifications I concluded to do to WRAP was to add in the type
> par
One of the modifications I concluded to do to WRAP was to add in the type
parameter. I was happy to see if in David's draft.
Even though redundant in some ways, it make it very clear to both the client
and server what is intended.
+1 for putting it back in.
On Mon, Jun 14, 2010 at 11:23 AM, Bria
t;
>> EHL
>>
>> -Original Message-
>> From: Marius Scurtescu [mailto:mscurte...@google.com]
>> Sent: Tuesday, June 15, 2010 4:19 PM
>> To: Eran Hammer-Lahav
>> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
>> Subject: Re: [OAUTH-WG] Draft -07
-Original Message-
From: Marius Scurtescu [mailto:mscurte...@google.com]
Sent: Tuesday, June 15, 2010 5:24 PM
To: Eran Hammer-Lahav
Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
On Tue, Jun 15, 2010 at 5:05 PM, Eran Hammer-Lahav wrote:
> It gi
15, 2010 4:19 PM
> To: Eran Hammer-Lahav
> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>
> On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav
> wrote:
>> Adding a verification code to the user-agent flow was suggested o
oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
> Adding a verification code to the user-agent flow was suggested on
> this list and received nothing but support. It was suggested as a
> solution to a Twitter use cas
On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
> Adding a verification code to the user-agent flow was suggested on this list
> and received nothing but support. It was suggested as a solution to a
> Twitter use case.
I think it would be good to see a detailed use case where this is
re
> -Original Message-
> From: Brian Eaton [mailto:bea...@google.com]
> Sent: Monday, June 14, 2010 11:23 AM
> To: Eran Hammer-Lahav
> Cc: Andrew Arnott; OAuth WG (oauth@ietf.org)
> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>
> On Mon, Jun 14, 2010 at 9:
On Mon, Jun 14, 2010 at 8:23 AM, Andrew Arnott wrote:
> And apparently now the user-agent flow can receive a
> verification code as well as an access token? It's unclear what that's for
> or how that's used.
Here's the thread where Brian Ellin proposed the verification code on
the user-agent flo
On Mon, Jun 14, 2010 at 9:18 AM, Eran Hammer-Lahav wrote:
> Adding a verification code to the user-agent flow was suggested on this list
> and received nothing but support. It was suggested as a solution to a
> Twitter use case. Once that is added in, the two flows only differ in how
> the respons
> -Original Message-
> From: Justin Richer [mailto:jric...@mitre.org]
> Sent: Monday, June 14, 2010 7:20 AM
> To: Eran Hammer-Lahav
> Cc: Marius Scurtescu; OAuth WG
> Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
>
> I disagree. I don't think i
.com]
> Sent: Monday, June 14, 2010 7:54 AM
> To: Eran Hammer-Lahav
> Cc: OAuth WG
> Subject: RE: [OAUTH-WG] Draft -07 (major rewrite)
>
> +1 for the type parameter.
>
> Our internal server and client developers would both prefer it.
>
> -cmort
> ___
ndrew Arnott [mailto:andrewarn...@gmail.com]
Sent: Monday, June 14, 2010 8:24 AM
To: Eran Hammer-Lahav
Cc: OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
I find the combination of the web server and user agent flows for end user
authorization unnatural -- particu
I find the combination of the web server and user agent flows for end user
authorization unnatural -- particularly poignant in the success response,
which has 4 parameters -- but one flow MUST have no more than 2, and the
other must have 3. And apparently now the user-agent flow can receive a
veri
Hammer-Lahav
Cc: OAuth WG
Subject: Re: [OAUTH-WG] Draft -07 (major rewrite)
I disagree. I don't think it's redundant, I think it's a clarifying
piece of information that makes it completely unambiguous what the
client is expecting to happen. On the server side, a single switch is a
m
I disagree. I don't think it's redundant, I think it's a clarifying
piece of information that makes it completely unambiguous what the
client is expecting to happen. On the server side, a single switch is a
much simpler and less error-prone dispatch structure than a set of "if
this-and-that paramet
s how well this
abstraction works.
A type parameter is nothing but a duplication of the information sent.
EHL
From: Andrew Arnott [mailto:andrewarn...@gmail.com]
Sent: Sunday, June 13, 2010 9:58 AM
To: Eran Hammer-Lahav
Cc: Justin Richer; Marius Scurtescu; OAuth WG
Subject: Re: [OAUTH-WG] Draft
Eran,
While the flows in the spec today may have unique sets of required
parameters, other flows may exist with overlapping initial parameters (why?
perhaps the flows have different rules that don't come into effect until
later in the flow). Keeping the type parameter in there would help
differen
some comments on the new draft from my side.
In my opinion, the raised abstraction level makes the spec harder to
read but more elegant :-) Rearranging conceptual statements and
endpoint/request descriptions would probably further improve
readability. For example, the end-user authorization en
The comment was about the token endpoint which used to include a 'type'
parameter (indicating the flow being used). All the flows share the same token
endpoint.
EHL
On 6/11/10 2:24 PM, "Christian Scholz" wrote:
Hi!
Am 11.06.10 22:47, schrieb Marius Scurtescu:
> On Fri, Jun 11, 2010 at 1:11
On 6/11/10 1:47 PM, "Marius Scurtescu" wrote:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav
> wrote:
>> Draft -07 represents a major rearrangement of the document. I still have a
>> lot of work to do but wanted to share my progress and get some general
>> feedback. The draft includes a
It doesn't really. It is completely clear what kind of authorization grant the
client is providing simply by looking at the parameter. It might make the code
a few lines longer (a few if-else instead of a switch-case) but because these
are all post parameters, you access them the same way (i.e.
Hi!
Am 11.06.10 22:47, schrieb Marius Scurtescu:
> On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav
> wrote:
>> Draft -07 represents a major rearrangement of the document. I still have a
>> lot of work to do but wanted to share my progress and get some general
>> feedback. The draft includes
I agree with Marius: I think we should keep the explicit flow name in
there (in the 'type' parameter or equivalent), as it (among other
things) opens the possibility for the rescope and revoke operations. It
makes it very clear how both client and server expect things to behave.
-- Justin
On Fri
On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav wrote:
> Draft -07 represents a major rearrangement of the document. I still have a
> lot of work to do but wanted to share my progress and get some general
> feedback. The draft includes a few normative language changes but the main
> focus is
Draft -07 represents a major rearrangement of the document. I still have a lot
of work to do but wanted to share my progress and get some general feedback.
The draft includes a few normative language changes but the main focus is on
the document structure and how the architecture is explained.
27 matches
Mail list logo
