Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 16:58:09 +0100

On 2012-01-23 16:46, The IESG wrote:
>
> The IESG has received a request from the Web Authorization Protocol WG
> (oauth) to consider the following document:
> - 'The OAuth 2.0 Authorization Protocol: Bearer Tokens'
>    <draft-ietf-oauth-v2-bearer-15.txt>  as a Proposed Standard
> ...

Please see my comments in 
<https://www.ietf.org/mail-archive/web/oauth/current/msg08120.html> 
which I think have not been addressed.

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Mon, 23 Jan 2012 18:39:12 +0100

On 2012-01-23 18:24, Mike Jones wrote:
> As editor of the Oauth Bearer spec, I believe that these comments have been well understood and considered by the working group.  I do understand that the working group's consensus position is different than Julian's.  See these notes documenting that this is the case:
>
> https://www.ietf.org/mail-archive/web/oauth/current/msg08113.html
> https://www.ietf.org/mail-archive/web/oauth/current/msg08116.html
> https://www.ietf.org/mail-archive/web/oauth/current/msg08121.html
> ...

We are going in circles; see 
<https://www.ietf.org/mail-archive/web/oauth/current/msg08118.html>.

I can only recommend that people who want to know what's going on read 
the complete mail thread.

Also I'd like to point out that I *did* recommend to go to IETF LC 
despite these issues because I believe that more review from outside the 
WG is needed here.

Best regards, Julian

---

From: Mike Jones <[email-masked]>
Date: Mon, 23 Jan 2012 17:24:24 +0000

Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Monday, January 23, 2012 7:58 AM
To: [email-masked]
Cc: The IESG; [email-masked]; IETF-Announce
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

On 2012-01-23 16:46, The IESG wrote:
>    <draft-ietf-oauth-v2-bearer-15.txt>  as a Proposed Standard ...

Best regards, Julian
_______________________________________________
OAuth mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/oauth

---

From: Mike Jones <[email-masked]>
Date: Mon, 23 Jan 2012 18:44:35 +0000

Resending including [email-masked], per the advice of Cindy Morgan of the IESG Secretariat...

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, January 23, 2012 9:24 AM
To: [email-masked]
Cc: Julian Reschke; The IESG; [email-masked]; IETF-Announce
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Monday, January 23, 2012 7:58 AM
To: [email-masked]
Cc: The IESG; [email-masked]; IETF-Announce
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

Best regards, Julian

---

From: Julian Reschke <[email-masked]>
Date: Wed, 25 Jan 2012 00:23:48 +0100

> which I think have not been addressed.

In an off-list conversation I heard that what I said before may not be 
as clear as it could be.

So...

1) draft-ietf-oauth-v2-bearer-15 defines a new HTTP authentication scheme.

2) In the IANA considerations, it references the registration procedure 
defined in 
<http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3> 
(now -18, but that doesn't matter here).

3) That document recommends in 
<http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-2.3.1>:

    o  The parsing of challenges and credentials is defined by this
       specification, and cannot be modified by new authentication
       schemes.  When the auth-param syntax is used, all parameters ought
       to support both token and quoted-string syntax, and syntactical
       constraints ought to be defined on the field value after parsing
       (i.e., quoted-string processing).  This is necessary so that
       recipients can use a generic parser that applies to all
       authentication schemes.

4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has 
been mentioned that it might not have ignored it if it had UPPERCASE 
requirements, but in HTTPbis we try to restrict BCP14 keywords to the 
actual protocol, not on recommendations on other specs.

5) The registration requirement for a new scheme is "IETF review", which 
RFC 5226 defines in <http://tools.ietf.org/html/rfc5226#section-4.1> as:

       IETF Review - (Formerly called "IETF Consensus" in
             [IANA-CONSIDERATIONS]) New values are assigned only through
             RFCs that have been shepherded through the IESG as AD-
             Sponsored or IETF WG Documents [RFC3932] [RFC3978].  The
             intention is that the document and proposed assignment will
             be reviewed by the IESG and appropriate IETF WGs (or
             experts, if suitable working groups no longer exist) to
             ensure that the proposed assignment will not negatively
             impact interoperability or otherwise extend IETF protocols
             in an inappropriate or damaging manner.

