Subject: [OAUTH-WG] ABNF elements for suggested WG review

From: Mike Jones <[email-masked]>
Date: Sat, 2 Jun 2012 08:10:23 +0000

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

---

From: William Mills <[email-masked]>
Date: Sat, 2 Jun 2012 08:52:56 -0700 (PDT)

We've definitely needed full ABNF, this is good.  I don't like the habit of multiple definitions for the same character sets though.  Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used.

>________________________________
> From: Mike Jones <[email-masked]>
>To: "[email-masked]" <[email-masked]> 
>Sent: Saturday, June 2, 2012 1:10 AM
>Subject: [OAUTH-WG] ABNF elements for suggested WG review
> 
>
> 
>Dear working group,
> 
>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).
> 
>_______________________________________________
>OAuth mailing list
>[email-masked]
>https://www.ietf.org/mailman/listinfo/oauth
>
>
>

---

From: Julian Reschke <[email-masked]>
Date: Sat, 02 Jun 2012 19:55:16 +0200

On 2012-06-02 10:10, Mike Jones 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
>

TEXT is defined in RFC 2616 as

     TEXT           = <any OCTET except CTLs,
                      but including LWS>

and

     OCTET          = <any 8-bit sequence of data>

So what character encoding do you use? Possible answers are "it 
depends", "ISO-8859-1", and "UTF-8".

The same comment applies to everything else using TEXT..

> Section 4.1.3, and Section 4.2.1:

Are you sure that this is not a URI-reference???

> ...

Best regards, Julian

---

From: Barry Leiba <[email-masked]>
Date: Sat, 2 Jun 2012 18:39:55 -0400

> Things like "%x21 / %x23-5B / %x5D-7E" should be named once and re-used.

An excellent suggestion, and one I hope is adopted.

Barry

---

From: Mike Jones <[email-masked]>
Date: Sun, 3 Jun 2012 02:03:01 +0000

Yep - on my to-do list.  I'll publish an updated version after giving people a few days to discuss.

				Cheers,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Barry Leiba
Sent: Saturday, June 02, 2012 3:40 PM
To: William Mills
Cc: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review

Barry

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Jun 2012 12:16:34 -0600

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 <[email-masked]>wrote:

>  Dear working group,****
> ** **
> 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****
>
> ** **
>
> ** **
>

---

From: Eran Hammer <[email-masked]>
Date: Mon, 4 Jun 2012 19:16:42 +0000

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-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Saturday, June 02, 2012 1:10 AM
To: [email-masked]
Subject: [OAUTH-WG] ABNF elements for suggested WG review

Dear working group,

                                                            -- Mike

A.1.  "client_id" Syntax

   client-secret = *TEXT

A.4.  "scope" Syntax

A.5.  "state" Syntax

   state      = 1*unreserved

   redirect-uri      = URI

A.7.  "error" Syntax

   error             = 1*error-char

A.9.  "error_uri" Syntax

   error-uri         = URI

A.11.  "code" Syntax

   code       = 1*unreserved

   access-token = b64token

   expires-in = 1*DIGIT

A.15.  "username" Syntax

A.16.  "password" Syntax

   password = *TEXT

   refresh-token = b64token

   param-name = 1*name-char

---

From: Justin Richer <[email-masked]>
Date: Mon, 4 Jun 2012 15:32:44 -0400

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:[email-masked] [mailto:[email-masked]] *On 
> Behalf Of *Mike Jones
> *Sent:* Saturday, June 02, 2012 1:10 AM
> *To:* [email-masked]
> *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.
>
> 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

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2012 21:56:15 +0000

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:[email-masked]]
Sent: Monday, June 04, 2012 11:17 AM
To: Mike Jones
Cc: [email-masked]
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 <[email-masked]<mailto:[email-masked]>> wrote:
Dear working group,

                                                            -- Mike

A.1.  "client_id" Syntax

   client-secret = *TEXT

A.4.  "scope" Syntax

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

   redirect-uri      = URI

A.7.  "error" Syntax

   error             = 1*error-char

A.9.  "error_uri" Syntax

   error-uri         = URI

A.11.  "code" Syntax

   code       = 1*unreserved

   access-token = b64token

   expires-in = 1*DIGIT

