Subject: [OAUTH-WG] [oauth] #10: 8.4. Defining Additional Error Codes

From: "oauth issue tracker" <[email-masked]>
Date: Fri, 15 Apr 2011 15:08:07 -0000

#10: 8.4. Defining Additional Error Codes

 Pending Consensus:

 8.4. Defining Additional Error Codes

 In cases where protocol extensions (i.e. access token types, extension
 parameters, or extension grant types) require additional error codes to be
 used with the authorization code grant error response (Section 4.1.2.1),
 the implicit grant error response (Section 4.2.2.1), or the token error
 response (Section 5.2), such error codes MAY be defined.

 Extension error codes MUST be registered (following the procedures in
 Section 10.3) if the extension they are used in conjunction with is
 registered.  Additional error codes used with unregistered extensions MAY
 be registered.

 Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed by
 an identifying name when possible.  For example, an error identifying an
 invalid value set to the extension parameter "example" should be named
 "example_invalid".

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

-- 
--------------------------------+-------------------------------------------
 Reporter:  Eran Hammer-Lahav   |       Owner:                        
     Type:  suggested change    |      Status:  new                   
 Priority:  major               |   Milestone:  Deliver OAuth 2.0 spec
Component:  v2                  |     Version:                        
 Severity:  Active WG Document  |    Keywords:                        
--------------------------------+-------------------------------------------

Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/10>
oauth <http://tools.ietf.org/oauth/>

---

From: "oauth issue tracker" <[email-masked]>
Date: Sat, 16 Apr 2011 15:03:35 -0000

Description changed by barryleiba@…:

Old description:

> parameters, or extension grant types) require additional error codes to
> be used with the authorization code grant error response (Section
> 4.1.2.1), the implicit grant error response (Section 4.2.2.1), or the
> token error response (Section 5.2), such error codes MAY be defined.
>
> Error codes MUST conform to the error-code ABNF, and SHOULD be prefixed
> by an identifying name when possible.  For example, an error identifying
> an invalid value set to the extension parameter "example" should be named
> "example_invalid".
>

New description:

 Pending Consensus:

 -------------------------------------------------
 Related to ticket 11:
 http://trac.tools.ietf.org/wg/oauth/trac/ticket/11

--

Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/10#comment:1>
oauth <http://tools.ietf.org/oauth/>

---

From: "oauth issue tracker" <[email-masked]>
Date: Sat, 16 Apr 2011 15:03:57 -0000

New description:

 Pending Consensus:

--

Ticket URL: <http://trac.tools.ietf.org/wg/oauth/trac/ticket/10#comment:2>
oauth <http://tools.ietf.org/oauth/>