[OAUTH-WG] ABNF Re: Error Encoding: Conclusion

[William Mills <[e-mail]>]

The current OAuth core spec section 8.5 has:
error-code   = ALPHA *error-char error-char   = "-" / "." / "_" / DIGIT / ALPHA 
Mike's proposal would nominally be:

error-code   = *error-char
     error-char   = %x20-21 / %x23-5B / %x5D-7E 
This is the set of ASCII characters from SPACE to '~' excluding '\' and '"'.  I'm not 
in love with that, but it's clear.  I'd prefer:

error-code   = ALPHA *error-char
     error-char   = %x20-21 / %x23-5B / %x5D-7E 
-bill 




>________________________________
> From: Eran Hammer <[e-mail]>
>To: Mike Jones <[e-mail]>; Hannes Tschofenig <[e-mail]> 
>Cc: "[e-mail] WG" <[e-mail]> 
>Sent: Thursday, May 31, 2012 7:47 PM
>Subject: Re: [OAUTH-WG] Error Encoding: Conclusion
> 
>
>
>> -----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>
>> > >
>> 
>> 
>
>_______________________________________________
>OAuth mailing list
>[e-mail]
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>