Re: [OAUTH-WG] Error Encoding: Conclusion

[Eran Hammer <[e-mail]>]

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:[e-mail]]
> Sent: Thursday, May 31, 2012 10:54 AM
> To: Eran Hammer
> Cc: Mike Jones; [e-mail] 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-mail]]
> >> Sent: Wednesday, May 23, 2012 11:45 PM
> >> To: David Recordon; Mike Jones; Hannes Tschofenig
> >> Cc: [e-mail] 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:[e-mail]]
> >> Sent: Wednesday, May 23, 2012 11:38 PM
> >> To: Mike Jones; Hannes Tschofenig; Eran Hammer
> >> Cc: [e-mail] 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
> <[e-mail]> 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: [e-mail] [mailto:[e-mail]] On
> Behalf Of Hannes Tschofenig
> >> Sent: Wednesday, May 23, 2012 11:27 AM
> >> To: [e-mail] 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
> >>
> >> [e-mail]
> >>
> >> https://www.ietf.org/mailman/listinfo/oauth
> >>
> >>
> >>
> >>
> >> _______________________________________________
> >> OAuth mailing list
> >> [e-mail]
> >> 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>
> >