Subject: [OAUTH-WG] Error Encoding: Conclusion

From: Hannes Tschofenig <[email-masked]>
Date: Wed, 23 May 2012 21:27:03 +0300

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

---

From: Mike Jones <[email-masked]>
Date: Thu, 24 May 2012 05:22:46 +0000

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: [email-masked] [mailto:[email-masked]] On Behalf Of Hannes Tschofenig
Sent: Wednesday, May 23, 2012 11:27 AM
To: [email-masked] WG
Subject: [OAUTH-WG] Error Encoding: Conclusion

Hi all,

Ciao

Hannes & Derek

_______________________________________________

OAuth mailing list

[email-masked]<mailto:[email-masked]>

https://www.ietf.org/mailman/listinfo/oauth

---

From: David Recordon <[email-masked]>
Date: Wed, 23 May 2012 23:38:19 -0700

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 <[email-masked]>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****
>
> > ****
>
> ****
> ****
> >    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****
>
> ****
> >    defined.****
> 3444c3484,3485****
> <       (Section 4.2.2.1), or token error response (Section 5.2).****
>
> ---****
>
> ****
> >       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.****
>
> ** **
>
> ** **
> 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****
>
> [email-masked]****
>
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>
> [email-masked]

---

From: Eran Hammer <[email-masked]>
Date: Thu, 24 May 2012 06:44:45 +0000

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:[email-masked]]
Sent: Wednesday, May 23, 2012 11:38 PM
To: Mike Jones; Hannes Tschofenig; Eran Hammer
Cc: [email-masked] 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 <[email-masked]<mailto:[email-masked]>> wrote:

                                                            Cheers,

                                                            -- Mike

683c683,684

<    notation of [RFC5234].

---

1441c1441,1442

---

1474a1475,1476

1476c1478

---

1478a1481,1482

1482a1487,1489

1840c1840,1841

---

1873a1874,1875

1875c1877

---

1877a1880,1881

1881a1886,1888

---

2325a2326,2327

2327c2329

---

2329a2332,2333

2333a2338,2340

2450c2460,2468

---

2479c2489

---

2503a2514,2533

2602,2603c2624,2626

---

3444c3484,3485

---

3596a3554,3557

3611,3612c3572,3573

---

3616,3617c3577,3579

---

3620,3623c3589,3591

<               May 2011.

---

3626c3594

---

3628,3629c3596,3597

<               July 2011.

---

3468,3546d3503

3639c3609,3639

3468,3546d3503

3644,3645c3644,3656

3468,3546d3503

<    Farrell.

3646a3658,3661

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
Sent: Wednesday, May 23, 2012 11:27 AM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [OAUTH-WG] Error Encoding: Conclusion

Hi all,

Ciao

Hannes & Derek

OAuth mailing list

---

From: Mike Jones <[email-masked]>
Date: Tue, 29 May 2012 23:10:00 +0000

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:[email-masked]]
Sent: Wednesday, May 23, 2012 11:45 PM
To: David Recordon; Mike Jones; Hannes Tschofenig
Cc: [email-masked] WG
Subject: RE: [OAUTH-WG] Error Encoding: Conclusion

EH

From: David Recordon [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>
Sent: Wednesday, May 23, 2012 11:38 PM
To: Mike Jones; Hannes Tschofenig; Eran Hammer
Cc: [email-masked]<mailto:[email-masked]> WG
Subject: Re: [OAUTH-WG] Error Encoding: Conclusion

Thanks,
--David

                                                            Cheers,

                                                            -- Mike

683c683,684

<    notation of [RFC5234].

---

1441c1441,1442

---

1474a1475,1476

1476c1478

---

1478a1481,1482

1482a1487,1489

1840c1840,1841

---

1873a1874,1875

1875c1877

---

1877a1880,1881

1881a1886,1888

---

2325a2326,2327

2327c2329

---

2329a2332,2333

2333a2338,2340

2450c2460,2468

---

2479c2489

---

2503a2514,2533

2602,2603c2624,2626

---

3444c3484,3485

---

3596a3554,3557

3611,3612c3572,3573

---

3616,3617c3577,3579

---

3620,3623c3589,3591

<               May 2011.

---

3626c3594

---

3628,3629c3596,3597

<               July 2011.

---

3468,3546d3503

3639c3609,3639

3468,3546d3503

3644,3645c3644,3656

3468,3546d3503

<    Farrell.

3646a3658,3661

-----Original Message-----
From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]<mailto:[email-masked]>] On Behalf Of Hannes Tschofenig
Sent: Wednesday, May 23, 2012 11:27 AM
To: [email-masked]<mailto:[email-masked]> WG
Subject: [OAUTH-WG] Error Encoding: Conclusion

Hi all,

Ciao

Hannes & Derek

