The OAuth 2.0 Authorization Framework
draft-ietf-oauth-v2-31

[Ballot discuss]
Revised (again) Updated based on -26.  There's just two remaining.

0) General: I found the lack of ABNF somewhat disconcerting in that implementers would have to hunt through the spec to figure out all the values of a given field.  For example grant_type has different values based on the different kind of access_token requests - four to be more precise - but there's no ABNF for the field.  There are many examples of this.  It would greatly aid implementers if a) the ABNF for all fields were included in the draft and b) all the ABNF was collected in one place.  I had individual discusses for each field that had missing ABNF, but it was getting out of hand so I'm just going to do this one general discuss on this topic.

Retaining this one because somebody ought to be able to get the ABNF collected.

10) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment is included:

  The endpoint URI MUST NOT include a fragment component.

The fragment is used to send back information to the client. Unlike query parameters, there is not well-establish practice of adding parameters to an existing fragment. If a fragment is included, it is likely to be dropped or incorrectly retained.

I wonder if this worth noting or whether this accepted/normal practice and you could just point to it?

I'll get back with some text or I'll drop this one.

[Ballot discuss]
Updated based on -26.  There's just three remaining.

0) General: I found the lack of ABNF somewhat disconcerting in that implementers would have to hunt through the spec to figure out all the values of a given field.  For example grant_type has different values based on the different kind of access_token requests - four to be more precise - but there's no ABNF for the field.  There are many examples of this.  It would greatly aid implementers if a) the ABNF for all fields were included in the draft and b) all the ABNF was collected in one place.  I had individual discusses for each field that had missing ABNF, but it was getting out of hand so I'm just going to do this one general discuss on this topic.

Retaining this one because somebody ought to be able to get the ABNF collected.

10) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment is included:

  The endpoint URI MUST NOT include a fragment component.

The fragment is used to send back information to the client. Unlike query parameters, there is not well-establish practice of adding parameters to an existing fragment. If a fragment is included, it is likely to be dropped or incorrectly retained.

I wonder if this worth noting or whether this accepted/normal practice and you could just point to it?

20) the bearer token spec contained character set restrictions on the error, error_description, and error_uri:

Values for the "error" and
"error_description" attributes MUST NOT include characters outside
the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri"
attribute MUST conform to the URI-Reference syntax, and thus MUST NOT
include characters outside the set %x21 / %x23-5B / %x5D-7E.

Do these apply here as well? This might get cleared up with some ABNF.

> No, because the bearer specification is limited to HTTP auth headers rules which do not specify an encoding for reserved character. OAuth uses formats with well specified encoding rules to allow any character.

Okay I think the chairs might need to weigh in on this one.

[Ballot discuss]
At v25, I appreciate that you must have slayed more than your fair share of dragons (and some more than once I bet).  I appreciate your efforts.  Just a couple of things I'd like to discuss:

0) General: I found the lack of ABNF somewhat disconcerting in that implementers would have to hunt through the spec to figure out all the values of a given field.  For example grant_type has different values based on the different kind of access_token requests - four to be more precise - but there's no ABNF for the field.  There are many examples of this.  It would greatly aid implementers if a) the ABNF for all fields were included in the draft and b) all the ABNF was collected in one place.  I had individual discusses for each field that had missing ABNF, but it was getting out of hand so I'm just going to do this one general discuss on this topic.

1) General: If I buy your argument in s1.7 that this is a framework and you can leave bits needed to fully implement it out, then should this draft not have "protocol" in the title or be tweaked to acknowledge it's not complete?  I can hear you all groaning now, but it's truth in advertising.  The other RFCs that have been oft quoted as frameworks, like PKIX and CMS, that would allow you to not pick MTI, like the token format, don't have "protocol" in the name.  Adding some like ": Framework" after the title so that it's clear this ain't the hole shooting match would, I think, be truth in advertising.  It's just a little misleading that the abstract/intro lead you to believe if you implement this draft you'll be access these resources but you have to dig in to s1.7 and s7 to know that the bits need to actually determine access aren't defined in the draft.

