Subject: [OAUTH-WG] draft-ietf-oauth-v2-18

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 8 Jul 2011 12:46:01 -0700

Published draft-ietf-oauth-v2-18.

This was a much larger effort than I was previously expecting or planning. Review requires reading the full text as the number of changes makes using a diff tool impractical. Below is the mostly complete list of changes. The new draft should include very few normative changes requiring changes to existing code (at least that was the intention).

*** Please do not reply to this thread but instead start new threads per issue to make discussion easier.

List of open issues:

* Consensus for new Client Registration section (2)
* Consensus for revised Redirection URI section (3.1.2)
* Consensus for new token endpoint Client Authentication section (3.2.1)
* Consensus for new authorization endpoint response type extensibility (8.4)
* Missing example from security section 10.4 Refresh Tokens
* Missing reference to DOM variable example in section 10.12 Cross-Site Request Forgery
* Need editing for 10.13 Clickjacking to better align with the protocol terminology, missing reference for x-frame-options header

(This is the complete list. If you have an issue not listed you must raise it again as it is not being tracked.)

Changes from -16:

* Many editorial changes, typos, and clarifications.
* Replaced end-user with resource owner anywhere were the term was referring to the official role. End-user is only used for casual references to people.
* Replaced computer with device.
* Replaced duration with lifetime.
* Expanded TOS to three levels deep.
* Replaced client credentials with client authentication as a general term.
* Replaced secrets with credentials as a general term.
* Removed definition of refresh token as a self-encoded credential.
* Removed client credentials as a distinct object in diagrams, kept explicit authentication language in diagram text.
* Removed document structure section in introduction.
* Added new Client Registration section, folded previous Client Authentication section into it.
* Forbid including a fragment component in authorization endpoint URIs.
* Significantly expanded the Redirection URI section, added discussion about URI matching, multiple registered URIs, and including of third-party scripts in landing page.
* Added requirement to register redirection URIs for all public clients, and for all usage of the implicit grant.
* Added recommendation to register the entire redirection URI.
* Added discussion of the reasons and requirements of client authentication when using the token endpoint.
* Adjusted grant type introductions from 'suitable' to 'optimize' to better align with other use cases.
* Changed redirect_uri to OPTIONAL (was implicitly already).
* Added requirement to expire the authorization code and recommended 10 minutes lifetime.
* Changed language from 'MAY' to 'SHOULD attempt' regarding revoking access tokens issued via a compromised authorization code.
* Replaced example tokens with 22 character strings
* Added state parameter to examples
* Removed client_id from the various sections describing the token endpoints, moved back to the client password credentials section.
* Removed error extensibility using HTTP status codes, added new error codes: server_error and temporarily_unavailable.
* Clarified error_description and error_uri as used for debugging only.
* Changed implicit grant type 'Web server with client resource' to 'Web-hosted client resource' to reduce confusion with other servers.
* Fixed various typos in scope definitions.
* Added note about user-agent support for fragments in redirection Location headers.
* Added note to resource owner password credentials grant type about brute force attacks.
* Clarified that the client credentials grant type applies to other forms of client authentications (not just via credentials).
* Added recommendation not to issue refresh tokens when using client credentials grant.
* Added charset=UTF-8 to all content-type header examples.
* Added 'Pragma: no-cache' to credential responses.
* Added requirement to authenticate the client when refreshing tokens for private clients.
* Clarified that new refresh tokens must have the same scope as the one used to make the refresh request.
* Added response type extensibility and registry for the authorization endpoint, added special designation for the '+' character in response type names (no parsing).
* New native applications section text.
* Cleanup of security considerations text, moving some normative requirements to previous sections.
* Added reference to RFC 4949.
* Added reference to RFC 2818.
* Rearranged the order of sections in security considerations.
* Imported phishing text from OAuth 1.0 RFC.
* Added CSRF and Clickjacking sections.
* Removed empty Redirection URI Validation section in security considerations.

EHL

---

From: Barry Leiba <[email-masked]>
Date: Sat, 9 Jul 2011 09:21:59 -0400

> * Need editing for 10.13 Clickjacking to better align with the protocol terminology,
>   missing reference for x-frame-options header
>

I have put this list into the datatracker:
http://trac.tools.ietf.org/wg/oauth/trac/report/1

Please let me know as they get resolved, so I can update it.  Also, if
you open new threads for new issues, please make it clear that you're
asking for a new issue to be created.

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Sat, 9 Jul 2011 08:02:24 -0700

We probably need some help from the chairs to close 15-18. Maybe make an official request for feedback with a deadline?

EHL

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf
> Of Barry Leiba
> Sent: Saturday, July 09, 2011 6:22 AM
> To: OAuth WG
> Subject: Re: [OAUTH-WG] draft-ietf-oauth-v2-18
> 
> > List of open issues:
> >
> > (This is the complete list. If you have an issue not listed you must
> > raise it again as it is not being tracked.)
> 
> Please let me know as they get resolved, so I can update it.  Also, if you open
> new threads for new issues, please make it clear that you're asking for a new
> issue to be created.
> 
> Barry, as chair
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Barry Leiba <[email-masked]>
Date: Fri, 15 Jul 2011 10:36:42 -0400

>> * Consensus for new authorization endpoint response type extensibility (8.4)

These issues have been open for almost a week -- they're issues 15
thru 18 in the tracker:
   http://trac.tools.ietf.org/wg/oauth/trac/report/1

There's already text in draft-ietf-oauth-v2-18 for them, marked as
"pending consensus", so we have only to confirm that the text is
acceptable to the working group.  There's been no discussion of that
text that I've seen, and I take that to mean that what's there looks
good.

We'll give it another few days, and take silence to mean assent.  In
other words, if anyone has problems with the "pending consensus" text,
please start a new thread about it, and put the issue number in the
subject line ("Subject: Issue 15, new client registration", for
example).  Barring objections by this coming Tuesday afternoon (19
July), I will close issues 15 thru 18.

As soon as we get resolutions for issues 19 thru 21, we'd like to
start working group last call on draft-ietf-oauth-v2.  So let's get
all the issues sorted out as soon as we can, and move this document
ahead.

Barry, as chair

---

From: Eran Hammer-Lahav <[email-masked]>
Date: Fri, 15 Jul 2011 08:03:06 -0700

Issue 18 did raise some comments. The feedback was that the parameter value should be changed from a simple string to a space-delimited list of values. 5 people expressed support with 2 (myself included) expressed concern about this change. I would be great if others would take 10 minutes to study it and join the conversation (the thread is 'defining new response types').

Issues 15-17 are not trivial changes and I would really like to see some comments about them, even if just of support.

EHL

> Sent: Friday, July 15, 2011 7:37 AM
> To: OAuth WG
> These issues have been open for almost a week -- they're issues 15 thru 18 in
> the tracker:
> There's already text in draft-ietf-oauth-v2-18 for them, marked as "pending
> consensus", so we have only to confirm that the text is acceptable to the
> working group.  There's been no discussion of that text that I've seen, and I
> take that to mean that what's there looks good.
> 
> We'll give it another few days, and take silence to mean assent.  In other
> words, if anyone has problems with the "pending consensus" text, please
> start a new thread about it, and put the issue number in the subject line
> ("Subject: Issue 15, new client registration", for example).  Barring objections
> by this coming Tuesday afternoon (19 July), I will close issues 15 thru 18.
> 
> As soon as we get resolutions for issues 19 thru 21, we'd like to start working
> group last call on draft-ietf-oauth-v2.  So let's get all the issues sorted out as
> soon as we can, and move this document ahead.
> 
> Issues 19 thru 21: