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-bounces@ietf.org [mailto:oauth-bounces@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-bounces@ietf.org [mailto:oauth-bounces@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