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

[Eran Hammer-Lahav <[e-mail]>]

Why client developers? How does it make their life easier?

An approach I'm more comfortable with is to redefine 'type' as the type of authorization grant provided: refresh_token, user_basic, verification_code, assertion. And if we use the name 'type', I would change the 'type' parameter on the end-user authorization endpoint to something else such as the proposed 'response_type'. Otherwise change it to 'grant_type' or something like that.

EHL

> -----Original Message-----
> From: Chuck Mortimore [mailto:[e-mail]]
> 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
> ________________________________________
> 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