Do we want to make expires_in not have zeroes? Or am I being to OCD on this?
-bill
>________________________________
> From: Mike Jones <michael.jo...@microsoft.com>
>To: Eran Hammer <e...@hueniverse.com>; "oauth@ietf.org" <oauth@ietf.org>
>Sent: Monday, June 4, 2012 3:10 PM
>Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review
>
>
>
>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:e...@hueniverse.com]
>Sent: Monday, June 04, 2012 12:17 PM
>To: Mike Jones; oauth@ietf.org
>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: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
