[OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration

Mike Jones <Michael.Jones@microsoft.com> Fri, 04 January 2013 23:55 UTC

Return-Path: <Michael.Jones@microsoft.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 B8D2221F8A8E for <oauth@ietfa.amsl.com>; Fri, 4 Jan 2013 15:55:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.598
X-Spam-Level:
X-Spam-Status: No, score=-2.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, 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 mMIwM0lTj2TM for <oauth@ietfa.amsl.com>; Fri, 4 Jan 2013 15:55:57 -0800 (PST)
Received: from NA01-BY2-obe.outbound.protection.outlook.com (na01-by2-obe.ptr.protection.outlook.com [207.46.100.27]) by ietfa.amsl.com (Postfix) with ESMTP id 529EE21F8428 for <oauth@ietf.org>; Fri, 4 Jan 2013 15:55:57 -0800 (PST)
Received: from BL2FFO11FD006.protection.gbl (10.173.161.200) by BL2FFO11HUB039.protection.gbl (10.173.160.245) with Microsoft SMTP Server (TLS) id 15.0.586.12; Fri, 4 Jan 2013 23:55:54 +0000
Received: from TK5EX14HUBC107.redmond.corp.microsoft.com (131.107.125.37) by BL2FFO11FD006.mail.protection.outlook.com (10.173.161.2) with Microsoft SMTP Server (TLS) id 15.0.586.12 via Frontend Transport; Fri, 4 Jan 2013 23:55:54 +0000
Received: from TK5EX14MBXC283.redmond.corp.microsoft.com ([169.254.2.24]) by TK5EX14HUBC107.redmond.corp.microsoft.com ([157.54.80.67]) with mapi id 14.02.0318.003; Fri, 4 Jan 2013 23:55:20 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect Registration
Thread-Index: Ac3q1vQVjnUSZGp4QGSRPD4cbWM9SQ==
Date: Fri, 04 Jan 2013 23:55:19 +0000
Message-ID: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.75]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B1680429673943669FE5FETK5EX14MBXC283r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(164054002)(31966008)(50986001)(47976001)(49866001)(5343635001)(33656001)(51856001)(16236675001)(56816002)(16297215001)(76482001)(5343645001)(53806001)(55846006)(5343655001)(54316002)(512954001)(47736001)(74502001)(59766001)(77982001)(74662001)(54356001)(15202345001)(15395725002)(16406001)(56776001)(4396001)(46102001)(44976002)(47446002)(59253001); DIR:OUT; SFP:; SCL:1; SRVR:BL2FFO11HUB039; LANG:en;
X-OriginatorOrg: microsoft.onmicrosoft.com
X-Forefront-PRVS: 0716E70AB6
Subject: [OAUTH-WG] Difference between client_update semantics in draft-ietf-oauth-dyn-reg and OpenID Connect 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: Fri, 04 Jan 2013 23:55:58 -0000

The client_update operation in http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-03 does something different than the operation upon which it was based from http://openid.net/specs/openid-connect-registration-1_0-13.html.  Specifically, while the OpenID Connect operation replaces all field values, the OAuth operation allows only selective fields to be replaced, designating fields to remain unchanged by specifying their value as the empty string ("").

I'm personally not happy with the change to the semantics of client field inclusion.  Updating some but not all fields is a substantially more complicated operation than replacing all fields.  Is there some use case that motivates this?  I don't think it's a substantial burden on the registering party to remember all the field values from the initial registration and then selectively use them for update operations, when needed.  Then the work goes to the (I suspect rare) parties that need partial update - not to every server.  It complicates the simple case, rather than pushing the complexity to the rare case, violating the design principle "make simple things simple and make more complicated things possible".

Is anyone opposed to updating the OAuth Registration semantics to match the Connect registration semantics?  Is so, why?

                                                                Thanks,
                                                                -- Mike