Re: [OAUTH-WG] Error Encoding: Conclusion

[David Recordon <[e-mail]>]

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
>
>