Re: [OAUTH-WG] Section 7.2

WFM.

This will be the new text for 7.2 unless someone has any additional feedback or concerns.

This closes my issue with the new error registry changes.

EH

From: Mike Jones [mailto:Michael.Jones@microsoft.com]
Sent: Thursday, June 14, 2012 6:15 PM
To: Eran Hammer; oauth@ietf.org WG (oauth@ietf.org)
Subject: RE: [OAUTH-WG] Section 7.2

Thanks for writing the text below.  It looks fine to me.  About adding the other error parameters as suggestions, that seems like a reasonable thing to do.  How about the text at the end below, which adds mentions of error_description and error_uri?

7.2.  Error Response

   If a resource access request fails, the resource server SHOULD inform

   the client of the error.  While the specifics of such error responses

   are beyond the scope of this specification, this documents establishes

   a common registry for error values to be shared among OAuth token

   authentication schemes.

   New authentication schemes designed primarily for OAuth token

   authentication SHOULD define a mechanism for providing an

   error status code to the client, in which the error values allowed are

   registered in the error registry established by this specification. Such

   schemes MAY limit the set of valid error codes to a subset of the

   registered values. If the error code is returned using a named parameter,

   the parameter name SHOULD be "error".

   Other schemes capable of being used for OAuth token authentication, but

   not primarily designed for that purpose, MAY bind their error values to the

   registry in the same manner.

   New authentication schemes MAY choose to also specify the use of the

   "error_description" and "error_uri" parameters to return error information

   in a manner parallel to their usage in this specification.

                                                            -- Mike

P.S.  If you already have the text you wrote in a copy of the draft, you should apply these spelling corrections:

               desgined -> designed

               authentiction -> authentication

-----Original Message-----
From: Eran Hammer [mailto:eran@hueniverse.com]<mailto:[mailto:eran@hueniverse.com]>
Sent: Thursday, June 14, 2012 3:29 PM
To: Eran Hammer; Mike Jones; oauth@ietf.org<mailto:oauth@ietf.org> WG (oauth@ietf.org<mailto:oauth@ietf.org>)
Subject: RE: [OAUTH-WG] Section 7.2

Mike - if you want to add the other error parameters as suggestions, that would be fine by me.

EH

> -----Original Message-----

> From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org]<mailto:[mailto:oauth-bounces@ietf.org]> On Behalf

> Of Eran Hammer

> Sent: Thursday, June 14, 2012 3:23 PM

> To: Mike Jones; oauth@ietf.org<mailto:oauth@ietf.org> WG (oauth@ietf.org<mailto:oauth@ietf.org>)

> Subject: Re: [OAUTH-WG] Section 7.2

>

> 7.2.  Error Response

>

>    If a resource access request fails, the resource server SHOULD inform

>    the client of the error.  While the specifics of such error responses

>    are beyond the scope of this specification, this documents establishes

>    a common registry for error values to be shared among OAuth token

>    authentication schemes.

>

>    New authentication schemes desgined primarily for OAuth token

>    authentiction SHOULD define a mechanism for providing an

>    error status code to the client, in which the error values allowed are

>    registered in the error registry established by this specification. Such

>    schemes MAY limit the set of valid error codes to a subset of the

>    registered values. If the error code is returned using a named parameter,

>    the parameter name SHOULD be "error".

>

>    Other schemes capable of being used for OAuth token authentication, but

>    not primarily designed for that purpose, MAY bind their error values to the

>    registry in the same manner.

>

> EH

>

> _______________________________________________

> OAuth mailing list

> OAuth@ietf.org<mailto:OAuth@ietf.org>

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