The ABNF must reflect the existing draft, not invent new restrictions. The only field we had consensus for applying new restrictions on is error (and the related ones from bearer). That's it. Please have the proposed ABNF reflect the unrestricted nature of all values not explicitly defined otherwise.
EH From: [email protected] [mailto:[email protected]] On Behalf Of Mike Jones Sent: Saturday, June 02, 2012 1:10 AM To: [email protected] Subject: [OAUTH-WG] ABNF elements for suggested WG review Dear working group, It turns out that writing an ABNF for the Core spec pointed out that the syntax of a number of the OAuth protocol elements had not been previously defined. (Thanks, Sean, for having us do this!) I took a stab at specifying appropriate ABNF values for each of the protocol elements, but I would request that the working group actively review the choices in my proposed draft. For instance, I chose to use the same syntax definitions for username and password and client_id and client_secret as HTTP Basic used for userid and password. Other choices were possible, such as perhaps limiting client_id and possibly username values to use "unreserved" characters, rather than allowing all characters other than ":" (as HTTP Basic did with userid). Please particularly review the syntax definitions for these elements, as I had to make choices that went beyond the current specs to provide unambiguous syntax definitions: client_id client_secret state code access_token username password refresh_token The full proposed ABNF section follows. -- Mike Appendix A. Augmented Backus-Naur Form (ABNF) Syntax This section provides Augmented Backus-Naur Form (ABNF) syntax descriptions for the elements defined in this specification using the notation of [RFC5234]. Elements are presented in the order first defined. Some of the definitions that follow use the "unreserved" and "URI" definitions from [RFC3986], which are: unreserved = ALPHA / DIGIT / "-" / "." / "_" / "~" URI = scheme ":" hier-part [ "?" query ] [ "#" fragment ] Some of the definitions that follow use the "b64token" syntax below, which matches the "b64token" syntax defined by HTTP/1.1, Part 7 [I-D.ietf-httpbis-p7-auth]: b64token = 1*( ALPHA / DIGIT / "-" / "." / "_" / "~" / "+" / "/" ) *"=" A.1. "client_id" Syntax The "client_id" element is defined in Section 2.3.1: client-id = *<TEXT excluding ":"> (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.2. "client_secret" Syntax The "client_secret" element is defined in Section 2.3.1: client-secret = *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.3. "response_type" Syntax The "response_type" element is defined in Section 3.1.1 and Section 8.4: response-type = response-name *( SP response-name ) response-name = 1*response-char response-char = "_" / DIGIT / ALPHA A.4. "scope" Syntax The "scope" element is defined in Section 3.3: scope = scope-token *( SP scope-token ) scope-token = 1*( %x21 / %x23-5B / %x5D-7E ) A.5. "state" Syntax The "state" element is defined in Section 4.1.1, Section 4.1.2, Section 4.1.2.1, Section 4.2.1, Section 4.2.2, and Section 4.2.2.1: state = 1*unreserved A.6. "redirect_uri" Syntax The "redirect_uri" element is defined in Section 4.1.1, Section 4.1.3, and Section 4.2.1: redirect-uri = URI A.7. "error" Syntax The "error" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, Section 7.2, and Section 8.5: error = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E A.8. "error_description" Syntax The "error_description" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-description = 1*error-char error-char = %x20-21 / %x23-5B / %x5D-7E A.9. "error_uri" Syntax The "error_uri" element is defined in Section 4.1.2.1, Section 4.2.2.1, Section 5.2, and Section 7.2: error-uri = URI A.10. "grant_type" Syntax The "grant_type" element is defined in Section 4.1.3, Section 4.3.2, Section 4.4.1, Section 6, and Section 4.5: grant-type = grant-name / URI grant-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA A.11. "code" Syntax The "code" element is defined in Section 4.1.3: code = 1*unreserved A.12. "access_token" Syntax The "access_token" element is defined in Section 4.2.2 and Section 5.1: access-token = b64token A.13. "token_type" Syntax The "token_type" element is defined in Section 4.2.2, Section 5.1, and Section 8.1: token-type = type-name / URI type-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA A.14. "expires_in" Syntax The "expires_in" element is defined in Section 4.2.2 and Section 5.1: expires-in = 1*DIGIT A.15. "username" Syntax The "username" element is defined in Section 4.3.2: username = *<TEXT excluding ":"> (This matches the "userid" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.16. "password" Syntax The "password" element is defined in Section 4.3.2: password = *TEXT (This matches the "password" definition in the HTTP Basic Authentication Scheme [RFC2617].) A.17. "refresh_token" Syntax The "refresh_token" element is defined in Section 5.1 and Section 6: refresh-token = b64token A.18. Endpoint Parameter Syntax The syntax for new endpoint parameters is defined in Section 8.2: param-name = 1*name-char name-char = "-" / "." / "_" / DIGIT / ALPHA
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