2) Figure 1: Because so many of the later sections refer to the not shown protocol flow I decided to make it a discuss (though I'm sure more than one person would say this is a comment):

  s1.2: Figure 1: If the preferred mechanism for the client request
  is to go indirectly through the Authorization Server it would be
  really good to depict that.  You could just add that to Figure 1 or
  add a Figure 2.

Further, shouldn't the out-of-scope bits also be shown too: client registration, and the interaction between the authorization and resource servers so we get the complete picture?  You can mark them out-of-scope in the figure.

And another thing, the bearer token picture shows client credentials in (C) shouldn't this also show them as optional?

3) s1.6/s2.3.1/s3.1: So some might consider this nit-picking but when you say "Whenever TLS is required by this specification" do you mean "Whenever this specification requires TLS be used"?  MTI doesn't mean mandatory to use, but in this case I think you do mean mandatory to use because it ships around cleartext passwords.  This also comes up in s2.3.1 and 3.1 where the text indicates:

  t/The authorization server MUST require TLS as described in Section
  1.6 when sending requests using password authentication.

I'd just replace require with use in both places.  Note that s3.1.2.1 seems to have it right: "require the use of TLS".

4) s1.7: When you say "authorization server capabilities" you're talking about the client discovering which token format is supported?  I think the draft needs to be clear that without these underdefined things that the protocol can only interop with the clients being configured a priori.

5) s1.7: Since you brought it up (and I thank you for being upfront about it) and you provided some examples, shouldn't the list of underdefined things be completely listed?  That way if somebody wants to profile this for their use they know all the bits and pieces they need to write down.

6) s2: The protocol to register the client is out-of-scope but is the directions for the client developer in scope?  If so, shouldn't 2119 language be used here:

When registering a client, the client developer:
- MUST specify the client type…
- SHOULD provide its client redirection …
- MUST include any other …

7) s2.1: How is trust established?

8) s2.2: How unique is the client_id?  Is it just for this server or universally unique?  If it's the later how do you guarantee this?  Is there some requirement for the length of the string?

9) s2.3.1: Where is this described:

Since this client authentication method involves a password, the
authorization server MUST protect any endpoint utilizing it against
brute force attacks.

10) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment is included:

  The endpoint URI MUST NOT include a fragment component.

11) s3.1/s3.2: What happens if they are included more than once - is it rejected or is the first one accepted?:

  Request and response parameters
  MUST NOT be included more than once.

12) s3.1.2.1: This section made me scratch my head a bit.  In which of the scenario's flows is the SHOULD for (i.e., where do you think TLS won't be implemented)?  Is it (D) in Figure 3?

13) s3.1.2.1: How does the authorization server warn the resource owner about the insecure endpoint?

14) s3.1.2.4/s4.1.2.1:  Under what circumstances wouldn't you inform the resource owner of the error (i.e., why isn't that SHOULD a MUST)?

15) s3.1.2.5: Are there any security considerations that would result if the client includes third-party scripts?

16) s3.1.2.5: How is this done:

If third-party
scripts are included, the client MUST ensure that its own scripts
(used to extract and remove the credentials from the URI) will
execute first.

17) s4.1.2.1/s4.2.2.1: The errors in these two sections have the same values but just slightly different meanings: one refers to authorization codes and the other refers to access tokens.  Is it wise to use the same name for the error values?  This issue would go away if the error_description was required.

18) s4.1.2/s4.1.2.1/s4.2.2/s4.2.2.1/: Don't you need to say which type of HTTP status code is returned e.g., is it always 302 as shown in the exampled?

19) How is the expiry time of the access token provided to the resource server?  Is this supposed to be documented in the access token documents?

20) the bearer token spec contained character set restrictions on the error, error_description, and error_uri:

Values for the "error" and
"error_description" attributes MUST NOT include characters outside
the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri"
attribute MUST conform to the URI-Reference syntax, and thus MUST NOT
include characters outside the set %x21 / %x23-5B / %x5D-7E.

Do these apply here as well? This might get cleared up with some ABNF.