A.15.  "username" Syntax

A.16.  "password" Syntax

   password = *TEXT

   refresh-token = b64token

   param-name = 1*name-char

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2012 22:03:52 +0000

RFC 2616 contains this restriction for the contents of TEXT fields:

   Words of *TEXT MAY contain characters from character sets other than
   ISO-8859-1 [22] only when encoded according to the rules of
   RFC 2047 [14].

Therefore, I believe that for the elements using TEXT, the encoding must be specified as ISO-8859-1, since they are not always used in contexts where MIME encoding rules can be specified.

Yes, I believe you're correct that "URI" should be "URI-reference".

I'll make both of these changes.

				Thanks,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Saturday, June 02, 2012 10:55 AM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review

and

So what character encoding do you use? Possible answers are "it depends", "ISO-8859-1", and "UTF-8".

Best regards, Julian

---

From: Brian Campbell <[email-masked]>
Date: Mon, 4 Jun 2012 16:04:15 -0600

Wow, sorry. I had a link ready to past into that message but apparently I
never actually did it. My mistake.

http://nat.sakimura.org/2012/04/15/openid-connect-idp-on-iphone/ is the
post I'd intended to link where Nat was talking about an OpenID Connect IdP
on iPhone. In the JSON in part 1 he's got,

  "client_id": "https://example.com/",

which, if I understand correctly, wouldn't be a legal client id per the
proposed ABNF?

On Mon, Jun 4, 2012 at 3:56 PM, Mike Jones <[email-masked]>wrote:

>  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:[email-masked]]
> *Sent:* Monday, June 04, 2012 11:17 AM
> *To:* Mike Jones
> *Cc:* [email-masked]
> *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 <[email-masked]>
> wrote:****
>
> Dear working group,****
>
>  ****
>
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
>  ****
> https://www.ietf.org/mailman/listinfo/oauth****
>
> ** **
>

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2012 22:10:38 +0000

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-masked]]
Sent: Monday, June 04, 2012 12:17 PM
To: Mike Jones; [email-masked]
Subject: RE: ABNF elements for suggested WG review

EH

From: [email-masked]<mailto:[email-masked]> [mailto:[email-masked]]<mailto:[mailto:[email-masked]]> On Behalf Of Mike Jones
Sent: Saturday, June 02, 2012 1:10 AM
To: [email-masked]<mailto:[email-masked]>
Subject: [OAUTH-WG] ABNF elements for suggested WG review

Dear working group,

                                                            -- Mike

A.1.  "client_id" Syntax

   client-secret = *TEXT

A.4.  "scope" Syntax

A.5.  "state" Syntax

   state      = 1*unreserved

   redirect-uri      = URI

A.7.  "error" Syntax

   error             = 1*error-char

A.9.  "error_uri" Syntax

   error-uri         = URI

A.11.  "code" Syntax

   code       = 1*unreserved

   access-token = b64token

   expires-in = 1*DIGIT

A.15.  "username" Syntax

A.16.  "password" Syntax

   password = *TEXT

   refresh-token = b64token

   param-name = 1*name-char

---

From: William Mills <[email-masked]>
Date: Mon, 4 Jun 2012 15:24:41 -0700 (PDT)

Do we want to make expires_in not have zeroes?  Or am I being to OCD on this?

-bill

>To: Eran Hammer <[email-masked]>; "[email-masked]" <[email-masked]> 
>Sent: Monday, June 4, 2012 3:10 PM
>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.
> 
>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 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.
> 
>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-masked]] 
>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-masked] [mailto:[email-masked]] On Behalf Of Mike Jones

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jun 2012 00:36:44 +0200

>     ISO-8859-1 [22] only when encoded according to the rules of

TEXT is gone in httpbis.

> Therefore, I believe that for the elements using TEXT, the encoding must be specified as ISO-8859-1, since they are not always used in contexts where MIME encoding rules can be specified.

Again, the TEXT rule was only applicable while talking about 
octets-on-the-wire. It wasn't used to define sequences of characters. 
You will have to consider where the ABNF is used. Defining new protocol 
elements that are constrained to ISO-8859-1 definitively will be a problem.

And anyway, it's gone from the spec.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2012 22:40:51 +0000

