Re: [OAUTH-WG] Issue 15, new client registration
Torsten Lodderstedt <torsten@lodderstedt.net> Wed, 20 July 2011 20:59 UTC
Return-Path: <torsten@lodderstedt.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C68B921F8AB9 for <oauth@ietfa.amsl.com>; Wed, 20 Jul 2011 13:59:05 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[AWL=0.250, BAYES_00=-2.599, HELO_EQ_DE=0.35]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id zSrQ5rNUh+7g for <oauth@ietfa.amsl.com>; Wed, 20 Jul 2011 13:58:58 -0700 (PDT)
Received: from smtprelay03.ispgateway.de (smtprelay03.ispgateway.de [80.67.31.41]) by ietfa.amsl.com (Postfix) with ESMTP id 4BAF421F8A97 for <oauth@ietf.org>; Wed, 20 Jul 2011 13:58:58 -0700 (PDT)
Received: from [79.253.8.100] (helo=[192.168.71.35]) by smtprelay03.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from <torsten@lodderstedt.net>) id 1Qjdr7-00022G-1c for oauth@ietf.org; Wed, 20 Jul 2011 22:58:57 +0200
Message-ID: <4E274191.6020207@lodderstedt.net>
Date: Wed, 20 Jul 2011 22:58:57 +0200
From: Torsten Lodderstedt <torsten@lodderstedt.net>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; de; rv:1.9.2.18) Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
To: OAuth WG <oauth@ietf.org>
References: <4E2740E9.5000209@lodderstedt.net>
In-Reply-To: <4E2740E9.5000209@lodderstedt.net>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Df-Sender: torsten@lodderstedt-online.de
Subject: Re: [OAUTH-WG] Issue 15, new client registration
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/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: Wed, 20 Jul 2011 20:59:05 -0000
2.1 Client types I'm struggeling with the new terminology of "private" and "public" clients. In my perception, the text just distinguishes clients which can be authenticated and such which cannot. This is fine but I consider the wording misleading. I would suggest to change it to something like trusted/untrusted or authenticated/unauthenticated or Verifiable/Forgeable. Moreover, I think merging the text on client types in section 10 into section 2.1 would make sense for the following reasons: - there is large overlap between them - It would introduce the term "native application" before it is used for the first time in Section 9 2.2. Registration Requirements Why is the redirect URI a MUST? It should be a MUST for clients using the implicit grant and probably for "private" clients but why generally? I would suggest to change this to RECOMMENDED. 2.4 Client Authentication "In addition, the client and authorization server establish a client authentication method suitable for the client type and security requirements of the authorization server." Does this hold true for public clients? 2.4.1 Client Password "Clients in possession of a client password MAY " Why not SHOULD? regards, Torsten. Am 20.07.2011 22:56, schrieb Torsten Lodderstedt: > 2.1 Client types > > I'm struggeling with the new terminology of "private" and "public" > clients. In my perception, the text just distinguishes clients which > can be authenticated and such which cannot. This is fine but I > consider the wording misleading. I would suggest to change it to > something like trusted/untrusted or authenticated/unauthenticated or > Verifiable/Forgeable. > > Moreover, I think merging section 2.1 with the text on client types in > section 10 would make sense for the following reasons: > - there is large overlap between them > - It would introduce the term "native application" before it is used > for the first time in Section 9 > > 2.2. Registration Requirements > > Why is the redirect URI a MUST? It should be a MUST for clients using > the implicit grant and probably for "private" clients but why > generally? I would suggest to change this to RECOMMENDED. > > 2.4 Client Authentication > > "In addition, the client and authorization server establish a client > authentication method suitable for the client type and security > requirements of the authorization server." > > Does this hold true for public clients? > > 2.4.1 Client Password > > "" > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] Issue 15, new client registration Torsten Lodderstedt
- [OAUTH-WG] Issue 15, new client registration Torsten Lodderstedt
- Re: [OAUTH-WG] Issue 15, new client registration Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue 15, new client registration Lu, Hui-Lan (Huilan)
- Re: [OAUTH-WG] Issue 15, new client registration Skylar Woodward
- Re: [OAUTH-WG] Issue 15, new client registration Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue 15, new client registration Torsten Lodderstedt
- Re: [OAUTH-WG] Issue 15, new client registration Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue 15, new client registration Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue 15, new client registration Eran Hammer-Lahav
- Re: [OAUTH-WG] Issue 15, new client registration Justin Richer
- Re: [OAUTH-WG] Issue 15, new client registration Eran Hammer-Lahav