21) s10.3: Given Richard's point in GEN-ART review on 10.3, I think it might be worth adding the text you suggested.

22) s10: About the parameters that require secure transmission/storage: Would a compromise be to just list the ones that require secure transmission/storage?  We often do/require this for protocols (e.g., SNMP, NETCONF).

[Ballot comment]
0) s2.1: Assume either you'll rev the draft of Stephen will add the text via an RFC editor note:

  A clients may be implemented as a distributed set of components, each
  with a different client type and security context (e.g. a distributed
  client with both a confidential server-based component and a public
  browser-based component). If the authorization  server does not
  provide support for such clients, or does not provide guidance with
  regard to their registration, the client SHOULD register each
  component as a separate client.

1) s1: r/created by passwords/inherent in passwords

2) s1: r/OAuth with any transport protocol other than HTTP is undefined./OAuth with any transport protocol other than HTTP is out-of-scope.

3) s1: General: Nice reference to RFC 4949 in s1.8, but that got me to wondering whether you should use the term "capability token" as opposed to "access token" where the definition of capability token is:

(I) A token (usually an unforgeable data object) that gives the
    bearer or holder the right to access a system resource. Possession
    of the token is accepted by a system as proof that the holder has
    been authorized to access the resource indicated by the token.

4) s1.5: r/Issuing a refresh token is optional/Issuing a refresh token is OPTIONAL ?

5) s1.5: r/If the authorization server issues a refresh token, it is included when issuing an access token./If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (D) in Figure 1).

6) s1.6: Did you mean that additional transport-layer *security* mechanisms can be implemented?

7) ID-nits is coughing on your 2119 paragraph.  Replace ' with " and it ought to go away.

8) really we're going to use: application/x-www-form-urlencoded

9) s3.1.2.2: add a period to the end of:prior to utilizing the authorization endpoint

10) s4.1.1.1/s4.1.2/s4.2.2/s5.1: SHOULD in the following:

The authorization server should document the size of
any value it issues

11) s5.2: 1st sentence indicates 400 is the response but in invalid_client it says might be a 401.  Should the 1st sentence use 4xx instead to indicate it's from the client error set of codes?

12) This might have been settled already: s11.4.1: A GEN-ART comment on the bearer token draft might have trigged a necessary change to the OAuth Extension Error Registry to allow bearer tokens errors to use the same registry.  Would need to add a fourth usage location:  "resource access error response" to be able to use this registry for bearer error types.

From Richard's GEN-ART review:

13) On redirects: I think it might help to add somewhere that redirects and directs can be accomplished through HTTP redirects or through other implementation alternatives.

14) s2.3.1: I think it would help to add something that says this is only used with Token Endpoint (3.2) which is limited to POST only.

[Ballot discuss]
At v25, I appreciate that you must have slayed more than your fair share of dragons (and some more than once I bet).  I appreciate your efforts.  Just a couple of things I'd like to discuss:

0) General: I found the lack of ABNF somewhat disconcerting in that implementers would have to hunt through the spec to figure out all the values of a given field.  For example grant_type has different values based on the different kind of access_token requests - four to be more precise - but there's no ABNF for the field.  There are many examples of this.  It would greatly aid implementers if a) the ABNF for all fields were included in the draft and b) all the ABNF was collected in one place.  I had individual discusses for each field that had missing ABNF, but it was getting out of hand so I'm just going to do this one general discuss on this topic.

1) General: If I buy your argument in s1.7 that this is a framework and you can leave bits needed to fully implement it out, then should this draft not have "protocol" in the title or be tweaked to acknowledge it's not complete?  I can hear you all groaning now, but it's truth in advertising.  The other RFCs that have been oft quoted as frameworks, like PKIX and CMS, that would allow you to not pick MTI, like the token format, don't have "protocol" in the name.  Adding some like ": Framework" after the title so that it's clear this ain't the hole shooting match would, I think, be truth in advertising.  It's just a little misleading that the abstract/intro lead you to believe if you implement this draft you'll be access these resources but you have to dig in to s1.7 and s7 to know that the bits need to actually determine access aren't defined in the draft.

