Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Eran Hammer <eran@hueniverse.com> Thu, 15 March 2012 14:45 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 63AA021F863E for <oauth@ietfa.amsl.com>; Thu, 15 Mar 2012 07:45:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.536
X-Spam-Level:
X-Spam-Status: No, score=-2.536 tagged_above=-999 required=5 tests=[AWL=0.062, BAYES_00=-2.599, HTML_MESSAGE=0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id JW2XQ5Xrs7nu for <oauth@ietfa.amsl.com>; Thu, 15 Mar 2012 07:45:34 -0700 (PDT)
Received: from p3plex1out02.prod.phx3.secureserver.net (p3plex1out02.prod.phx3.secureserver.net [72.167.180.18]) by ietfa.amsl.com (Postfix) with SMTP id CFF9121F8648 for <oauth@ietf.org>; Thu, 15 Mar 2012 07:45:34 -0700 (PDT)
Received: (qmail 5107 invoked from network); 15 Mar 2012 14:45:33 -0000
Received: from unknown (HELO p3plex2out02.prod.phx3.secureserver.net) (184.168.131.14) by p3plex1out02.prod.phx3.secureserver.net with SMTP; 15 Mar 2012 14:45:33 -0000
Received: from P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.47]) by p3plex2out02.prod.phx3.secureserver.net with bizsmtp id lqlY1i00111lQaG01qlZ1v; Thu, 15 Mar 2012 07:45:33 -0700
Received: from P3PW5EX1MB01.EX1.SECURESERVER.NET ([10.6.135.20]) by P3PW5EX1HT005.EX1.SECURESERVER.NET ([72.167.180.134]) with mapi; Thu, 15 Mar 2012 07:45:30 -0700
From: Eran Hammer <eran@hueniverse.com>
To: Nat Sakimura <sakimura@gmail.com>, Breno de Medeiros <breno@google.com>, OAuth WG <oauth@ietf.org>
Date: Thu, 15 Mar 2012 07:45:20 -0700
Thread-Topic: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
Thread-Index: Ac0CiojBIiokKrGLS8qyc3KbuKLKkwAL1Wpw
Message-ID: <90C41DD21FB7C64BB94121FBBC2E723453AFF089F4@P3PW5EX1MB01.EX1.SECURESERVER.NET>
References: <CAGdjJpLBCyvg21zuGi1jWK58hkDL4Ff7-xdJ0dy0WZpvNPPrKA@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08903@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAAJ++qE3KcFgJey7xXzW8dkTPzvtcu_ke7abkOEMS4hwi93yEg@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08919@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAGdjJpK6dMzSyoxEb_2rQcB-anXzvWaW-PLdYTZW_jECieBSMg@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08932@P3PW5EX1MB01.EX1.SECURESERVER.NET> <4E1F6AAD24975D4BA5B16804296739436641D4E3@TK5EX14MBXC284.redmond.corp.microsoft.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF08949@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CAAJ++qG+jdej64rjWM8V4MU_uxEc-2WoT4MKqhD_9ef0jBYwgg@mail.gmail.com> <CAC4RtVBzDdeJViT_zOJ4QQQoo4Soy0iJJL_EK5zGd+94J1h7RQ@mail.gmail.com> <90C41DD21FB7C64BB94121FBBC2E723453AFF0896E@P3PW5EX1MB01.EX1.SECURESERVER.NET> <CALaySJ+tTmh1jHzn-6g+CSwLWNoq0KQ1HKXD-KdaORZKJwjv6w@mail.gmail.com> <CALaySJL9EphC=L2Dj++9bCcusnOPouQ4vRmuEdDM-6ggURo-fA@mail.gmail.com> <CABzCy2Bi+YvaJiXwsnNPFHXxGDkFSRiMEzKbVi9YD8zF7D8nxg@mail.gmail.com>
In-Reply-To: <CABzCy2Bi+YvaJiXwsnNPFHXxGDkFSRiMEzKbVi9YD8zF7D8nxg@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: multipart/alternative; boundary="_000_90C41DD21FB7C64BB94121FBBC2E723453AFF089F4P3PW5EX1MB01E_"
MIME-Version: 1.0
Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23
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: Thu, 15 Mar 2012 14:45:36 -0000
This add-on is unnecessary. It already says the authorization server can handle it any way it wants. The fact that other registration options are possible clearly covers the client identifier reuse case. As for the response type, that's not an issue but more of an optimization for an edge case raised. EH From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Nat Sakimura Sent: Thursday, March 15, 2012 2:04 AM To: Breno de Medeiros; OAuth WG Subject: Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. 23 So, Eran's first proposal: A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server, unless the authorization server provides other registration options to specify such complex clients. kind of meets my concern. There seems to be another issue around the usefulness of return_type in such case raised by Breno, and if I understand it correctly, Eran's answer was that these separate components may have the same client_id so that return_type is a valid parameter to be sent at the request. So, to clarify these, perhaps changing the above text slightly to the following solves the problem? A client application consisting of multiple components, each with its own client type (e.g. a distributed client with both a confidential server-based component and a public browser-based component), MUST register each component separately as a different client to ensure proper handling by the authorization server, unless the authorization server provides other registration options to specify such complex clients. Each component MAY have the same client_id, in which case the server judges the client type and the associated security context based on the response_type parameter in the request. Would it solve your problem, Breno? Best, =nat
- [OAUTH-WG] Fw: Breaking change in OAuth 2.0 rev. … Marius Scurtescu
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Marius Scurtescu
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Mike Jones
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Richer, Justin P.
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Barry Leiba
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Barry Leiba
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Barry Leiba
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Nat Sakimura
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… John Bradley
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Mike Jones
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno de Medeiros
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Breno
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Eran Hammer
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Mike Jones
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… Nat Sakimura
- Re: [OAUTH-WG] Fw: Breaking change in OAuth 2.0 r… John Bradley