> -----Original Message----- > From: Anthony Nadalin [mailto:[email protected]] > 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 [email protected] https://www.ietf.org/mailman/listinfo/oauth