2) Figure 1: Because so many of the later sections refer to the not shown protocol flow I decided to make it a discuss (though I'm sure more than one person would say this is a comment):

  s1.2: Figure 1: If the preferred mechanism for the client request
  is to go indirectly through the Authorization Server it would be
  really good to depict that.  You could just add that to Figure 1 or
  add a Figure 2.

Further, shouldn't the out-of-scope bits also be shown too: client registration, and the interaction between the authorization and resource servers so we get the complete picture?  You can mark them out-of-scope in the figure.

And another thing, the bearer token picture shows client credentials in (C) shouldn't this also show them as optional?

3) s1.6/s2.3.1/s3.1: So some might consider this nit-picking but when you say "Whenever TLS is required by this specification" do you mean "Whenever this specification requires TLS be used"?  MTI doesn't mean mandatory to use, but in this case I think you do mean mandatory to use because it ships around cleartext passwords.  This also comes up in s2.3.1 and 3.1 where the text indicates:

  t/The authorization server MUST require TLS as described in Section 1.6
  when sending requests using password authentication.

I'd just replace require with use in both places.  Note that s3.1.2.1 seems to have it right: "require the use of TLS".

4) s1.7: When you say "authorization server capabilities" you're talking about the client discovering which token format is supported?  I think the draft needs to be clear that without these underdefined things that the protocol can only interop with the clients being configured a priori.

5) s1.7: Since you brought it up (and I thank you for being upfront about it) and you provided some examples, shouldn't the list of underdefined things be completely listed?  That way if somebody wants to profile this for their use they know all the bits and pieces they need to write down.

6) s2: The protocol to register the client is out-of-scope but is the directions for the client developer in scope?  If so, shouldn't 2119 language be used here:

When registering a client, the client developer:
- MUST specify the client type…
- SHOULD provide its client redirection …
- MUST include any other …

7) s2.1: How is trust established?

8) s2.2: How unique is the client_id?  Is it just for this server or universally unique?  If it's the later how do you guarantee this?  Is there some requirement for the length of the string?

9) s2.3.1: Where is this described:

Since this client authentication method involves a password, the
authorization server MUST protect any endpoint utilizing it against
brute force attacks.

10) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment is included:

  The endpoint URI MUST NOT include a fragment component.

11) s3.1/s3.2: What happens if they are included more than once - is it rejected or is the first one accepted?:

  Request and response parameters
  MUST NOT be included more than once.

12) s3.1.2.1: This section made me scratch my head a bit.  In which of the scenario's flows is the SHOULD for (i.e., where do you think TLS won't be implemented)?  Is it (D) in Figure 3?

13) s3.1.2.1: How does the authorization server warn the resource owner about the insecure endpoint?

14) s3.1.2.4/s4.1.2.1:  Under what circumstances wouldn't you inform the resource owner of the error (i.e., why isn't that SHOULD a MUST)?

15) s3.1.2.5: Are there any security considerations that would result if the client includes third-party scripts?

16) s3.1.2.5: How is this done:

If third-party
scripts are included, the client MUST ensure that its own scripts
(used to extract and remove the credentials from the URI) will
execute first.

17) s4.1.2.1/s4.2.2.1: The errors in these two sections have the same values but just slightly different meanings: one refers to authorization codes and the other refers to access tokens.  Is it wise to use the same name for the error values?  This issue would go away if the error_description was required.

18) s4.1.2/s4.1.2.1/s4.2.2/s4.2.2.1/: Don't you need to say which type of HTTP status code is returned e.g., is it always 302 as shown in the exampled?

19) How is the expiry time of the access token provided to the resource server?  Is this supposed to be documented in the access token documents?

20) the bearer token spec contained character set restrictions on the error, error_description, and error_uri:

Values for the "error" and
"error_description" attributes MUST NOT include characters outside
the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri"
attribute MUST conform to the URI-Reference syntax, and thus MUST NOT
include characters outside the set %x21 / %x23-5B / %x5D-7E.

