Re: [OAUTH-WG] Error Encoding: Conclusion

[Eran Hammer <[e-mail]>]

> -----Original Message-----
> From: Mike Jones [mailto:[e-mail]]
> Sent: Thursday, May 31, 2012 1:53 PM
> To: Eran Hammer; Hannes Tschofenig
> Cc: [e-mail] WG
> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion
> 
> Actually, could you please publish before the ABNF is done so that I can
> publish a version of Bearer referencing the new text in Core, so it can be
> reviewed by the WG in parallel with the ABNF work happening?  I think that
> was Hannes' intent in asking you to publish soon.

I'll review the text and will reply back as to publishing schedule.

> Version numbers are
> cheap...

My time isn't.

EH

> 				Thanks,
> 				-- Mike
> 
> -----Original Message-----
> From: Eran Hammer [mailto:[e-mail]]
> Sent: Thursday, May 31, 2012 12:35 PM
> To: Hannes Tschofenig
> Cc: Mike Jones; [e-mail] WG
> Subject: RE: [OAUTH-WG] Error Encoding: Conclusion
> 
> 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>
> > >
> 
>