I don't need to repeat three months of extensive arguments. AIRI, you were as strongly opinionated about this as I was, and it was largely an argument between my, you, and Tony Nadalin. After we failed to reach WG consensus - we did resolve some items as you indicated below - the chairs formed a design committee on which both Tony and I served. The committee unanimously decided to not include the protected resource location in the registry. The chairs presented this to the group, then closed the items.
My point is, it was a long and extensive debated that required much effort to resolve. Now all of a sudden, getting a quick round of +1 is enough to undo 3 months of negotiations. That's clearly a broken process. EH From: Mike Jones [mailto:michael.jo...@microsoft.com] Sent: Wednesday, May 09, 2012 5:42 PM To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org) Subject: RE: Bearer token DISCUSS items related to errors I believe that you're intentionally oversimplifying things. My memory was that originally you objected to having the OAuth Errors Registry at all. Issue 11 was about getting it created in the first place, despite your objections. The compromise with you to get you to agree to it was that you intentionally excluded registration of errors resulting from OAuth flows E and F. I fully remember what a painful process it was to get you to agree to that much, if that's the "extensive discussion by the working group" that you're referring to. I wouldn't characterize the result as "working group consensus" so much as exhaustion. As I see it as an individual, Russ's DISCUSS results from the simple observation that OAuth errors are not consistently registered across the OAuth specs. This may or not be changed, depending upon the result of the consensus call and a decision by the chairs. I'm fine with either outcome, but believe that the working group should earnestly consider his request. We're almost done. I hope that after the consensus calls, this and the other open issues can be quickly addressed and we can finally achieve OAuth 2.0 RFCs. -- Mike From: oauth-boun...@ietf.org<mailto:oauth-boun...@ietf.org> [mailto:oauth-boun...@ietf.org]<mailto:[mailto:oauth-boun...@ietf.org]> On Behalf Of Eran Hammer Sent: Wednesday, May 09, 2012 5:17 PM To: oauth@ietf.org<mailto:oauth@ietf.org> WG (oauth@ietf.org<mailto:oauth@ietf.org>) Subject: [OAUTH-WG] Bearer token DISCUSS items related to errors Most people on this WG are not aware of all the details around the on-going IESG review and my objections to making additional changes to the core specification. Currently, these are the open issues preventing the bearer specification from being approved: >From Russ Housley: Section 3.1 specifies Error Codes. Alexey suggested the use of an IANA registry for this field. Apparently there is already a registry created by draft-ietf-oauth-v2. However this document does not register values defined in this section in that registry. Please explain why the IANA registry is not leveraged by this document. >From Sean Turner: s3.1: Shouldn't the character set restrictions on error, error_description, and error_uri be in draft-ietf-oauth-v2? >From Pete Resnick: [ the use of a reserved query parameter 'access_token' ] --- Sean Turner closed this issue today so it is no longer relevant. Basically, as currently drafted, there is no overlap between the parameters and the encoding reflects the transport restrictions of each specification. While I don't have a technical objection to limiting the character set of the error parameter in the core specification, I do object to making a breaking change at this point without any actual technical justification. Peter Resnick's issue has nothing to do with this so I will not discuss it. The only remaining issue is Russ' which SHOULD have been replied to with: --- The use of the error registry in draft-ietf-oauth-v2 for the error codes defined in the bearer specification was extensively discussed by the working group and the special design committee appointed by the chairs. The working group consensus was that these errors, while similar is name and meaning to those used in the core specification, belong elsewhere. They relate to the protected resource namespace which is not covered by the core specification. In addition, there was no working group consensus whether the error parameter used by the bearer specification was the preferred mechanism for relaying errors in protected resource access or HTTP authentication schemes (e.g. the MAC token scheme draft does not use such mechanism and opted to rely on simple HTTP status codes instead). At the time, the working group reached out to HTTPbis for guidance and did not receive a conclusive answer. This issue was documented in the issues tracker [1] and was closed after extensive discussions. The working group's consensus was that if a registry is required, it should be defined within the bearer specification. --- All Russ was asking for is an explanation. Instead, he was told there was no good reason and that it should be changed. That was clearly not an honest representation of clear working group consensus from over 10 months ago which was achieved at great effort. EH [1] http://trac.tools.ietf.org/wg/oauth/trac/ticket/11
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
