The main point of my message was to point out that the working group has not
discussed the syntax for some the elements identified. I'm glad that it now is.
Actually, the draft already contains or implies syntax restrictions for more
fields than you listed, Eran. Let me tackle each field individually and
provide rationale for the choice made and solicit working group input on those
where I believe there are open issues.
We already had syntax restrictions in place for error, error_description,
error_uri, scope, and response_type so I won't discuss those further.
The spec already included a syntax for token_type, and the ABNF doesn't deviate
from it. The grant_type element is logically the same kind of object as
token_type, so it makes sense to use the same syntax.
I don't see a case for having expires_in contain anything but 1*DIGIT, so I
don't see that as being controversial.
For redirect_uri, since it is a URI, I believe that URI-reference makes sense.
For username and password, the spec mandates that they be used with HTTP Basic,
thus implicitly restricting their legal values. (Per my earlier response to
Julian, RFC 2616 effectively limits these characters to be the ISO-8859-1
characters other than control characters but including LWS characters.) HTTP
Basic further restricts the username field to not contain a colon (':'). In
short, I believe that the OAuth core already implicitly contains the specified
character set restrictions.
Since client_id and client_secret are parallel to username and password, it
would be inconsistent to use different character set restrictions for them.
(On the other hand, Brian Campbell referenced a case where a client_id might be
a URL, in which case colon would be required. That seems like a reasonable
usage, so the syntax restriction on client_id probably needs to be relaxed. WG
thoughts on the correct syntax? Should it just be TEXT?)
That leaves state, code, access_token, and refresh_token as the remaining
elements that genuinely need working group discussion. The ABNF currently
restricts these to character sets that don't require encodings. Should it, or
like client_id, should we likely expand the sets? If so, is TEXT with
ISO-8859-1 encoding the right ABNF definition for them, given that they can all
be used in contexts where MIME encodings aren't specified?
Thanks all,
-- Mike
From: Eran Hammer [mailto:[email protected]]
Sent: Monday, June 04, 2012 12:17 PM
To: Mike Jones; [email protected]
Subject: RE: ABNF elements for suggested WG review
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]>
[mailto:[email protected]]<mailto:[mailto:[email protected]]> On
Behalf Of Mike Jones
Sent: Saturday, June 02, 2012 1:10 AM
To: [email protected]<mailto:[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
