Agreed with Eran, there shouldn't be restrictions on most of these
fields. Though it should address Julian's request of how do you define
encoding on these fields explicitly.
-- Justin
On 06/04/2012 03:16 PM, Eran Hammer wrote:
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:*oauth-boun...@ietf.org [mailto:oauth-boun...@ietf.org] *On
Behalf Of *Mike Jones
*Sent:* Saturday, June 02, 2012 1:10 AM
*To:* oauth@ietf.org
*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
