Although what Nat is doing in this post is a little off topic, note that he does have an https URL as a client id which would be disallowed by the ABNF in A.1 below. Excluding ":" in client id definition makes sense when you consider that client ids will often be used as a userid in HTTP Basic but is that too restrictive in general?
On Sat, Jun 2, 2012 at 2:10 AM, Mike Jones <michael.jo...@microsoft.com>wrote: > 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