In this case the WG exists (it's HTTPbis), and the OAuth got two reviews 
from HTTPbis pointing out the problem  -- from Mark Nottingham, the WG 
chair, and myself, one of the authors.

And yes, I believe the way OAuth defines the syntax *will* impact 
interoperability.

Also, I haven't seen any explanation why OAuth can not follow the 
recommendation from HTTPbis.

Hope this clarifies things,

Julian

---

From: Mike Jones <[email-masked]>
Date: Tue, 24 Jan 2012 23:45:12 +0000

(Resending now that I'm a member of the [email-masked] list so that my note will appear there.)

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Mike Jones
Sent: Monday, January 23, 2012 9:24 AM
To: [email-masked]
Cc: Julian Reschke; The IESG; [email-masked]; IETF-Announce
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

				Best wishes,
				-- Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Julian Reschke
Sent: Monday, January 23, 2012 7:58 AM
To: [email-masked]
Cc: The IESG; [email-masked]; IETF-Announce
Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard

Best regards, Julian

---

From: SM <[email-masked]>
Date: Tue, 24 Jan 2012 18:43:06 -0800

At 07:46 23-01-2012, The IESG wrote:
>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
>[email-masked] mailing lists by 2012-02-06. Exceptionally, comments may be

 From Section 2.3:

   'When sending the access token in the HTTP request URI, the client
    adds the access token to the request URI query component as defined
    by Uniform Resource Identifier (URI) [RFC3986] using the
    "access_token" parameter.'

This draft standardizes the URI query parameter to be used.  There 
isn't any mention of whether it is reserving the parameter.  The 
draft mentions that:

   'Because of the security weaknesses associated with the URI method
   (see Section 4), including the high likelihood that the URL
   containing the access token will be logged, it SHOULD NOT be used
   unless it is impossible to transport the access token in the
   "Authorization" request header field or the HTTP request entity-body.'

The security weakness is well-known.  It might be good to label 
Section 2.3 as deprecated.  I note that a "platform" using OAuth 2.0 
does not mention the above security consideration.

As for Section 3, it seems that the text reflects a consensus 
decision of the working group which is at odds with a recommendation 
in the specifications from HTTPbis:

   "As for your assertion that the specs are in conflict, yes, the Bearer spec
    includes a different decision than a RECOMMENDED clause in the HTTPbis spec
    (which was added after the Bearer text was already in place).  However, it
    is not violating any MUST clauses in the HTTPbis spec."

The thread of the discussion is at 
http://www.ietf.org/mail-archive/web/oauth/current/msg08051.html

The informative reference for RFC 2616 can be removed.

Regards,
S. Moonesamy

---

From: Eran Hammer <[email-masked]>
Date: Tue, 24 Jan 2012 23:23:51 -0700

I fully agree with Julian's perspective. I believe there is sufficient feedback requiring further review of this issue. If the editor cannot facilitate a path forward, I request the chairs to intervene. 

I will make sure this feedback is fully applied to the MAC token specification in the next draft.

EHL

> Sent: Tuesday, January 24, 2012 3:24 PM
> To: [email-masked]
> Cc: The IESG; [email-masked]
> Subject: Re: [OAUTH-WG] Last Call: <draft-ietf-oauth-v2-bearer-15.txt> (The
> OAuth 2.0 Authorization Protocol: Bearer Tokens) to Proposed Standard
> 
> In an off-list conversation I heard that what I said before may not be as clear
> as it could be.
> 
> So...
> 
> defined in <http://tools.ietf.org/html/draft-ietf-httpbis-p7-auth-17#section-
> 2.3>
> 4) draft-ietf-oauth-v2-bearer-15 ignores this recommendation. It has been
> mentioned that it might not have ignored it if it had UPPERCASE
> requirements, but in HTTPbis we try to restrict BCP14 keywords to the actual
> protocol, not on recommendations on other specs.
> 
> 5) The registration requirement for a new scheme is "IETF review", which RFC
> 5226 defines in <http://tools.ietf.org/html/rfc5226#section-4.1> as:
> 
> In this case the WG exists (it's HTTPbis), and the OAuth got two reviews from
> HTTPbis pointing out the problem  -- from Mark Nottingham, the WG chair,
> and myself, one of the authors.
>