#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/>
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
