Errors that have nothing to do with the core spec. There is not overlap in functionality between the two documents and their use cases.
EH > -----Original Message----- > From: Mike Jones [mailto:michael.jo...@microsoft.com] > Sent: Monday, May 07, 2012 4:12 PM > To: Eran Hammer; Hannes Tschofenig; oauth@ietf.org WG > Subject: RE: [OAUTH-WG] Error Registry Consensus Call > > The bearer spec is not intended as a general purpose HTTP Auth scheme. > Note that it includes a "scope" response, which firmly anchors it to use with > OAuth, where it provides flows E-F which follow flows A-D that are specified > in the framework spec - thus completing the end-to-end OAuth protocol > usage flows. > > These are OAuth-specific errors. > > -----Original Message----- > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > Of Eran Hammer > Sent: Monday, May 07, 2012 4:07 PM > To: Hannes Tschofenig; oauth@ietf.org WG > Subject: Re: [OAUTH-WG] Error Registry Consensus Call > > A. > > For the following reasons (all extensively discussed on this list before): > > 1. The OAuth core specification has nothing to do with HTTP authentication > schemes. > 2. The bearer specification is a general purpose HTTP Auth scheme and > defining such a registry needs to be defined within those boundaries - that > is, > either specific to Bearer to generic to all HTTP Auth scheme opting into the > error parameter. > 3. There wasn't strong consensus that the error parameter was even > necessary or useful to begin with. Limiting it to bearer reflects the wider > IETF > consensus on the matter (based on feedback received at the time from the > HTTPbis WG). > 4. It would be odd for someone using the bearer scheme outside of OAuth to > use the OAuth error registry (and take over values that will be helpful for > the > core specification). > 5. There is no overlap in functionality or values between the protected > resource endpoint (which is part of the proprietary API namespace) and the > OAuth endpoint for which the registry was created. To piggyback the OAuth > registry just because it is slightly easier would be wrong. There is no > interop > value accomplished. > > This is not simply a question of where to stick the registry. Adding this to > the > OAuth registry would be a fundamental change in architecture and > philosophy and a significant change at this point. Adding it to the bearer > specification is the only viable option. > > I would request that such a change go through another IETF LC if this was the > WG consensus but hope we can avoid it. > > EH > > > > > -----Original Message----- > > From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On Behalf > > Of Hannes Tschofenig > > Sent: Monday, May 07, 2012 3:48 PM > > To: oauth@ietf.org WG > > Subject: [OAUTH-WG] Error Registry Consensus Call > > > > Hi all, > > > > there is an open issue concerning draft-ietf-oauth-v2-bearer-19 that > > may impact draft-ietf-oauth-v2-26 (depending on it's resolution) and > > we would like to get feedback from the working group about it. > > > > Here is the issue: When a client makes an access to a protected > > resources then things may go wrong and an error may be returned in > > response. draft- ietf-oauth-v2-bearer talks about this behavior. > > > > That's great but these error codes need to be registered somewhere. > > Note that the registry can be created in one document while the values > > can be registered by many documents. > > > > So, where should the registry be? > > > > There are two choices. > > > > a) A new OAuth errors registry goes into draft-ietf-oauth-v2-bearer. > > > > b) draft-ietf-oauth-v2 expands the scope of the existing OAuth Errors > > registry to encompass errors returned from resource servers. > > > > Currently, draft-ietf-oauth-v2 creates registries for error codes only > > for the exchanges from A-to-D (symbols used from Figure 1 of > > draft-ietf-oauth-v2), but excludes registration of errors from flows E-F. > > > > We must create a registry for error codes from flows E-F. In which > > document do we want to create this registry? > > > > So, give us your feedback whether you have a preference by the end of > > the week. > > > > Ciao > > Hannes & Derek > > > > _______________________________________________ > > OAuth mailing list > > OAuth@ietf.org > > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