Do these apply here as well? This might get cleared up with some ABNF.

21) s10.3: Given Richard's point in GEN-ART review on 10.3, I think it might be worth adding the text you suggested.

22) s10: About the parameters that require secure transmission/storage: Would a compromise be to just list the ones that require secure transmission/storage?  We often do/require this for protocols (e.g., SNMP, NETCONF).

[Ballot discuss]
At v25, I appreciate that you must have slayed more than your fair share of dragons (and some more than once I bet).  I appreciate your efforts.  Just a couple of things I'd like to discuss:

Some general ones to start:

1) General: I found the lack of ABNF somewhat disconcerting in that implementers would have to hunt through the spec to figure out all the values of a given field.  For example grant_type has different values based on the different kind of access_token requests - four to be more precise - but there's no ABNF for the field.  There are many examples of this.  It would greatly aid implementers if a) the ABNF for all fields were included in the draft and b) all the ABNF was collected in one place.  I had individual discusses for each field that had missing ABNF, but it was getting out of hand so I'm just going to do this one general discuss on this topic.

2) General: If I buy your argument in s1.7 that this is a framework and you can leave bits needed to fully implement it out, then should this draft not have "protocol" in the title or be tweaked to acknowledge it's not complete?  I can hear you all groaning now, but it's truth in advertising.  The other RFCs that have been oft quoted as frameworks, like PKIX and CMS, that would allow you to not pick MTI, like the token format, don't have "protocol" in the name.  Adding some like ": Framework" after the title so that it's clear this ain't the hole shooting match would, I think, be truth in advertising.  It's just a little misleading that the abstract/intro lead you to believe if you implement this draft you'll be access these resources but you have to dig in to s1.7 and s7 to know that the bits need to actually determine access aren't defined in the draft.

3) Figure 1: Because so many of the later sections refer to the not shown protocol flow I decided to make it a discuss (though I'm sure more than one person would say this is a comment):

  s1.2: Figure 1: If the preferred mechanism for the client request
  is to go indirectly through the Authorization Server it would be
  really good to depict that.  You could just add that to Figure 1 or
  add a Figure 2.

Further, shouldn't the out-of-scope bits also be shown too: client registration, and the interaction between the authorization and resource servers so we get the complete picture?  You can mark them out-of-scope in the figure.

And another thing, the bearer token picture shows client credentials in (C) shouldn't this also show them as optional?

4) s1.6/s2.3.1/s3.1: So some might consider this nit-picking but when you say "Whenever TLS is required by this specification" do you mean "Whenever this specification requires TLS be used"?  MTI doesn't mean mandatory to use, but in this case I think you do mean mandatory to use because it ships around cleartext passwords.  This also comes up in s2.3.1 and 3.1 where the text indicates:

  t/The authorization server MUST require TLS as described in Section 1.6
  when sending requests using password authentication.

I'd just replace require with use in both places.  Note that s3.1.2.1 seems to have it right: "require the use of TLS".

5) s1.7: When you say "authorization server capabilities" you're talking about the client discovering which token format is supported?  I think the draft needs to be clear that without these underdefined things that the protocol can only interop with the clients being configured a priori.

6) s1.7: Since you brought it up (and I thank you for being upfront about it) and you provided some examples, shouldn't the list of underdefined things be completely listed?  That way if somebody wants to profile this for their use they know all the bits and pieces they need to write down.

7) s2: The protocol to register the client is out-of-scope but is the directions for the client developer in scope?  If so, shouldn't 2119 language be used here:

When registering a client, the client developer:
- MUST specify the client type…
- SHOULD provide its client redirection …
- MUST include any other …

8) s2.1: How is trust established?

9) s2.2: How unique is the client_id?  Is it just for this server or universally unique?  If it's the later how do you guarantee this?  Is there some requirement for the length of the string?

10) s2.3.1: Where is this described:

Since this client authentication method involves a password, the
authorization server MUST protect any endpoint utilizing it against
brute force attacks.

