> -----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 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.
The goal is to make client developers life easier. I never heard making it easier for server developers is a goal. In fact, with all the new flows and refresh token, OAuth 2.0 adds a lot more complexity to sever developers. > 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. Creating a clear framework with a well-defined model wins over the ability to extend anything you feel like by defining a new parameter value. The original 'type' parameter talked about the kind of *flow* being used. It basically used the OpenID 'mode' architecture of a single endpoint overloaded with unrelated activities. It turns out that we actually created a clean model where you request a token using one of 4 authorization grant constructs. If you ignore the device request for verification code (which doesn't feet the "Token Endpoint" definition anyway), the model is completely consistent. Using this endpoint now to delete a token would break this. A much cleaner approach is to define a new endpoint, either a fixed one or as a return value with the token (as previously suggested by James). > 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. Refreshing a token is nothing more than asking for a new token using an authorization grant of type refresh token. It is exactly the same as using a verification code or end-user credentials. > Using HTTP DELETE is a bad idea since it > would require each token to have a URL associated with it You should still be able to put the access token in a parameter using a DELETE operation. I'm not aware of any limitation on using query parameters with a DELETE operation. Can you point me to where this restriction is defined? > and you can no longer manipulate the OAuth API with just query parameters. Well, we don't actually use query parameters, we use form-encoded body 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. As stated earlier, I'm ok with a parameter indicating the kind of authorization grant being used. But that will not solve your use case. Using the refresh token as authentication will not work for the many cases where no such token is issued. Sending just the access token is enough - if an access token alone is secure enough to access protected resources, it is clearly secure enough to revoke it. In general, I am still not clear on the token modification requirements (delete, re-scope). It would be useful to discuss how it would be used in practice (what kind of clients, for what purpose, etc.), and what existing experience we have to use as reference. For now, adding token revocation and re-scoping seems better suited to an extension than the core specification. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
