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
