Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
<Axel.Nennker@telekom.de> Thu, 13 May 2010 20:50 UTC
Return-Path: <Axel.Nennker@telekom.de>
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 791123A68E6 for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:03 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.949
X-Spam-Level:
X-Spam-Status: No, score=-1.949 tagged_above=-999 required=5 tests=[AWL=-1.300, BAYES_50=0.001, HELO_EQ_DE=0.35, RCVD_IN_DNSWL_LOW=-1]
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 vox885MK86Mn for <oauth@core3.amsl.com>; Thu, 13 May 2010 13:50:02 -0700 (PDT)
Received: from tcmail83.telekom.de (tcmail83.telekom.de [62.225.183.131]) by core3.amsl.com (Postfix) with ESMTP id 8D6613A6832 for <oauth@ietf.org>; Thu, 13 May 2010 13:49:56 -0700 (PDT)
Received: from s4de9jsaano.mgb.telekom.de (HELO S4DE9JSAANO.ost.t-com.de) ([10.125.177.105]) by tcmail81.telekom.de with ESMTP; 13 May 2010 22:49:40 +0200
Received: from S4DE9JSAAID.ost.t-com.de ([10.125.177.169]) by S4DE9JSAANO.ost.t-com.de with Microsoft SMTPSVC(6.0.3790.4675); Thu, 13 May 2010 22:49:39 +0200
X-MimeOLE: Produced By Microsoft Exchange V6.5
Content-class: urn:content-classes:message
MIME-Version: 1.0
Content-Type: text/plain; charset="US-ASCII"
Content-Transfer-Encoding: quoted-printable
Date: Thu, 13 May 2010 22:49:37 +0200
Message-ID: <98B37F7D0484184B9DBDCC44B6C8EDA3049FA5BA@S4DE9JSAAID.ost.t-com.de>
In-Reply-To: <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt
thread-index: AcrwdLKxFih7IRblQsKaGWxu0kloVACUBeegAAWsfrA=
References: <4BE730CC.1090607@lodderstedt.net><90C41DD21FB7C64BB94121FBBC2E72343B3AB46E24@P3PW5EX1MB01.EX1.SECURESERVER.NET><4BE85A86.2020701@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72343B3B698854@P3PW5EX1MB01.EX1.SECURESERVER.NET>
From: Axel.Nennker@telekom.de
To: eran@hueniverse.com
X-OriginalArrivalTime: 13 May 2010 20:49:39.0404 (UTC) FILETIME=[CE2A18C0:01CAF2DD]
Cc: 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: Thu, 13 May 2010 20:50:03 -0000
Two snippets from the emails below: > > You mean token format? OAuth defined the token as opaque so that > would be counter-productive. My comment on that comment: "opaque" for oauth could mean that oauth does not handle certain types of tokens specially. I think this is not an argument to reject the request that the client could ask for one token format. I think a client should be allowed to ask for a token format but oauth should not handle any format specially. Oauth should transport all tokens but the format is something agreed upon between client, authorization server and resource server. Requesting a token format is also a means to migrate from one token format to the next. >> I dont't mean OAuth shall define token formats. I just ask for a way to >> request tokens in a particular format and pass such meta data from AS to >> resource server via the client. Why is that counter-productive? >> Otherwise the resource server has to implement some token format >> discovery. > >Yes it does. > >EHL My comment on that comment: If we burden the resource server with token format discovery then why not burdon the authorization server with client_credential discovery? Currently if client_secrets are used the client maker has to register the client with the authorization server maintainer to get the client_secret and such. This agreement is beyond the scope of oauth. I think client and authorization server should be allowed to agree on any authentication scheme not just shared secrets. My request is to just rename client_secret to client_credential; both of them know what they agreed upon whether it is a shared secret or something else. -Axel -----Original Message----- From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Eran Hammer-Lahav Sent: Thursday, May 13, 2010 7:59 PM To: Torsten Lodderstedt Cc: OAuth WG (oauth@ietf.org) Subject: Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt > -----Original Message----- > From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] > Sent: Monday, May 10, 2010 12:12 PM > >> 3.6.1.1. End-user Grants Authorization > >> > >> Why not call the "code" Parameter "verification_code"? It's called > >> verification code in the text. > >> > > Longer for no reason. > > > > for the sake of clarity? Anyone with thoughts on this? > >> 3.6.2. Client Requests Access Token > >> > >> client_secret > >> REQUIRED if the client identifier has a matching secret. The > >> client secret as described in Section 3.4. > >> > >> 1) I'm having trouble to understand the meaning of "if the client > >> identifier has a matching secret". Is the assumption underneath that > >> authorization servers require this secrets from all clients they have issued > a secret to? Yes. > >> What about client w/o a secret? Are they also allowed to use this flow? > >> Or is there envisioned a dependency > >> between the client type, clients credentials and the flows a > >> particular client is authorized to use? Yes, they are (I think this is the compromise on native apps). > >> I would have expected a clear policy which flows require > >> authentication and which not. Suggest text. > >> 3.7.2. Client Requests Access Token > >> > >> "authorization_declined" > >> > >> Why does the spec interpret a request as bad request if the user just > >> has declined the authorization? According to rfc2616 the semantics of > >> 400 is: "The request could not be understood by the server due to > >> malformed syntax". > >> > >> The calling client did not sent a malformed request, it cannot > >> foresee or influence this outcome. I would suggest to either use > >> status 403 or to return status code 200 for all syntactically correct > >> and authorized request and to use another return codes in the response > body to detail the requests outcome. > >> > > Did you miss this question? No. Just ignored it because I need to go over all the HTTP status codes and error messages and clean it all up. Its incomplete at best right now. > >> 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. > > > > What would be the right way? Allow the client to include an access token when asking for additional scope (via a normal flow) so that resulting token will include the scope of both new and old scopes. > >> 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. > > > > That's interesting! I consider the authentication scheme the major > contribution of OAuth since it allows for a standardized way of service > interaction. So 3rd party software components can be integrated into a > companies infrastructure (incl. AS) w/o customization. Moreover, as you > pointed out, there will be many other ways to get tokens in the future. I'm not married to the name. I dislike 'OAuth2' because it is wrong to put a version number in the name. We can potentially reuse 'OAuth' but I'm opposed to using the 'oauth_version=2.0' parameter specified in OAuth 1.0. So we can just update 1.0 (since it is now an RFC) to note that 1.0 uses the oauth_ prefix for parameters and deprecate the oauth_version parameter. Or something like that. I'm also open to new suggestions. But I think 'Token' is very descriptive (but I agree it does depend on your view of what is OAuth - I think it is really just the collection of flows). > > > >> 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. > > > > I dont't mean OAuth shall define token formats. I just ask for a way to > request tokens in a particular format and pass such meta data from AS to > resource server via the client. Why is that counter-productive? > Otherwise the resource server has to implement some token format > discovery. Yes it does. EHL _______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
- [OAUTH-WG] Comments on draft-ietf-oauth-v2-03.txt Torsten Lodderstedt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Dick Hardt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Dick Hardt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Torsten Lodderstedt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Torsten Lodderstedt
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Evan Gilbert
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Evan Gilbert
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Strict equality matching of redire… Luke Shepard
- Re: [OAUTH-WG] Strict equality matching of redire… Raffi Krikorian
- Re: [OAUTH-WG] Strict equality matching of redire… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Marius Scurtescu
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Eran Hammer-Lahav
- Re: [OAUTH-WG] Comments on draft-ietf-oauth-v2-03… Axel.Nennker
- Re: [OAUTH-WG] Strict equality matching of redire… Dick Hardt
- Re: [OAUTH-WG] Strict equality matching of redire… Evan Gilbert
- Re: [OAUTH-WG] Strict equality matching of redire… Marius Scurtescu
- Re: [OAUTH-WG] Strict equality matching of redire… Brian Eaton
- Re: [OAUTH-WG] Strict equality matching of redire… Evan Gilbert