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 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. > 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:e...@hueniverse.com] Sent: Wednesday, March 23, 2011 3:30 PM To: Anthony Nadalin; Phil Hunt; Manger, James H Cc: oauth@ietf.org Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry > -----Original Message----- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > 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 _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
