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

Reply via email to