OAuth mailing list

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 May 2012 20:20:27 +0300

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>
> 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 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:
>  
> * Does the parameter need to / should be called ‘error’?
> On Wed, May 23, 2012 at 10:22 PM, Mike Jones <[email-masked]> wrote:
> ·        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
> 
>  
> 
> ·        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)
> 
>  
> 
> <draft-ietf-oauth-v2-26+mbj-2.xml><draft-ietf-oauth-v2-26+mbj-2.txt><draft-ietf-oauth-v2-26+mbj-2.html>

---

From: Hannes Tschofenig <[email-masked]>
Date: Thu, 31 May 2012 20:54:10 +0300

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

---

From: Eran Hammer <[email-masked]>
Date: Thu, 31 May 2012 19:35:26 +0000

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

> From: Hannes Tschofenig [mailto:[email-masked]]
> Sent: Thursday, May 31, 2012 10:54 AM
> To: Eran Hammer
> Cc: Mike Jones; [email-masked] WG; Hannes Tschofenig
> 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.
> 
> > thank you for compiling the text. It looks good to me. I have not seen
> anyone from the working group screaming either.
> >
> >> 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>
> >> 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.
> >>
> >> Hopefully incorporating these changes will enable us to close the
> remaining DISCUSS issues on both the Core and Bearer drafts.
> >>
> >>                                                                Thanks all,
> >>                                                                -- Mike
> >>
> >>
> >> 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.
> >>
> >> * 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)?
> 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
> extensibility. Extending the registry's scope means the need for non-trivial
> new text that:
> >>
> >> * guide authors of future HTTP authentication schemes meant for use
> with OAuth (e.g. MAC) for their requirements for using the error registry,
> and
> Protected resource endpoints). This requires changing the entire structure of
> the registry to create separate records for each code/location pair.
> >>
> >> Thanks,
> >> --David
> >>
> 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.
> >>
> >>
> >>
> conclusions are:
> document were:
> >> *        Updated out of date references, especially the draft-hardt-oauth-01
> reference, which contained an invalid link
> >>
> >> *        Replaced use of the deprecated <appendix> element, which
> 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].
> >>
> >> ---
> >>
> encoding. Here is the link to the call:
> >>
> 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
> >>
> >>
> >>
> >> <draft-ietf-oauth-v2-26+mbj-2.xml><draft-ietf-oauth-v2-26+mbj-
> 2.txt><draft-ietf-oauth-v2-26+mbj-2.html>
> >

---

From: Mike Jones <[email-masked]>
Date: Thu, 31 May 2012 20:52:52 +0000

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.  Version numbers are cheap...

				Thanks,
				-- Mike

-----Original Message-----
From: Eran Hammer [mailto:[email-masked]] 
Sent: Thursday, May 31, 2012 12:35 PM
To: Hannes Tschofenig
Cc: Mike Jones; [email-masked] WG
Subject: RE: [OAUTH-WG] Error Encoding: Conclusion

EH

> 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
> 
> 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>
> reference to OASIS.saml-core-2.0-os, since it is used by no <xref> in 
> the document.
> >>
> >>                                                                -- 
> >> Mike
> >> With the exception of section 7.2, the changes look reasonable and 
> >> will be
> applied in the next revision.
> >>
> defined for use with OAuth resource access methods'. This requirement 
> is too vague.
> >>
> >> * What about future methods in which errors are not simply 
> >> expressed in
> the form of a fixes string?
> >>
> >> EH
> >>
> >>
> 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?
> >>
> with OAuth (e.g. MAC) for their requirements for using the error 
> registry, and
> 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
> >>
> 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.
> >>
> >>
> >>
> prevented the spec from building with strict checking, with a 
> <section> element in the <back> section (which creates an appendix)
> >>
> >>
> >>
> 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].
> >>
> >> ---
> >>
> 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
> >>
> >>
> >>

---

From: Eran Hammer <[email-masked]>
Date: Fri, 1 Jun 2012 02:47:36 +0000

> From: Mike Jones [mailto:[email-masked]]
> Sent: Thursday, May 31, 2012 1:53 PM
> To: Eran Hammer; Hannes Tschofenig
> Cc: [email-masked] WG
> 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

> > >> *        Added Yaron Goland's middle initial Y. (since he prefers to include
> it
> > in publications)
> > >>

---

From: William Mills <[email-masked]>
Date: Thu, 31 May 2012 21:31:27 -0700 (PDT)

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 <[email-masked]>
>To: Mike Jones <[email-masked]>; Hannes Tschofenig <[email-masked]> 
>Cc: "[email-masked] WG" <[email-masked]> 
>Sent: Thursday, May 31, 2012 7:47 PM

---

From: Mike Jones <[email-masked]>
Date: Fri, 1 Jun 2012 04:45:35 +0000

Your proposal differs both from what's in Bearer and what's in Core at present.  By using the syntax restrictions from Bearer (which were already significantly discussed by the WG) in Core, developers have consistent rules, which was the point of the DISCUSS.