11) s3.1/s3.1.2/s3.2/etc.: why the MUST NOT here and what happens if a fragment is included:

  The endpoint URI MUST NOT include a fragment component.

12) s3.1/s3.2: What happens if they are included more than once - is it rejected or is the first one accepted?:

  Request and response parameters
  MUST NOT be included more than once.

13) s3.1.2.1: This section made me scratch my head a bit.  In which of the scenario's flows is the SHOULD for (i.e., where do you think TLS won't be implemented)?  Is it (D) in Figure 3?

14) s3.1.2.1: How does the authorization server warn the resource owner about the insecure endpoint?

15) s3.1.2.4/s4.1.2.1:  Under what circumstances wouldn't you inform the resource owner of the error (i.e., why isn't that SHOULD a MUST)?

16) s3.1.2.5: Are there any security considerations that would result if the client includes third-party scripts?

17) s3.1.2.5: How is this done:

If third-party
scripts are included, the client MUST ensure that its own scripts
(used to extract and remove the credentials from the URI) will
execute first.

18) s4.1.2.1/s4.2.2.1: The errors in these two sections have the same values but just slightly different meanings: one refers to authorization codes and the other refers to access tokens.  Is it wise to use the same name for the error values?  This issue would go away if the error_description was required.

19) s4.1.2/s4.1.2.1/s4.2.2/s4.2.2.1/: Don't you need to say which type of HTTP status code is returned e.g., is it always 302 as shown in the exampled?

20) How is the expiry time of the access token provided to the resource server?  Is this supposed to be documented in the access token documents?

21) the bearer token spec contained character set restrictions on the error, error_description, and error_uri:

Values for the "error" and
"error_description" attributes MUST NOT include characters outside
the set %x20-21 / %x23-5B / %x5D-7E. Values for the "error_uri"
attribute MUST conform to the URI-Reference syntax, and thus MUST NOT
include characters outside the set %x21 / %x23-5B / %x5D-7E.

Do these apply here as well? This might get cleared up with some ABNF.

22) s10.3: Given Richard's point in GEN-ART review on 10.3, I think it might be worth adding the text you suggested.

23) s10: About the parameters that require secure transmission/storage: Would a compromise be to just list the ones that require secure transmission/storage?  We often do/require this for protocols (e.g., SNMP, NETCONF).

[Ballot comment]
0) s2.1: Assume either you'll rev the draft of Stephen will add the text via an RFC editor note:

  A clients may be implemented as a distributed set of components, each
  with a different client type and security context (e.g. a distributed
  client with both a confidential server-based component and a public
  browser-based component). If the authorization  server does not
  provide support for such clients, or does not provide guidance with
  regard to their registration, the client SHOULD register each component
  as a separate client.

1) s1: r/created by passwords/inherent in passwords

2) s1: r/OAuth with any transport protocol other than HTTP is undefined./OAuth with any transport protocol other than HTTP is out-of-scope.

3) s1: General: Nice reference to RFC 4949 in s1.8, but that got me to wondering whether you should use the term "capability token" as opposed to "access token" where the definition of capability token is:

(I) A token (usually an unforgeable data object) that gives the
    bearer or holder the right to access a system resource. Possession
    of the token is accepted by a system as proof that the holder has
    been authorized to access the resource indicated by the token.

4) s1.5: r/Issuing a refresh token is optional/Issuing a refresh token is OPTIONAL ?

5) s1.5: r/If the authorization server issues a refresh token, it is included when issuing an access token./If the authorization server issues a refresh token, it is included when issuing an access token (i.e., step (D) in Figure 1).

6) s1.6: Did you mean that additional transport-layer *security* mechanisms can be implemented?

7) ID-nits is coughing on your 2119 paragraph.  Replace ' with " and it ought to go away.

8) really we're going to use: application/x-www-form-urlencoded

9) s3.1.2.2: add a period to the end of:prior to utilizing the authorization endpoint

10) s4.1.1.1/s4.1.2/s4.2.2/s5.1: SHOULD in the following:

The authorization server should document the size of
any value it issues