OAuth Core doesn't use HTTPbis.  Many of these parameters are often used as URI query parameters, so whatever encodings are specified must work there.  What syntax and encodings would you suggest for the OAuth Core parameters that need to work with HTTP Basic as specified in RFC 2617?

Other suggestions are welcome as well.

				Thanks,
				-- Mike

-----Original Message-----
From: Julian Reschke [mailto:[email-masked]] 
Sent: Monday, June 04, 2012 3:37 PM
To: Mike Jones
Cc: [email-masked]
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review

TEXT is gone in httpbis.

> Therefore, I believe that for the elements using TEXT, the encoding must be specified as ISO-8859-1, since they are not always used in contexts where MIME encoding rules can be specified.

Again, the TEXT rule was only applicable while talking about octets-on-the-wire. It wasn't used to define sequences of characters. 
You will have to consider where the ABNF is used. Defining new protocol elements that are constrained to ISO-8859-1 definitively will be a problem.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jun 2012 00:42:18 +0200

On 2012-06-05 00:10, Mike Jones wrote:
> 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.

RFC 2617 is very vague on this, and implementations disagree.

> 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?)

No, please forget about TEXT. It's gone from HTTP-

If you define new protocol elements, either restrict them to US-ASCII, 
or find a way to encode all of Unicode. Restricting to ISO-8859-1 is a 
non-starter.

Best regards, Julian

---

From: Peter Saint-Andre <[email-masked]>
Date: Mon, 04 Jun 2012 16:43:21 -0600

> or find a way to encode all of Unicode. Restricting to ISO-8859-1 is a

+1 to that.

Peter

-- 
Peter Saint-Andre
https://stpeter.im/

---

From: Mike Jones <[email-masked]>
Date: Mon, 4 Jun 2012 22:46:29 +0000

Is there an existing ABNF element already defined that both of you would suggest that we use instead of TEXT?  For instance, is there one that allows all printable and horizontal whitespace ASCII characters?  And one that allows all printable and horizontal whitespace Unicode characters?

Expert advice explicitly solicited. :-)  I'd like us not to break new ground here...

				Thanks,
				-- Mike

-----Original Message-----
From: Peter Saint-Andre [mailto:[email-masked]] 
Sent: Monday, June 04, 2012 3:43 PM
To: Julian Reschke
Cc: Mike Jones; [email-masked]
Subject: Re: [OAUTH-WG] ABNF elements for suggested WG review

On 6/4/12 4:42 PM, Julian Reschke wrote:
>> 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?)
> 

+1 to that.

Peter

--
Peter Saint-Andre
https://stpeter.im/

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jun 2012 00:49:16 +0200

> Other suggestions are welcome as well.

URI query parameters are all US-ASCII by definition.

The interesting question is whether you define something abstract (and 
then describe the mapping to protocol elements) or not.

In the first case, you need to define in terms of *code points*, not 
*octets*, and then specify the encoding into, for instance, URI query 
parameters (such as: UTF-8-encode then percent-escape).

It's unfortunate that HTTP Basic is broken with respect to I18N, please 
don't add new stuff to this mess (-> 
<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>).

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Tue, 05 Jun 2012 09:15:48 +0200

> Is there an existing ABNF element already defined that both of you would suggest that we use instead of TEXT?  For instance, is there one that allows all printable and horizontal whitespace ASCII c…

RFC 5234 defines VCHAR 
(<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>).

For code-point-based ABNF productions, you may want to look at 
<http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>.

Best regards, Julian

---

From: William Mills <[email-masked]>
Date: Tue, 5 Jun 2012 08:34:15 -0700 (PDT)

wrong link for 5234...  http://tools.ietf.org/html/rfc5234

> From: Julian Reschke <[email-masked]>
>To: Mike Jones <[email-masked]> 
>Cc: "[email-masked]" <[email-masked]> 
>Sent: Tuesday, June 5, 2012 12:15 AM
>RFC 5234 defines VCHAR (<http://greenbytes.de/tech/webdav/draft-reschke-basicauth-enc-latest.html>).
>
>For code-point-based ABNF productions, you may want to look at <http://greenbytes.de/tech/webdav/rfc5323.html#rfc.section.5.15.1>.
>
>