Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt

Eran Hammer-Lahav <eran@hueniverse.com> Mon, 10 May 2010 05:10 UTC

Return-Path: <eran@hueniverse.com>
X-Original-To: oauth@core3.amsl.com
Delivered-To: oauth@core3.amsl.com
Received: from localhost (localhost [127.0.0.1]) by core3.amsl.com (Postfix) with ESMTP id 74B123A67DB for <oauth@core3.amsl.com>; Sun, 9 May 2010 22:10:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.241
X-Spam-Level:
X-Spam-Status: No, score=-1.241 tagged_above=-999 required=5 tests=[AWL=-1.056, BAYES_40=-0.185]
Received: from mail.ietf.org ([64.170.98.32]) by localhost (core3.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id yHp6Q+HHvuWK for <oauth@core3.amsl.com>; Sun, 9 May 2010 22:10:03 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by core3.amsl.com (Postfix) with SMTP id B12C43A6AE7 for <oauth@ietf.org>; Sun, 9 May 2010 22:09:53 -0700 (PDT)
Received: (qmail 22566 invoked from network); 10 May 2010 05:09:41 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.21) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 10 May 2010 05:09:40 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT003.EX1.SECURESERVER.NET ([72.167.180.21]) with mapi; Sun, 9 May 2010 22:09:41 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Dick Hardt <dick.hardt@gmail.com>
Date: Sun, 09 May 2010 22:09:42 -0700
Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
Thread-Index: Acrv2w23sf/PKOeMS2yKi7p3XwQGcAAIpMww
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E37@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4BE730CC.1090607@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET> <918F548B-2501-4630-977E-0A7D4484D067@gmail.com>
In-Reply-To: <918F548B-2501-4630-977E-0A7D4484D067@gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "OAuth WG (oauth@ietf.org)" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/oauth>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 10 May 2010 05:10:05 -0000

> -----Original Message-----
> From: Dick Hardt [mailto:dick.hardt@gmail.com]
> Sent: Sunday, May 09, 2010 5:52 PM

> >> BTW: Will Brian's security considerations document be updated to be
> >> in sync with the draft?
> >
> > Brian's document was written for WRAP. We need to write a full security
> review for 2.0 that is structure similarly to OAuth 1.0.
> 
> Besides changing some terminology, I would think Brian's doc would be
> mainly reusable. Perhaps you could insert a version with changes you
> understand, then people can suggest changes that need to be made.

Since the security section is all non-normative language, it is the least important part on my list. Brian's document is useful but is not something I can work with quickly. If someone wants to take a stab at converting it into a section that can be cut-and-paste into the draft, I would be very happy to incorporate it.
 
> >> 3.5.1.  Client Requests Authorization
> >>
> >> If the client has previously registered a redirection URI with the
> >>    authorization server, the authorization server MUST verify that the
> >>    redirection URI received matches the registered URI associated with
> >>    the client identifier.
> >>
> >> Does this mean equality? Or just the same base string?
> >
> > Right now it depends on the server.
> 
> The spec should clarify that. Suggested wording:
> 
> 
> If the client has previously registered a redirection URI with the authorization
> server, the authorization server MUST verify that the redirection URI
> received matches the registered URI associated with the client identifier. The
> components of the redirection URI that must match the registered URI is
> authorization server dependant.

I don't see how that helps... I also don't see why we can't just profile this and decide on how the matching should be done. We have the state parameter to help too.

> >> 7.  Refreshing an Access Token
> >>
> >> I would suggest to add an optional "scope" parameter to this request.
> >> This could be used to downgrade the scope associated with a token.
> >
> > That would be the wrong way to do it given that people will expect to also
> be able to upgrade scope.
> 
> Would you elaborate? Would not providing a scope parameter enable any
> potential change in scope to the access token? The change may be neither an
> upgrade or downgrade, just different.

Downgrading scope is the only modification allowed without getting the end-user involved again (or using any of the flows from the beginning). When you refresh a token, you can ask to get a new token with less scope because that will not conflict with the access grant.

> >> 8.1.  The Authorization Request Header
> >>
> >> I consider the name "Token" of the authentication schema much to
> generic.
> >> That was also the feedback of all colleagues I talked to about the
> >> upcoming standard. Why not call it "OAuth2"?
> >
> > It is meant to be generic. I consider OAuth to be the part of the protocol
> dealing with getting a token. There will be many new ways to get a token in
> the future.
> 
> I also find the use of Token here.

Find it...?

> >> 8.2.2.  Form-Encoded Body Parameter
> >>
> >> I would suggest to drop this section/feature.
> >>
> >> General note: Would it make sense to add explicit format handling to
> >> the OAuth API? If we envision authorization servers supporting more
> >> than one token format (e.g. SAML, SWT, ...), the client should given
> >> the option to request a certain format and responses returning access
> >> tokens should indicate the format of this token. The OAuth
> >> authorization header could also have an optional format attribute for the
> same purpose.
> >
> > You mean token format? OAuth defined the token as opaque so that
> would be counter-productive.
> 
> Not only can the AS support multiple formats, but a PR could support
> multiple formats. While the token is opaque to the client, the PR is going to
> need to detect what kind of token was presented in some way. We can
> make this easier by something in the spec, or defer this to the PR to detect
> tokens by examining the token. The scope parameter could be used by the
> AS to determine the token type to be generated.

Token type negotiation is something this group has strongly rejected in the past. I am not sure we can even agree on the right abstraction layer. Either way, there is nothing to stop someone from extending the spec.

And BTW, people can write extensions *now*. This is not aimed at anyone: if you feel strongly about a feature getting little love by this group or facing strong objections, it is your responsibility to draft it and promote it. If you get enough people to like it, we can incorporate it. If not, you can publish it as a companion document.

EHL