11) s5.2: 1st sentence indicates 400 is the response but in invalid_client it says might be a 401.  Should the 1st sentence use 4xx instead to indicate it's from the client error set of codes?

12) This might have been settled already: s11.4.1: A GEN-ART comment on the bearer token draft might have trigged a necessary change to the OAuth Extension Error Registry to allow bearer tokens errors to use the same registry.  Would need to add a fourth usage location:  "resource access error response" to be able to use this registry for bearer error types.

From Richard's GEN-ART review:

13) On redirects: I think it might help to add somewhere that redirects and directs can be accomplished through HTTP redirects or through other implementation alternatives.

14) s2.3.1: I think it would help to add something that says this is only used with Token Endpoint (3.2) which is limited to POST only.

[Ballot discuss]
I should like to see a statement along the lines of "OAuth 2.0 is not
intended to be backward compatible with OAuth 1.0. The protocol versions
may co-exist in the network and implementations may chhose to support
both. However, it is the intention of this document that new
implementation support OAuth 2.0 as specified in this document, and that
OAuth 1.0 is used only to support existing deployed implementations."

---

It would be useful to include a concise section titled "Changes from
OAuth 1.0 (RFC 5849)". This would help implementers moving from 1.0 to
2.0 (and would help reviewers as well :-)

[Ballot comment]
4.3.2 says that the authorization server MUST "validate the resource owner password credentials", but it doesn't say exactly how one might do that. For example, it doesn't say whether to compare things case-sensitively or (and this is the reason it even occurred to me) whether one should be normalizing the UTF-8. I'm fine with that being left as an exercise to the reader if this is the common practice in security protocols. And UTF-8 doesn't make this special; even comparing US-ASCII has it's quirks. The UTF-8 just made it noticable to me.

8: Just confirming that you are OK with the following legal ABNF productions:

type-name and param-name could each be "...---..."
response-name could be "_____"
error-code could be "z...---..."

Those all OK productions?

[Ballot comment]
I came to a similar conclusion as Benoit: readers of this
document would benefit from a one-paragraph summary
of the reasons for the development of Oauth 2.0.  A summary
or overview of technical differences would be helpful,
as well, if it's not too lengthy.

I also agree with Stewart's DISCUSS regarding the adoption
of modified RFC 5226 review processes rather than reusing
existing processes.

[Ballot comment]
I came to a similar conclusion to Benoit's: readers of this
document would benefit from a one-paragraph summary
of the reasons for the development of Oauth 2.0.  A summary
or overview of technical differences would be helpful,
as well, if it's not too lengthy.

I also agree with Stewart's DISCUSS regarding the adoption
of modified RFC 5226 review processes rather than reusing
existing processes.

[Ballot comment]
I read:
  This specification replaces and obsoletes the OAuth 1.0 protocol described
  in RFC 5849.

I've not been familiar with OAuth, and one question that bothered me: Why should I implement/upgrade to OAuth 2.0, compared to 1.0? It's not mentioned in the draft. I had to search somewhere to find the answer: in the current charter, which says:

  In April 2010 the OAuth 1.0 specification, documenting pre-IETF work,
  was published as an informational document (RFC 5849). The working
  group has since been developing OAuth 2.0, a standards-track version
  that will reflect IETF consensus.  Version 2.0 will consider the
  implementation experience with version 1.0, a discovered security
  vulnerability (session fixation attack), the use cases and
  functionality proposed with OAuth WRAP [draft-hardt-oauth-01] and will
  * improve the terminology used,
  * consider broader use cases,
  * embody good security practices,
  * improve interoperability, and
  * provide guidelines for extensibility.


Adding at least the first two sentences (or something similar) + one about the "discovered security vulnerability" would make sense, at least to me... Unless this specified in a different document (maybe I-D.ietf-oauth-v2-threatmodel?)

[Ballot discuss]
It is not clear to me why it is necessary to create the protocol specific variant of the RFC5226 Review process described in section 11.1, 11.2, 11.3, 11.4.

Creating new variants of the IANA process creates confusion, and unless there is a good reason specific to this protocol, one of the standard IANA processes should be called out.

