Re: [OAUTH-WG] Draft -07 (major rewrite)

[Chuck Mortimore <[e-mail]>]

+1 for the type parameter.   

Our internal server and client developers would both prefer it.   

-cmort
________________________________________
From: [e-mail] [[e-mail]] On Behalf Of Justin Richer [[e-mail]]
Sent: Monday, June 14, 2010 7:20 AM
To: Eran 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
much simpler and less error-prone dispatch structure than a set of "if
this-and-that parameter else if this-other parameter else if
that-other-and-something-else parameter" statements. If one of our goals
of OAuth2 is easing the implementation for developers, dropping the
"type" field is a big lose.

Also, as has already been pointed out, if a new flow comes in that wants
to use existing parameters in a different way, then it won't fit into
this framework or an extension. Decreasing ambiguity for a small price
(a few extra required characters for the auth flow) is a good thing.

Incidentally, I agree that the refresh flow should fit in with all of
the other flows, but with "type=refresh". Maybe "type" is the wrong word
for this parameter? Because I was envisioning the rescope and revoke
operations to be similar to the refresh operation. Using HTTP DELETE is
a bad idea since it would require each token to have a URL associated
with it, and you can no longer manipulate the OAuth API with just query
parameters. A "type=revoke" call with the refresh token as
authentication and the token-to-be-revoked as parameter makes a whole
lot more sense to me.  It keeps these three operations parallel to the
other authorization flows -- part of the whole "how to get a token" side
of OAuth.

 -- Justin

On Fri, 2010-06-11 at 17:25 -0400, Eran Hammer-Lahav wrote:
> 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. this is not a case where header information is
> moved to post body, etc.).
>
> As for the rescope and revoke operations, we still need to figure out
> how to accomplish that. For example, revoking can be done using an
> HTTP DELETE operation which is more consistent with HTTP, and
> rescoping (which is still tricky because scope can only be decreased)
> is more a function of a refresh operation (asking for a new access
> token using a refresh token and simply providing a new, lesser scope).
>
> EHL
>
>
> On 6/11/10 2:05 PM, "Justin Richer" <[e-mail]> wrote:
>
>         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, 2010-06-11 at 16:47 -0400, Marius Scurtescu wrote:
>         > On Fri, Jun 11, 2010 at 1:11 PM, Eran Hammer-Lahav
>         <[e-mail]> 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 on the
>         document structure and how the architecture is explained.
>         > >
>         > > Changes include:
>         > >
>         > >   o  Removed device profile.
>         > >   o  Added verification code support to user-agent flow.
>         > >   o  Removed multiple formats support, leaving JSON as the
>         only format.
>         > >   o  Changed assertion "assertion_format" parameter to
>         "assertion_type".
>         > >   o  Removed "type" parameter from token endpoint.
>         >
>         > It would be really useful if each request had a unique type,
>         now we
>         > are back to guessing what is requested, like in WRAP.
>         >
>         > One small error that I noticed: section "5.1.4.  Refresh
>         Token" is not
>         > listing client_id and client_secret as optional parameters.
>         >
>         > In general I found previous versions much easier to read and
>         > understand, but maybe I just need more time...
>         >
>         >
>         > Marius
>         > _______________________________________________
>         > OAuth mailing list
>         > [e-mail]
>         > https://www.ietf.org/mailman/listinfo/oauth
>
>
>


_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth