Subject: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

From: Mike Jones <[email-masked]>
Date: Mon, 21 Mar 2011 16:48:07 +0000

People voted as follows in the poll I conducted on the OAuth Errors Registry:

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

Given that twice as many people indicated a preference for A as for any other option, that seems to indicate a consensus for A.  Therefore Eran, when you update your draft, can you please proceed on that basis?

                                                                Thanks,
                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Mar 2011 10:21:29 -0700

You call this consensus? David Recordon was raising concerns about the proposal and Justin Richter agreed to registry alternatives. So no, this is not sufficient to make changes yet.

I do see a need to extend the error code set in case of extensions which modify the behavior of the authorization and token endpoints. Such additional error codes are completely dependent on the definition of additional parameters which we do register. I have received some negative feedback about using URIs for extension error codes (due to their inconsistency with the existing codes).

I will post a modified proposal for error extensibility based on the requirement I presented earlier (as I have not seen any other valid requirements or use cases) before the next draft for discussion.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, March 21, 2011 9:48 AM
To: [email-masked]
Subject: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Mar 2011 11:45:19 -0700

I don't believe there is consensus yet. Many of us have not voted and/or don't agree with the options presented.

Phil
[email-masked]

On 2011-03-21, at 9:48 AM, Mike Jones wrote:

> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: "Manger, James H" <[email-masked]>
Date: Tue, 22 Mar 2011 10:38:15 +1100

The bearer spec defines 3 errors (invalid_request, invalid_token, insufficient_scope), which accompany 3 different status codes (400 Bad request, 401 Unauthorized, 403 Forbidden respectively).

Client apps are probably better off switching behaviour based on the HTTP status code, and ignoring the error string (perhaps put it in a log, or on a debug console so a developer can see it).

It seems like overkill to have:

*         An HTTP status code (eg 401)

*         An HTTP status message (eg Unauthorized)

*         An error string (eg invalid_token)

*         An error_description (eg token is formatted incorrectly)