I don't believe that changing both sets of syntax restrictions was on the table at this point based upon the DISCUSS (but of course, the working group can still obviously do anything that there's clear consensus to do).

                                                            My two cents worth...
                                                            -- Mike

From: William Mills [mailto:[email-masked]]
Sent: Thursday, May 31, 2012 9:31 PM
To: Eran Hammer; Mike Jones; Hannes Tschofenig
Cc: [email-masked] WG
Subject: ABNF Re: [OAUTH-WG] Error Encoding: Conclusion

     error-char   = "-" / "." / "_" / DIGIT / ALPHA

     error-code   = *error-char

-bill

________________________________
From: Eran Hammer <[email-masked]<mailto:[email-masked]>>
To: Mike Jones <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 31, 2012 7:47 PM
Subject: Re: [OAUTH-WG] Error Encoding: Conclusion

> From: Mike Jones [mailto:[email-masked]<mailto:[email-masked]>]

My time isn't.

EH

> From: Eran Hammer [mailto:[email-masked]<mailto:[email-masked]>]
> Cc: Mike Jones; [email-masked]<mailto:[email-masked]> WG
> > From: Hannes Tschofenig [mailto:[email-masked]<mailto:[email-masked]>]
> > Cc: Mike Jones; [email-masked]<mailto:[email-masked]> WG; Hannes Tschofenig
> > >> From: Eran Hammer [mailto:[email-masked]<mailto:[email-masked]>]
> > >> From: David Recordon [mailto:[email-masked]<mailto:[email-masked]>]
> > >> On Wed, May 23, 2012 at 10:22 PM, Mike Jones
> > <[email-masked]<mailto:[email-masked]>> wrote:

---

From: William Mills <[email-masked]>
Date: Thu, 31 May 2012 21:55:52 -0700 (PDT)

So are you saying that 

1) I got your syntax right in the second one?
2) You like your syntax and don't want to limit it to a leading ALPHA?

-bill

> From: Mike Jones <[email-masked]>
>To: William Mills <[email-masked]>; Eran Hammer <[email-masked]>; Hannes Tschofenig <[email-masked]> 
>Sent: Thursday, May 31, 2012 9:45 PM
>Subject: RE: ABNF Re: [OAUTH-WG] Error Encoding: Conclusion
> 
>
> 
>Your proposal differs both from what’s in Bearer and what’s in Core at present.  By using the syntax restrictions from Bearer (which were already significantly discussed by the WG) in Core, developers have consistent rules, which was the point of the DISCUSS.
> 
>I don’t believe that changing both sets of syntax restrictions was on the table at this point based upon the DISCUSS (but of course, the working group can still obviously do anything that there’s clear consensus to do). 
> 
>                                                            My two cents worth…
>                                                            -- Mike
> 
>From:William Mills [mailto:[email-masked]] 
>>From:Eran Hammer <[email-masked]>
>>> > <[email-masked]> wrote:

---

From: Mike Jones <[email-masked]>
Date: Fri, 1 Jun 2012 05:41:35 +0000

Yes, (1) you got the Bearer syntax right in the second one (although I would say that it’s the working group’s consensus syntax, rather than taking personal credit for it, so I differ from use of “your”) and (2) yes, the working group didn’t see a reason to limit the syntax to requiring a leading alpha character.

Indeed, as an individual, I can easily envision meaningful error codes that don’t start with an alpha character, such as “403”, “401(k)_not_available”, “-1”, or “_claim_sources-invalid”.  I don’t see any reason to prohibit them, nor do I think it’s productive to have a discussion on changing the syntax at this stage in the spec development, where we’re close to closing all the DISCUSS issues and sending the specs to the RFC editor.

                                                            Best wishes,
                                                            -- Mike

From: William Mills [mailto:[email-masked]]
Sent: Thursday, May 31, 2012 9:56 PM
To: Mike Jones; Eran Hammer; Hannes Tschofenig
Cc: [email-masked] WG
Subject: Re: ABNF Re: [OAUTH-WG] Error Encoding: Conclusion

So are you saying that

-bill

________________________________
From: Mike Jones <[email-masked]<mailto:[email-masked]>>
To: William Mills <[email-masked]<mailto:[email-masked]>>; Eran Hammer <[email-masked]<mailto:[email-masked]>>; Hannes Tschofenig <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked] WG<mailto:[email-masked]%20WG>" <[email-masked]<mailto:[email-masked]>>
Sent: Thursday, May 31, 2012 9:45 PM
Subject: RE: ABNF Re: [OAUTH-WG] Error Encoding: Conclusion

                                                            My two cents worth…
                                                            -- Mike

From: William Mills [mailto:[email-masked]]<mailto:[mailto:[email-masked]]>

     error-code   = *error-char

-bill

My time isn't.

EH