#11: 10.3. The OAuth Extensions Error Registry Description changed by barryleiba@…:
Old description: > Pending Consensus: > > 10.3. The OAuth Extensions Error Registry > > This specification establishes the OAuth extensions error registry. > > Additional error codes used together with other protocol extensions (i.e. > extension grant types, access token types, or extension parameters) are > registered on the advice of one or more Designated Experts (appointed by > the IESG or their delegate), with a Specification Required (using > terminology from [RFC5226]). However, to allow for the allocation of > values prior to publication, the Designated Expert(s) may approve > registration once they are satisfied that such a specification will be > published. > > Registration requests should be sent to the [TBD]@ietf.org mailing list > for review and comment, with an appropriate subject (e.g., "Request for > error code: example"). [[ Note to RFC-EDITOR: The name of the mailing > list should be determined in consultation with the IESG and IANA. > Suggested name: oauth-ext-review. ]] > > Within at most 14 days of the request, the Designated Expert(s) will > either approve or deny the registration request, communicating this > decision to the review list and IANA. Denials should include an > explanation and, if applicable, suggestions as to how to make the request > successful. > > Decisions (or lack thereof) made by the Designated Expert can be first > appealed to Application Area Directors (contactable using app- > [email protected] email address or directly by looking up their email > addresses on http://www.iesg.org/ website) and, if the appellant is not > satisfied with the response, to the full IESG (using the [email protected] > mailing list). > > IANA should only accept registry updates from the Designated Expert(s), > and should direct all requests for registration to the review mailing > list. > > ---------------------------------------------- > > Tony Nadalin: > The remaining technical issue in this regard is the need to expand the > scope of the registry to encompass errors returned from resource servers. > The error registry was introduced to address a requirement that existed > in the working group documents prior to the split. This requirement was > expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ > Add mechanism for extending error codes ]]". New description: Pending Consensus: 10.3. The OAuth Extensions Error Registry This specification establishes the OAuth extensions error registry. Additional error codes used together with other protocol extensions (i.e. extension grant types, access token types, or extension parameters) are registered on the advice of one or more Designated Experts (appointed by the IESG or their delegate), with a Specification Required (using terminology from [RFC5226]). However, to allow for the allocation of values prior to publication, the Designated Expert(s) may approve registration once they are satisfied that such a specification will be published. Registration requests should be sent to the [TBD]@ietf.org mailing list for review and comment, with an appropriate subject (e.g., "Request for error code: example"). [[ Note to RFC-EDITOR: The name of the mailing list should be determined in consultation with the IESG and IANA. Suggested name: oauth-ext-review. ]] Within at most 14 days of the request, the Designated Expert(s) will either approve or deny the registration request, communicating this decision to the review list and IANA. Denials should include an explanation and, if applicable, suggestions as to how to make the request successful. Decisions (or lack thereof) made by the Designated Expert can be first appealed to Application Area Directors (contactable using app- [email protected] email address or directly by looking up their email addresses on http://www.iesg.org/ website) and, if the appellant is not satisfied with the response, to the full IESG (using the [email protected] mailing list). IANA should only accept registry updates from the Designated Expert(s), and should direct all requests for registration to the review mailing list. ---------------------------------------------- Tony Nadalin: The remaining technical issue in this regard is the need to expand the scope of the registry to encompass errors returned from resource servers. The error registry was introduced to address a requirement that existed in the working group documents prior to the split. This requirement was expressed in draft 10, Section 3.2.1 and draft 11, Section 4.3.1 as "[[ Add mechanism for extending error codes ]]". ------------------------------------------------- Related to ticket 10: http://trac.tools.ietf.org/wg/oauth/trac/ticket/10 -- -- --------------------------------+------------------------------------------- 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/11#comment:2> oauth <http://tools.ietf.org/oauth/> _______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