*         An error_uri (eg http://api.example.com/error/45)

*         The body of the HTTP response (eg an HTML page with extensive details about the error and links to the API documentation)

6 sources of error information -- and all for a bearer token that is usually opaque to the client app!

Encouraging new error strings to be defined - by having a registry for them - is not ideal. Client apps that don't recognize a value learn nothing. At least with HTTP status codes a client app knows the class of error (eg 4xx or 5xx) and can behave accordingly even if it doesn't recognize the specific value (eg 538).

I'd vote for F) ditch error string/description/uri for the BEARER HTTP authentication scheme.

--

James Manger

For A:

                Mike Jones

                Igor Faynberg

                Justin Richter

                Anthony Nadalin

For D or C:

                Eran Hammer-Lahav

                William Mills

                                                                Thanks,

                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Mar 2011 17:54:06 -0700

That's what I did for MAC. However, this thread is about the v2 spec.

EHL

On Mar 21, 2011, at 16:38, "Manger, James H" <[email-masked]<mailto:[email-masked]>> wrote:

·         An HTTP status code (eg 401)

·         An HTTP status message (eg Unauthorized)

·         An error string (eg invalid_token)

·         An error_description (eg token is formatted incorrectly)

·         An error_uri (eg <http://api.example.com/error/45> http://api.example.com/error/45)

·         The body of the HTTP response (eg an HTML page with extensive details about the error and links to the API documentation)

Encouraging new error strings to be defined – by having a registry for them – is not ideal. Client apps that don’t recognize a value learn nothing. At least with HTTP status codes a client app knows the class of error (eg 4xx or 5xx) and can behave accordingly even if it doesn’t recognize the specific value (eg 538).

I’d vote for F) ditch error string/description/uri for the BEARER HTTP authentication scheme.

--
James Manger

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Phil Hunt <[email-masked]>
Date: Mon, 21 Mar 2011 20:17:15 -0700

I'm still not understanding why each RFC (e.g. the bearer spec) can't define its own error codes. If you were to support the bearer token RFC, then you obviously understand the normative errors. I'm just not getting what the value of a central "OAuth" registry is.  

An OAuth registry also unnecessarily limits possibility of re-use of token schemes in other frameworks outside of OAuth or conversely limits the ability to use tokens (such as kerberos) in an OAuth "framework".

So again, I ask what the benefit of a registry is achieved that could not be achieved within the token spec itself.

Phil
[email-masked]

On 2011-03-21, at 4:38 PM, Manger, James H wrote:

> ·         An error_uri (eg http://api.example.com/error/45)

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Mon, 21 Mar 2011 21:32:58 -0700

There are two separate issues here which Mike's latest draft conflated into one.

Issues 1:

The v2 specification currently does not allow for defining additional error codes to the authorization and token endpoints. The only way to define additional error codes is by updating the RFC (once published). Updating an RFC is an acceptable way of extending an existing specification, but only if it is done very infrequently. The other two options are to allow URI-formatted error code, or define a registry.

In any case, all three extensibility model have a single purpose - to reduce the likelihood of an error code name collision. It does not improve interoperability unless clients actually implement the additional codes. The goal of the v2 specification must be to cover all possible scenarios so that a client implementing nothing but these codes will be able to handle error cases related to this specification.

After a long discussion, the only valid use case to arise is the one in which an extension such as the UX specification (providing a way for the client to specify the display size of the authorization web page for various devices) needs additional codes. For example, the UX specification defines the 'display' authorization request parameter. If the client provides bad value, the server may want to return an error specific to this situation.

The open issue is how to address this use case. Since such additional error codes are always a result of an additional request parameter, I am looking for a way to allow parameter registration to specify such related error codes without defining yet another registry. This solution is specific to the only use case we have. Defining an error registry is likely to do more harm than good, encouraging developers to define new generic error codes that are not extension-specific which will only reduce interoperability.

Issue 2:

The bearer token specification includes registration requirements for protected resource request parameters as well as potential error codes when a protected resource request fails. A few people have strongly objected to this new proposal since the semantics of the protected resource request is by definition, outside the scope of any OAuth specification.

The only parameter allowed to infringe on the resource server namespace is the currently named 'oauth_token' parameter. There is an ongoing discussion to renamed it to 'bearer_token'.

Hope this helps.

EHL

From: [email-masked] [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, March 21, 2011 8:17 PM
To: Manger, James H
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

Phil
[email-masked]<mailto:[email-masked]>

--
James Manger

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

---

From: Phil Hunt <[email-masked]>
Date: Tue, 22 Mar 2011 09:45:08 -0700

Eran,

Thanks. Thats the best summary of the problem and I think it will help move the discussion forward (finally).

Issue 1:

Since only one token format could be in play at any time, there doesn't seem to be a chance for conflict unless a bearer token collides with either OAuth or HTTP itself.

Let's say, worst case, two RFC's defined the same error code (lets say MAC and BEARER) with a different normative meaning. Would there really be a conflict? It doesn't seem so. The token type would dictate the RFC which would describe the definition in that case.

So the value of a registry strictly becomes a more documentary function - to ensure a nice neat namespace for status codes.  The downside? It ties token specs strictly to OAuth. This is the part I object to.

Issue 2:
I think if fully de-coupled, then the BEARER spec would be free to add whatever detail they like - as long as there is agreement within the BEARER spec community.

Finally, while I agree, detailed error messages helps in user interface design (and have been a big proponent in the past), it seems that in most "Internet" cases, services decline to give detailed errors (e.g. take OpenID or SAML as examples). They tend to just report generic errors. So is there much practical value here if nobody is likely to use them?  

Phil
[email-masked]

On 2011-03-21, at 9:32 PM, Eran Hammer-Lahav wrote:

> There are two separate issues here which Mike’s latest draft conflated into one.
>  
> Issues 1:
>  
> In any case, all three extensibility model have a single purpose – to reduce the likelihood of an error code name collision. It does not improve interoperability unless clients actually implement the additional codes. The goal of the v2 specification must be to cover all possible scenarios so that a client implementing nothing but these codes will be able to handle error cases related to this specification.
>  
> After a long discussion, the only valid use case to arise is the one in which an extension such as the UX specification (providing a way for the client to specify the display size of the authorization web page for various devices) needs additional codes. For example, the UX specification defines the ‘display’ authorization request parameter. If the client provides bad value, the server may want to return an error specific to this situation.
>  
> The only parameter allowed to infringe on the resource server namespace is the currently named ‘oauth_token’ parameter. There is an ongoing discussion to renamed it to ‘bearer_token’.
>  
> Hope this helps.
>  
> EHL
>  
>

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Mar 2011 09:48:12 -0700

Issue 1 has nothing to do with bearer, MAC, or accessing a protected resource. It is strictly about the v2 authorization and token endpoints. Each of those has a closed set of error codes which is currently not officially extensible.

EHL

From: Phil Hunt [mailto:[email-masked]]
Sent: Tuesday, March 22, 2011 9:45 AM
To: Eran Hammer-Lahav
Cc: Manger, James H; [email-masked]
Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

Eran,

Issue 1:

Issue 2:

Phil

Issues 1:

Issue 2:

Hope this helps.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]] On Behalf Of Phil Hunt
Sent: Monday, March 21, 2011 8:17 PM
To: Manger, James H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

Phil

--
James Manger

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Tue, 22 Mar 2011 21:31:34 +0000

There seems to be some basic disagreements;

(1)    The various token specifications standalone (e.g. draft-ietf-oauth-v2-bearer-03, etc.) and are not extensions to draft-ietf-oauth-v2-xx and have no need to have common error messages/codes

(2)    Errors in draft-ietf-oauth-v2-xx are final and we don't see a need to have a mechanism to add additional ones because of #(1)

(3)    We want to put a burden on the clients to have to deal with all the various error messages/codes from the different token profiles and the client has to figure this out

Given the above I'm not sure why we have a registry for the parameters, seems incionsistent.

From: [email-masked] [mailto:[email-masked]] On Behalf Of Eran Hammer-Lahav
Sent: Monday, March 21, 2011 9:33 PM
To: Phil Hunt; Manger, James H
Cc: [email-masked]
Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

Issues 1:

Issue 2:

Hope this helps.

EHL

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Phil Hunt
Sent: Monday, March 21, 2011 8:17 PM
To: Manger, James H
Cc: [email-masked]<mailto:[email-masked]>
Subject: Re: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

Phil

--
James Manger

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Tue, 22 Mar 2011 21:52:20 -0700

These are separate issues and collapsing them into one list is counterproductive (not to mention ignoring many useful points made along the way). What made this entire topic a mess is the original error registry proposal included in the bearer token specification which conflated completely different things into one useless registry.

Regarding the v2 specification:

- Should the error codes defined in sections 4.2.2.1 and 5.2 be extensible?

There is agreement that some extensibility is needed. The open question is whether such extensibility should be combined with the existing parameter extension registry or not. The reason for combining it with the existing registry is that so far, the only valid use case raised on the list was for defining extension-specific errors such as 'unknown display type' for the UX extension.

Regarding the bearer token and MAC token specifications:

- Should these specification define error codes beyond the HTTP status code returned (400, 401, 403)?

James Manger and I argue that given that there are three error conditions and three corresponding codes, there is no point in defining additional error codes. The HTTP status provides the client with all the information it needs. Others argue that they need finer error codes for cases such as token expiration (which is covered by 401).

- Should the error codes defined for the bearer token specification be extensible?

Since the MAC specification does not define additional error code and does not allow for any extensibility which can alter the protocol behavior (and generate additional error states), no error extensibility is needed. Bearer token specification defines an error registry but does not offer any use cases or requirements for such theoretical scenario.

- Should the bearer token and MAC token specification share an error registry, error response, header format, etc.?

The two specification are dramatically different and each has its own set of utilization methods, terminology, and errors. In addition, the MAC specification extends OAuth but is not an OAuth extension. OAuth extensions are specifications directly affecting the process of obtaining tokens, not using tokens.

EHL

From: Anthony Nadalin [mailto:[email-masked]]
Sent: Tuesday, March 22, 2011 2:32 PM
To: Eran Hammer-Lahav; Phil Hunt; Manger, James H
Cc: [email-masked]
Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

Issues 1:

Issue 2:

Hope this helps.

EHL

Phil

--
James Manger

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

---

From: Anthony Nadalin <[email-masked]>
Date: Wed, 23 Mar 2011 22:10:58 +0000

Not ignoring points made along the way as there are points from each view point, and not sure it's counterproductive to state the issues and what is driving the issues on a single list. So let's move on.

I don't believe that there is anything wrong in combining into a single registry, as this has been done in other specifications. I don't believe that HTTP status codes can convey all the information that may be needed by the client, you may be able to shoehorn all into the three but that is a disservice to the poor client who may have to figure these codes out.

What I'm hearing is that some folks feel that we will ever have any OAuth Extensions and anything that extends OAuth can do whatever it likes and we don't want to have any conventions dictated by the base.

From: Eran Hammer-Lahav [mailto:[email-masked]]
Sent: Tuesday, March 22, 2011 9:52 PM
To: Anthony Nadalin; Phil Hunt; Manger, James H
Cc: [email-masked]
Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

EHL

From: Anthony Nadalin [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Eran Hammer-Lahav

Issues 1:

Issue 2:

Hope this helps.

EHL

Phil

--
James Manger

For A:
                Mike Jones
                Igor Faynberg
                Justin Richter
                Anthony Nadalin

For D or C:
                Eran Hammer-Lahav
                William Mills

                                                                Thanks,
                                                                -- Mike

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Wed, 23 Mar 2011 15:30:11 -0700

> -----Original Message-----
> Sent: Wednesday, March 23, 2011 3:11 PM

> I don't believe that there is anything wrong in combining into a single
> registry, as this has been done in other specifications.

There are very different endpoints with different extensibility models. Trying to put protected resource endpoints in the same bucket as OAuth endpoint is a violation of the protocol design.

> I don't believe that
> HTTP status codes can convey all the information that may be needed by the
> client, you may be able to shoehorn all into the three but that is a disservice
> to the poor client who may have to figure these codes out.

Do you have actual use cases to support this?
 
> What I'm hearing is that some folks feel that we will ever have any OAuth
> Extensions and anything that extends OAuth can do whatever it likes and we
> don't want to have any conventions dictated by the base.

Hearing where? We already have OAuth extensions (not token types and schemes but actual extensions to the OAuth endpoints).

The problem with the current registry proposal is that it is not backed by any requirements or use cases. After repeated requests, Mike Jones posted some examples which I replied to and demonstrated how they are invalid. I didn't see any counter arguments.

Like most other disagreements we had, you offer vague and non-technical arguments, ignore my extensive attempts at having a technical discussion, provide no concrete use cases or requirements, and try to get your point by making sweeping declarations about it being 'unusable'.

Based on the requirements I presented to the group with regard to error code extensibility (using the UX extension example), I will draft a proposal and seek feedback.

EHL

---

From: Anthony Nadalin <[email-masked]>
Date: Thu, 24 Mar 2011 21:14:31 +0000

Amusing like your past rants but they don't help or offer solutions. We proposed a solution in the bearer token specification, I have not seen you offer alternative to this proposal, so you're not being constructive here and trying to reach consensus. You don't agree with our use cases and requirements that we present, I can't help that.

>. Trying to put protected resource endpoints in the same bucket as OAuth endpoint is a violation of the protocol design.
Not a violation of protocol design, maybe in your mind it is.

> Do you have actual use cases to support this?
Yes, as pointed out there are many cases that the client needs or can have further information, and the HTTP Status codes don't cut it, like in the bearer token specification with "insufficient_scope", there is also the case authorization server is busy and the HTTP 503 Service Unavailable does not cut it but you want to let the requestor know to retry, as I indicated you can shoehorn all errors into just "invalid". 

> The problem with the current registry proposal is that it is not backed by any requirements or use cases. After repeated requests, Mike Jones posted some examples which I replied to and demonstrate…
The registry proposal is backed by several requirements and use cases, (1) I don't believe that the errors defined in oauth-v2 are future proof; registry provides a means to protect us here (2) There are no real processing requirements in the oauth-v2 document thus the authorization server may need to provide additional errors that correspond with their processing rules.

> Like most other disagreements we had, you offer vague and non-technical arguments
We actually have to make this stuff work, and why we had to go off and do WRAP as OAuth 1.0a was not meeting ours and others business needs, so technology or technical discussions are only part of the equation of our requirements.

-----Original Message-----
From: Eran Hammer-Lahav [mailto:[email-masked]] 
Sent: Wednesday, March 23, 2011 3:30 PM
To: Anthony Nadalin; Phil Hunt; Manger, James H
Cc: [email-masked]
Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry

> I don't believe that there is anything wrong in combining into a 
> single registry, as this has been done in other specifications.

> I don't believe that
> HTTP status codes can convey all the information that may be needed by 
> the client, you may be able to shoehorn all into the three but that is 
> a disservice to the poor client who may have to figure these codes out.

> What I'm hearing is that some folks feel that we will ever have any 
> OAuth Extensions and anything that extends OAuth can do whatever it 
> likes and we don't want to have any conventions dictated by the base.

EHL

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Thu, 24 Mar 2011 14:17:19 -0700

You should probably go read RFC 2616 again...

EHL

> Sent: Thursday, March 24, 2011 2:15 PM
> Amusing like your past rants but they don't help or offer solutions. We
> proposed a solution in the bearer token specification, I have not seen you
> offer alternative to this proposal, so you're not being constructive here and
> trying to reach consensus. You don't agree with our use cases and
> requirements that we present, I can't help that.
> 
> >. Trying to put protected resource endpoints in the same bucket as OAuth
> endpoint is a violation of the protocol design.
> Yes, as pointed out there are many cases that the client needs or can have
> further information, and the HTTP Status codes don't cut it, like in the bearer
> token specification with "insufficient_scope", there is also the case
> authorization server is busy and the HTTP 503 Service Unavailable does not
> cut it but you want to let the requestor know to retry, as I indicated you can
> shoehorn all errors into just "invalid".
> 
> > The problem with the current registry proposal is that it is not backed by
> any requirements or use cases. After repeated requests, Mike Jones posted
> some examples which I replied to and demonstrated how they are invalid. I
> didn't see any counter arguments.
> The registry proposal is backed by several requirements and use cases, (1) I
> don't believe that the errors defined in oauth-v2 are future proof; registry
> provides a means to protect us here (2) There are no real processing
> requirements in the oauth-v2 document thus the authorization server may
> need to provide additional errors that correspond with their processing rules.
> 
> We actually have to make this stuff work, and why we had to go off and do
> WRAP as OAuth 1.0a was not meeting ours and others business needs, so
> technology or technical discussions are only part of the equation of our
> requirements.
> 
> 
> There are very different endpoints with different extensibility models. Trying
> to put protected resource endpoints in the same bucket as OAuth endpoint
> is a violation of the protocol design.
> 
> > I don't believe that
> Hearing where? We already have OAuth extensions (not token types and
> schemes but actual extensions to the OAuth endpoints).
> 
> The problem with the current registry proposal is that it is not backed by any
> requirements or use cases. After repeated requests, Mike Jones posted
> some examples which I replied to and demonstrated how they are invalid. I
> didn't see any counter arguments.
> 
> Like most other disagreements we had, you offer vague and non-technical
> arguments, ignore my extensive attempts at having a technical discussion,
> provide no concrete use cases or requirements, and try to get your point by
> making sweeping declarations about it being 'unusable'.
> 
> Based on the requirements I presented to the group with regard to error
> code extensibility (using the UX extension example), I will draft a proposal
> and seek feedback.
> 
> EHL
> 
> 
>