> -----Original Message----- > From: Marius Scurtescu [mailto:[email protected]] > Sent: Thursday, March 31, 2011 7:21 PM > To: Eran Hammer-Lahav > Cc: OAuth WG > Subject: Re: [OAUTH-WG] Error extensibility proposal > > Maybe I don't understand how you want to deal with errors, sorry if you > have to repeat the same argument.
This is helpful. > JavaScript clients need to be able to get new access tokens without user > interaction (after an initial consent). The solution is to define an immediate > mode through an extension. The client sends a parameter immediate=true > which tells the server that no UI should be shown. > Either an access token is returned immediately or a specific error code. This > error code must tell the client that it does need to popup a UI and try again. > In this case the error code could be immediate_failed, which conforms to > your prefix requirement, but I think only by luck. The prefix is just a useful suggestion. No need to produce convoluted grammar just to fit the parameter name it. But it usually works out given that the error operates with relation to the parameter. This examples seems to fit my proposal perfectly. > Another example is the device profile. The profile defines a new grant type, > the device is repeatedly checking the token endpoint to see if the user has > approved or not. Two special error codes are required for this to work: > authorization_pending and slow_down. No meaningful parameter prefix can > be used in this case. See: > http://tools.ietf.org/html/draft-recordon-oauth-v2-device-00#section-1.6 Ah, a new use case! So here we have new errors coming out of the use of an extension grant type. As currently drafted, the device grant type (which will need to be assigned a URI) does not introduce any new request or response parameter to the token endpoint, so my proposal does not satisfy this use case. This does provide a compelling use case for introducing an error registry, separate from the parameters registry. However, it is still directly linked to another extension point (grant type). I'll combine Mike Jones' proposal with mine and repost. Thanks for that! EHL _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
