You should probably go read RFC 2616 again... EHL
> -----Original Message----- > From: Anthony Nadalin [mailto:tony...@microsoft.com] > Sent: Thursday, March 24, 2011 2:15 PM > To: Eran Hammer-Lahav; Phil Hunt; Manger, James H > Cc: oauth@ietf.org > Subject: RE: [OAUTH-WG] Apparent consensus on OAuth Errors Registry > > 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
