To be clear, you are +1 on using only JSON for server responses on the token
endpoint?
EHL
From: Evan Gilbert [mailto:uid...@google.com]
Sent: Sunday, June 13, 2010 11:20 AM
To: Eran Hammer-Lahav
Cc: Robert Sayre; OAuth WG (oauth@ietf.org)
Subject: Re: [OAUTH-WG] Proposal for single JSON respons
I would argue that if a new flow doesn't fit into the existing framework, it
should define a new endpoint. For example, the device flow doesn't fit with the
2 endpoints model since the first call is really an half-authorization with a
custom URI returned. The second flow uses a verification code
On 2010-06-13, at 11:20 AM, Evan Gilbert wrote:
>
>
> On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav
> wrote:
> Using JSON in the end-user authorization endpoint response is still something
> we need to discuss. In the web server flow, it makes more sense to use
> form-encoded because t
On Sun, Jun 13, 2010 at 8:18 AM, Eran Hammer-Lahav wrote:
> Using JSON in the end-user authorization endpoint response is still
> something we need to discuss. In the web server flow, it makes more sense to
> use form-encoded because the URI is processed by a typical query processor
> (automatic i
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
'username' moves OAuth into the identity realm, which is something the OpenID
Connect proposal is going to address. I don't care if the immediate mode moves
into the OpenID Connect proposal, but I am against moving username into the UX
draft. As for yet another draft, I am not sure what its scop
Using JSON in the end-user authorization endpoint response is still something
we need to discuss. In the web server flow, it makes more sense to use
form-encoded because the URI is processed by a typical query processor
(automatic in every web server). In the fragment, it is a question of
prefe
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 "immediate" parameter is can have unintended consequences without some
way to attach it to an existing user. Examples here:
http://trac.tools.ietf.org/wg/oauth/trac/wiki/OAuth2UsernameParameter.
I'd prefer to link these two parameters (username and immediate) in one spec
- @David, this can be
-1
I disagree very strongly with this approach if I'm understanding
correctly. Let me paraphrase to make sure I understand:
All responses, even those encoded in a browser URL redirect back from the AS
(redirect with verification code in the web server flow and the redirect
with token in the user-
10 matches
Mail list logo