If the plan is to have a list review followed by an expert review of the list discussion, the timetable needs to call out time for the list to do a review and then a time for the expert to do their review.

[Ballot comment]
In section 1, right before 1.1 begins, HTTP is called a transport protocol.  While this tends to happen, it still isn't correct.  It would be better to reword the sentence replacing:
"with any other transport protocol"
to something more like:
"over any other protocol"

Upon approval of this document, IANA will perform the following actions
(note that "Specification Required" implies use of a designated expert):

ACTION 1:

IANA will create the following registry:

Registry Name: OAuth Access Token Types
Reference: [this document]
Registration Procedures: Specification Required

No initial registrations.


ACTION 2:

IANA will create the following registry:

Registry Name: OAuth Parameters
Reference: [this document]
Registration Procedures: Specification Required

o Parameter name: client_id
o Parameter usage location: authorization request, token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: client_secret
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: response_type
o Parameter usage location: authorization request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: redirect_uri
o Parameter usage location: authorization request, token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: scope
o Parameter usage location: authorization request, authorization
response, token request, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: state
o Parameter usage location: authorization request, authorization
response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: code
o Parameter usage location: authorization response, token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: error_description
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: error_uri
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: grant_type
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: access_token
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: token_type
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: expires_in
o Parameter usage location: authorization response, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: username
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: password
o Parameter usage location: token request
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Parameter name: refresh_token
o Parameter usage location: token request, token response
o Change controller: IETF
o Specification document(s): [[ this document ]]


ACTION 3:

IANA will create the following registry:

Registry Name: OAuth Authorization Endpoint Response Types
Reference: [this document]
Registration Procedures: Specification Required

o Response type name: code
o Change controller: IETF
o Specification document(s): [[ this document ]]

o Response type name: token
o Change controller: IETF
o Specification document(s): [[ this document ]]


ACTION 4:

IANA will create the following registry:

Registry Name: OAuth Extensions Errors
Reference: [this document]
Registration Procedures: Specification Required

No initial registrations.

State changed to In Last Call from In Last Call.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: REVISED Last Call:  (The OAuth 2.0 Authorization Protocol) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-07. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The OAuth 2.0 authorization protocol enables a third-party
  application to obtain limited access to an HTTP service, either on
  behalf of a resource owner by orchestrating an approval interaction
  between the resource owner and the HTTP service, or by allowing the
  third-party application to obtain access on its own behalf.  This
  specification replaces and obsoletes the OAuth 1.0 protocol described
  in RFC 5849.

There are a few downrefs to note:

* There is a normative reference to RFC 1750, which will be updated to
point to RFC 4086 before publication.

* There is a normative reference to RFC 2246 (TLS 1.0), which has been
obsoleted by RFC 5246 (TLS 1.2).  The document uses this reference to
note that TLS 1.0 is, at this writing, the most widely deployed
version.  The working group believes it is necessary to note that, and
that the reference be normative.

* There is a normative reference to Informational RFC 2818 (HTTP over
TLS). This is an allowed downref.

* There is a normative reference to Informational RFC 4627
(application/json Media Type). This is an allowed downref.


* There is a normative reference to Informational RFC 4949 (Internet
Security Glossary).  This is an allowed downref.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/


No IPR declarations have been submitted directly on this I-D.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Last Call:  (The OAuth 2.0 Authorization Protocol) to Proposed Standard


The IESG has received a request from the Web Authorization Protocol WG
(oauth) to consider the following document:
- 'The OAuth 2.0 Authorization Protocol'
  as a Proposed Standard

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2012-02-06. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

Abstract


  The OAuth 2.0 authorization protocol enables a third-party
  application to obtain limited access to an HTTP service, either on
  behalf of a resource owner by orchestrating an approval interaction
  between the resource owner and the HTTP service, or by allowing the
  third-party application to obtain access on its own behalf.  This
  specification replaces and obsoletes the OAuth 1.0 protocol described
  in RFC 5849.




The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-oauth-v2/


No IPR declarations have been submitted directly on this I-D.