Hi Brian,
I don't think I followed your message completely. What it is that Nat wrote
that you were referring to?
Thanks,
-- Mike
From: Brian Campbell [mailto:bcampb...@pingidentity.com]
Sent: Monday, June 04, 2012 11:17 AM
To: Mike Jones
Cc: oauth@ietf.org
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review
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<mailto: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<http://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<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
