We've definitely needed full ABNF, this is good. I don't like the habit of multiple definitions for the same character sets though. Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used.
>________________________________ > From: Mike Jones <michael.jo...@microsoft.com> >To: "oauth@ietf.org" <oauth@ietf.org> >Sent: Saturday, June 2, 2012 1:10 AM >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 >OAuth@ietf.org >https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
