Re: [OAUTH-WG] Issue 15, new client registration
Eran Hammer-Lahav <eran@hueniverse.com> Sat, 23 July 2011 16:38 UTC
Return-Path: <eran@hueniverse.com>
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 5C0B321F8A69 for <oauth@ietfa.amsl.com>; Sat, 23 Jul 2011 09:38:55 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.066
X-Spam-Level:
X-Spam-Status: No, score=-2.066 tagged_above=-999 required=5 tests=[AWL=-0.468, BAYES_00=-2.599, EXTRA_MPART_TYPE=1, HTML_MESSAGE=0.001]
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 6cs31k2MkdGb for <oauth@ietfa.amsl.com>; Sat, 23 Jul 2011 09:38:52 -0700 (PDT)
Received: from p3plex1out01.prod.phx3.secureserver.net (p3plex1out01.prod.phx3.secureserver.net [72.167.180.17]) by ietfa.amsl.com (Postfix) with SMTP id 6557921F88B7 for <oauth@ietf.org>; Sat, 23 Jul 2011 09:38:52 -0700 (PDT)
Received: (qmail 2986 invoked from network); 23 Jul 2011 16:38:51 -0000
Received: from unknown (HELO smtp.ex1.secureserver.net) (72.167.180.19) by p3plex1out01.prod.phx3.secureserver.net with SMTP; 23 Jul 2011 16:38:51 -0000
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.19]) by P3PW5EX1HT001.EX1.SECURESERVER.NET ([72.167.180.19]) with mapi; Sat, 23 Jul 2011 09:38:51 -0700
From: Eran Hammer-Lahav <eran@hueniverse.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Date: Sat, 23 Jul 2011 09:38:16 -0700
Thread-Topic: [OAUTH-WG] Issue 15, new client registration
Thread-Index: AcxJKyrGLdylEPi2RQ6WdVYMylz2uQAKbVew
Message-ID: <90C41DD21FB7C64BB94121FBBC2E72345021F37840@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <4E2740E9.5000209@lodderstedt.net> <4E274191.6020207@lodderstedt.net> <90C41DD21FB7C64BB94121FBBC2E72345021F377AA@P3PW5EX1MB01.EX1.SECURESERVER.NET> <64930E85-923B-4811-8A6B-6A677B95F904@kiva.org> <90C41DD21FB7C64BB94121FBBC2E72345021F377C3@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E2AAF88.4050807@lodderstedt.net>
In-Reply-To: <4E2AAF88.4050807@lodderstedt.net>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/related; boundary="_005_90C41DD21FB7C64BB94121FBBC2E72345021F37840P3PW5EX1MB01E_"; type="multipart/alternative"
MIME-Version: 1.0
Cc: OAuth WG <oauth@ietf.org>
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: Sat, 23 Jul 2011 16:38:55 -0000
Client authentication can be very useful for imposing restrictions on the token endpoint, as well as the reasons listed in 3.2.1. Personally, given the clear direction the web is taking where applications are moving off hosted servers to mobile devices and in-browser software, I believe that focusing OAuth 2.0 ability to identify a client based on a secret is counterproductive. This is why my last rewrite put much more weight on the redirection URI and clarifying registration requirements. OAuth 1.0 was highly criticized for failing to address client identity in public clients. I believe OAuth 2.0 offers a much better story, within the boundaries of what's possible today. Back to the terminology question, we need to find terms that directly translate to the client ability to authenticate using credentials of other means. This is not about client identity or about trust. EHL From: Torsten Lodderstedt [mailto:torsten@lodderstedt.net] Sent: Saturday, July 23, 2011 4:25 AM To: Eran Hammer-Lahav Cc: Skylar Woodward; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration Am 22.07.2011 23:49, schrieb Eran Hammer-Lahav: In many cases you can verify a public client using a registered redirection URI. I'm in doubt regarding "many". This kind of verification makes the assumption that the evildoer uses a web application which requires a correct refering to his site. I think client secrets (or other authentication schemes) are much more effective way of verifiying client identities. Or let me put it the other way around. If redirect uri verification is sufficient in many cases. Why do we need a client secret? regards, Torsten. EHL From: Skylar Woodward [mailto:skylar@kiva.org] Sent: Friday, July 22, 2011 2:46 PM To: Eran Hammer-Lahav Cc: Torsten Lodderstedt; OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration Looks like Torsten already has capture my suggestion which is also what the Kiva documentation uses... Verifiable/Forgeable identity. It's precise and avoids making a statement about trust, etc. But only developers need such simple one-word classifications. For end users (e.g., people w/ accounts who approve access for an app) we're be providing much more verbose explanations. For example. "This application's identity has ben verified... still (caution, caution, caution)" or "This application's identity cannot be verified. Only approve this application if you absolutely trust the application or link that sent you this page..." App users can't discern the significance of public vs. private credentials. To me, public credentials are not credentials at all. Yet another term to define. Better to be precise. Another option (and terminology we use to help developers) Can Keep Secrets / Can't Keep Secrets. Attached screenshots in case anyone is interested in how this plays out in real-world UI (vs. specs). [cid:image001.png@01CC491A.C1B51830][cid:image002.png@01CC491A.C1B51830] On Jul 22, 2011, at 11:12 PM, Eran Hammer-Lahav wrote: -----Original Message----- From: oauth-bounces@ietf.org<mailto:oauth-bounces@ietf.org> [mailto:oauth-bounces@ietf.org]<mailto:[mailto:oauth-bounces@ietf.org]> On Behalf Of Torsten Lodderstedt Sent: Wednesday, July 20, 2011 1:59 PM To: OAuth WG Subject: Re: [OAUTH-WG] Issue 15, new client registration 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. I'm open to changing the names. I don't like trusted/untrusted because OAuth does not define trust. The authenticated/unauthenticated pair is also not ideal because the terms describe the outcome, not the nature of the client. As for verifiable/forgeable, I think these terms are too complicated for a casual reader. My intention with public/private is to identify the nature of the client credentials. So a more verbose version would be 'public credentials/private credentials'. This also works with 'code' instead of 'credentials'. It's clear from the past year of discussions that we need terminology to describe these two types. Any other suggestions? EHL _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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