I'll first review the proposed text (as a WG member) and raise any issues remaining (if any).
I will wait until the ABNF text is provided before publishing another version. EH > -----Original Message----- > From: Hannes Tschofenig [mailto:hannes.tschofe...@gmx.net] > Sent: Thursday, May 31, 2012 10:54 AM > To: Eran Hammer > Cc: Mike Jones; oauth@ietf.org WG; Hannes Tschofenig > Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > > Eran, could you publish a new draft version by Sunday with these changes > incorporated? That should give the working group enough time to look at > these few paragraphs. > > In the meanwhile we are working on addressing the ABNF issue Sean raised > and we will then go for another update. > > Ciao > Hannes > > On May 31, 2012, at 8:20 PM, Hannes Tschofenig wrote: > > > Hi Mike, > > > > thank you for compiling the text. It looks good to me. I have not seen > anyone from the working group screaming either. > > > > Eran, can you incorporate these changes into the next draft version? > > > > Ciao > > Hannes > > > > On May 30, 2012, at 2:10 AM, Mike Jones wrote: > > > >> I've made another set of updates to a copy of Core -26 to address the > questions raised by Eran and David below (attached). > >> > >> An unrelated change that you should probably pick up, Eran is adding this > to the <front> section, so that the heading shows that the draft is a product > of the "OAuth Working Group" rather than the "Network Working Group": > >> <area>Security</area> > >> <workgroup>OAuth Working Group</workgroup> > >> > >> One change I didn't make, but that should be considered, is to delete the > reference to OASIS.saml-core-2.0-os, since it is used by no <xref> in the > document. > >> > >> The new proposed text for Section 7.2 follows: > >> > >> 7.2. Error Response > >> > >> If a resource access request fails, the resource server SHOULD inform > >> the client of the error. While the specific error responses possible > >> and methods for transmitting those errors when using any particular > >> access token type are beyond the scope of this specification, any > >> "error" code values defined for use with OAuth resource access > >> methods MUST be registered (following the procedures in > >> Section 11.4). > >> > >> Specifically, when the OAuth resource access method uses an "error" > >> result parameter to return an error code value that indicates the > >> resource access error encountered, then these error code values MUST > >> be registered. Values for these "error" codes MUST NOT include > >> characters outside the set %x20-21 / %x23-5B / %x5D-7E. When an > >> "error" code value is registered for use by an OAuth resource access > >> method, should that same code already be registered for use by > >> another OAuth resource access method or at a different OAuth error > >> usage location, then the meaning of that error code value in in the > >> new registration MUST be consistent with the its meaning in prior > >> registrations. > >> > >> The OAuth resource access error registration requirement applies only > >> to "error" code values and not to other means of returning error > >> indications, including HTTP status codes, or other error-related > >> result parameters, such as "error_description", "error_uri", or other > >> kinds of error status return methods that may be employed by the > >> resource access method. There is no requirement that OAuth resource > >> access methods employ an "error" parameter. > >> > >> Hopefully incorporating these changes will enable us to close the > remaining DISCUSS issues on both the Core and Bearer drafts. > >> > >> Thanks all, > >> -- Mike > >> > >> > >> From: Eran Hammer [mailto:e...@hueniverse.com] > >> Sent: Wednesday, May 23, 2012 11:45 PM > >> To: David Recordon; Mike Jones; Hannes Tschofenig > >> Cc: oauth@ietf.org WG > >> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion > >> > >> With the exception of section 7.2, the changes look reasonable and will be > applied in the next revision. > >> > >> The new section 7.2 is confusion and does not explain the new registry. > The section introduces a new requirement to register 'any error codes > defined for use with OAuth resource access methods'. This requirement is > too vague. > >> > >> I have no clue how to (for example) apply this text to the MAC draft. > Adding to David's list below: > >> > >> * Should the HTTP status codes used by the MAC spec as currently written > be registered (since no guidance is given to the use of an error parameter)? > >> * Does this introduce a requirement to add an error parameter? > >> * Does the parameter need to / should be called 'error'? > >> * What about future methods in which errors are not simply expressed in > the form of a fixes string? > >> > >> EH > >> > >> > >> From: David Recordon [mailto:record...@gmail.com] > >> Sent: Wednesday, May 23, 2012 11:38 PM > >> To: Mike Jones; Hannes Tschofenig; Eran Hammer > >> Cc: oauth@ietf.org WG > >> Subject: Re: [OAUTH-WG] Error Encoding: Conclusion > >> > >> Honestly still trying to fully wrap my head around what's going on here > since it seems far more complex than the threads are alluding to. In any case, > does Mike's text address what Eran brought up as needed in the thread > Hannes referenced or is Eran wrong? > >> > >> The core spec currently provides full guidance and definition for error > extensibility. Extending the registry's scope means the need for non-trivial > new text that: > >> > >> * explains the process of adding new errors for endpoints not defined by > this specification, > >> * finds a common ground for value restrictions beyond what is already > listed, > >> * guide authors of future HTTP authentication schemes meant for use > with OAuth (e.g. MAC) for their requirements for using the error registry, > and > >> * address the very likely scenario of the same error code carrying > different meanings in different endpoints, or an extension that adds a > location to a code already defined elsewhere - something very likely to > happen if you cross the two very different domains (OAuth endpoints, > Protected resource endpoints). This requires changing the entire structure of > the registry to create separate records for each code/location pair. > >> > >> Thanks, > >> --David > >> > >> On Wed, May 23, 2012 at 10:22 PM, Mike Jones > <michael.jo...@microsoft.com> wrote: > >> Thanks Hannes. In the interest of hopefully completing the edits to > remove the DISCUSS issues for the Bearer and Core specs in the next few > days so that we can send the docs to the RFC editors, I'd like to propose > specific language for the Core spec to address both of the consensus call > issue resolutions. After there's consensus on the specific text for Core, it > will > be easy for us to add a reference in Bearer to the language in Core for the > error syntax restrictions and to use the OAuth errors registry. I'll do that > in > parallel with the discussions on the proposed core language changes. > >> > >> > >> > >> A summary of the changes I made in response to the consensus call > conclusions are: > >> > >> * Add syntax restrictions for "error", "error_description", and > "error_uri" from Bearer to Core > >> > >> * Add section 7.2 about error responses from resource access > >> requests > >> > >> * Add "resource access error response" to the category of OAuth > errors that can be registered > >> > >> > >> > >> Additional editorial changes that I made as I encountered issues in the > document were: > >> > >> * Updated out of date references, especially the > >> draft-hardt-oauth-01 > reference, which contained an invalid link > >> > >> * Added Derek Atkins to the list of chairs > >> > >> * Added Yaron Goland's middle initial Y. (since he prefers to > >> include it > in publications) > >> > >> * Replaced use of the deprecated <appendix> element, which > prevented the spec from building with strict checking, with a <section> > element in the <back> section (which creates an appendix) > >> > >> > >> > >> To make it easy to incorporate these changes into the document and so > the proposed changes are unambiguous, I produced an edited version of > Core -26 containing these changes. The xml, txt, and html versions are > attached to facilitate review. Pertinent diffs from the .txt version follow. > >> > >> > >> > >> Cheers, > >> > >> -- Mike > >> > >> > >> > >> 683c683,684 > >> > >> < notation of [RFC5234]. > >> > >> --- > >> > >>> notation of [RFC5234]. Additionally, the rule URI-Reference is > >> > >>> included from Uniform Resource Identifier (URI) [RFC3986]. > >> > >> 1441c1441,1442 > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 1474a1475,1476 > >> > >>> Values for the "error" parameter MUST NOT include characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1476c1478 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 1478a1481,1482 > >> > >>> Values for the "error_description" parameter MUST NOT include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1482a1487,1489 > >> > >>> Values for the "error_uri" parameter MUST conform to the URI- > >> > >>> Reference syntax, and thus MUST NOT include characters outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> 1840c1840,1841 > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 1873a1874,1875 > >> > >>> Values for the "error" parameter MUST NOT include characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1875c1877 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 1877a1880,1881 > >> > >>> Values for the "error_description" parameter MUST NOT include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 1881a1886,1888 > >> > >>> Values for the "error_uri" parameter MUST conform to the URI- > >> > >>> Reference syntax, and thus MUST NOT include characters outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> < REQUIRED. A single error code from the following: > >> > >> --- > >> > >>> REQUIRED. A single ASCII [USASCII] error code from the > >> > >>> following: > >> > >> 2325a2326,2327 > >> > >>> Values for the "error" parameter MUST NOT include characters > >> > >>> outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 2327c2329 > >> > >> < OPTIONAL. A human-readable UTF-8 encoded text providing > >> > >> --- > >> > >>> OPTIONAL. A human-readable ASCII [USASCII] text providing > >> > >> 2329a2332,2333 > >> > >>> Values for the "error_description" parameter MUST NOT include > >> > >>> characters outside the set %x20-21 / %x23-5B / %x5D-7E. > >> > >> 2333a2338,2340 > >> > >>> Values for the "error_uri" parameter MUST conform to the URI- > >> > >>> Reference syntax, and thus MUST NOT include characters outside > >> > >>> the set %x21 / %x23-5B / %x5D-7E. > >> > >> 2450c2460,2468 > >> > >> < The method in which the client utilized the access token to > >> > >> --- > >> > >>> The method in which the client utilizes the access token to > >> > >> 2479c2489 > >> > >> < Authorization: Bearer 7Fjfp0ZBr1KtDRbnfVdmIw > >> > >> --- > >> > >>> Authorization: Bearer mF_9.B5f-4.1JqM > >> > >> 2503a2514,2533 > >> > >>> > >> > >>> 7.2. Error Response > >> > >>> > >> > >>> If a resource access request fails, the resource server SHOULD inform > >> > >>> the client of the error. While the specific error responses possible > >> > >>> and methods for transmitting those errors when using any particular > >> > >>> access token type are beyond the scope of this specification, any > >> > >>> error codes defined for use with OAuth resource access methods MUST > >> > >>> be registered (following the procedures in Section 11.4). > >> > >>> > >> > >>> > >> > >> 2602,2603c2624,2626 > >> > >> < (Section 4.2.2.1), or the token error response (Section 5.2), such > >> > >> < error codes MAY be defined. > >> > >> --- > >> > >>> (Section 4.2.2.1), the token error response (Section 5.2), or the > >> > >>> resource access error response (Section 7.2), such error codes MAY be > >> > >>> defined. > >> > >> 3444c3484,3485 > >> > >> < (Section 4.2.2.1), or token error response (Section 5.2). > >> > >> --- > >> > >>> (Section 4.2.2.1), token error response (Section 5.2), or resource > >> > >>> access error response (Section 7.2). > >> > >> 3596a3554,3557 > >> > >>> [USASCII] American National Standards Institute, "Coded Character > >> > >>> Set -- 7-bit American Standard Code for Information > >> > >>> Interchange", ANSI X3.4, 1986. > >> > >>> > >> > >> 3611,3612c3572,3573 > >> > >> < OAuth 2.0", draft-ietf-oauth-saml2-bearer-08 (work in > >> > >> < progress), August 2011. > >> > >> --- > >> > >>> OAuth 2.0", draft-ietf-oauth-saml2-bearer-12 (work in > >> > >>> progress), May 2012. > >> > >> 3616,3617c3577,3579 > >> > >> < Protocol: Bearer Tokens", draft-ietf-oauth-v2-bearer-08 > >> > >> < (work in progress), July 2011. > >> > >> --- > >> > >>> Authorization Protocol: Bearer Tokens", > >> > >>> draft-ietf-oauth-v2-bearer-19 (work in progress), > >> > >>> April 2012. > >> > >> 3620,3623c3589,3591 > >> > >> < Hammer-Lahav, E., Barth, A., and B. Adida, "HTTP > >> > >> < Authentication: MAC Access Authentication", > >> > >> < draft-ietf-oauth-v2-http-mac-00 (work in progress), > >> > >> < May 2011. > >> > >> --- > >> > >>> Hammer-Lahav, E., "HTTP Authentication: MAC Access > >> > >>> Authentication", draft-ietf-oauth-v2-http-mac-01 (work in > >> > >>> progress), February 2012. > >> > >> 3626c3594 > >> > >> < Lodderstedt, T., McGloin, M., and P. Hunt, "OAuth 2.0 > >> > >> --- > >> > >>> McGloin, M., Hunt, P., and T. Lodderstedt, "OAuth 2.0 > >> > >> 3628,3629c3596,3597 > >> > >> < draft-ietf-oauth-v2-threatmodel-00 (work in progress), > >> > >> < July 2011. > >> > >> --- > >> > >>> draft-ietf-oauth-v2-threatmodel-02 (work in progress), > >> > >>> February 2012. > >> > >> 3468,3546d3503 > >> > >> < Brian Eaton, Yaron Goland, Dick Hardt, and Allen Tom. > >> > >> 3639c3609,3639 > >> > >>> Brian Eaton, Yaron Y. Goland, Dick Hardt, and Allen Tom. > >> > >> 3468,3546d3503 > >> > >> < Yaron Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, > >> > >> 3644,3645c3644,3656 > >> > >>> Yaron Y. Goland, Brent Goldman, Kristoffer Gronowski, Justin Hart, > >> > >> 3468,3546d3503 > >> > >> < This document was produced under the chairmanship of Blaine Cook, > >> > >> < Peter Saint-Andre, Hannes Tschofenig, and Barry Leiba. The area > >> > >> < directors included Lisa Dusseault, Peter Saint-Andre, and Stephen > >> > >> < Farrell. > >> > >> 3646a3658,3661 > >> > >>> This document was produced under the chairmanship of Blaine Cook, > >> > >>> Peter Saint-Andre, Hannes Tschofenig, Barry Leiba, and Derek Atkins. > >> > >>> The area directors included Lisa Dusseault, Peter Saint-Andre, and > >> > >>> Stephen Farrell. > >> > >> > >> > >> -----Original Message----- > >> From: oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] On > Behalf Of Hannes Tschofenig > >> Sent: Wednesday, May 23, 2012 11:27 AM > >> To: oauth@ietf.org WG > >> Subject: [OAUTH-WG] Error Encoding: Conclusion > >> > >> > >> > >> Hi all, > >> > >> > >> > >> on May 10th we called for consensus on an open issue regarding the error > encoding. Here is the link to the call: > >> > >> http://www.ietf.org/mail-archive/web/oauth/current/msg08994.html > >> > >> > >> > >> Thank you all for the feedback. The conclusion of the consensus call was > to harmonize the encoding between the two specifications by incorporating > the restrictions from the bearer specification into the base specification. > The > error encoding will go into the core specification and the bearer > specification > will reference it. > >> > >> > >> > >> Ciao > >> > >> Hannes & Derek > >> > >> > >> > >> _______________________________________________ > >> > >> OAuth mailing list > >> > >> OAuth@ietf.org > >> > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> > >> > >> _______________________________________________ > >> OAuth mailing list > >> OAuth@ietf.org > >> https://www.ietf.org/mailman/listinfo/oauth > >> > >> > >> <draft-ietf-oauth-v2-26+mbj-2.xml><draft-ietf-oauth-v2-26+mbj- > 2.txt><draft-ietf-oauth-v2-26+mbj-2.html> > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
