Maybe I don't understand how you want to deal with errors, sorry if you have to repeat the same argument.
Here are a couple of examples. 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. 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 Marius On Thu, Mar 31, 2011 at 6:43 PM, Eran Hammer-Lahav <e...@hueniverse.com> wrote: > Hi Marius, > >> -----Original Message----- >> From: Marius Scurtescu [mailto:mscurte...@google.com] >> Sent: Thursday, March 31, 2011 6:07 PM > >> Many error codes (if not most) are not parameter specific. > > Like what? After a long debate, not a single use case was presented for a new > error code that is not: > > 1. overlapping with an existing HTTP code (4xx, 5xx) > 2. directly relates to an extension parameter > > Present new use cases and I'll reconsider. This proposal is 100% fit for the > given requirements. > >> Will this lead to the registration of fake parameter names just to be used >> as error prefixes? > > No. If there is an actual need to define a new error code that is not related > to at least one extension, I agree that we need a different solution (we can > always use the ability to update the RFC). But I have not seen any such need. > > In fact, I argue that such additional generic error codes are bad for > interoperability. If every client implements the same set of error codes > defined in v2, we know that they will all interop well when it comes to an > error condition. If the error is the result of an extension, the client must > understand that extension to understand any additional error code. Nothing > but extension parameter can change the behavior of this protocol. We don't > have other extension points that can produce such a change. No change - no > new error conditions. > > Another example of error code extensibility is the need to express more > specific error conditions related to extension grant types. It might be > necessary to express why a grant type was rejected, beyond just > 'invalid_grand'. However, *replacing* 'invalid_grant' with a more specific > error code would be bad for interoperability because it will break existing > libraries designed to be extensible but do not offer a fully extensible error > code handler (just not likely). The right solution would be to define an > additional, grant-type-specific response parameter that will provide > sub-meaning to the 'invalid_grant' code. > > In this case, no new error codes are even registered, just an extension > response parameter. > >> If we are going down this route, why don't we require extensions to register >> just a prefix? > > What route? Registering a prefix is a good idea if we expect a flood of > extension parameters. I'm not. > > <rant> > The bottom line is that this proposal is purposely not creating an open-ended > registry that will end up being as counter-productive as the OAuth 1.0 error > codes wiki page. It is design to put the least amount of process and hurdle > in the way of developer extending the protocol. > > I am happy to suggest alternatives or even adopt Mike Jones' proposal for an > error registry if only someone can present a *single* use case that defines a > new requirement not covered by this proposal. Give me just *one* example > where this is incomplete. But short of that, discussing the shortcoming of a > proposal without clear requirements is a total waste of time. > > Extensibility is where most protocol fuck up (pardon my language). It is > where crap enters the protocol, pollutes the flow, and breaks interop. We can > define experimental features - that's fine because if they fail they just > don't get adopted. But unchecked extensibility is how you end up with WS-*, > and SOAP, and a never ending list of crap that offers no shred of interop > because it was extended beyond recognition. > </rant> > > EHL > > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
