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