IETF Logo Mail Archive

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

John Bradley <ve7jtb@ve7jtb.com> Sat, 05 January 2013 00:13 UTC

Return-Path: <ve7jtb@ve7jtb.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 B9BC721F87D6 for <oauth@ietfa.amsl.com>; Fri, 4 Jan 2013 16:13:56 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[AWL=0.898, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 A544m-o85nXb for <oauth@ietfa.amsl.com>; Fri, 4 Jan 2013 16:13:55 -0800 (PST)
Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ietfa.amsl.com (Postfix) with ESMTP id B250921F84E4 for <oauth@ietf.org>; Fri, 4 Jan 2013 16:13:55 -0800 (PST)
Received: by mail-vc0-f172.google.com with SMTP id fw7so17517694vcb.3 for <oauth@ietf.org>; Fri, 04 Jan 2013 16:13:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-received:content-type:mime-version:subject:from:in-reply-to:date :cc:message-id:references:to:x-mailer:x-gm-message-state; bh=ADyQ19IUT72IoMb4Uxdf39h899DCyk1B5qIQUzpvxNI=; b=U8s4qway1k7ChZ1xxLA+N/DrfcxC3c4O6Xlf5WkGmX6DLmXnOmyWIX8F1wvDNkzNzm C6VfY4MqesUvVsHGf7u/oIFxN979dpItynfFv6zCNatGeP2lCZAeNVaLInV6GNGNF8Ju lUhWTZSNJQOZ3PMRlqqEaAxcZx5sGvaIJEhWseSJi95Kz9W4xxKZ0uf3wuSk/BomHJuo rSslfHM0FdXjeD17U1eww5DHaxDoEagFaIJZvRyMvK4RPfaD3hrDvWwTkI8CBUKR0Gxm vOsNargVSwmTeY/wI84ZGe9AHl/fnRGWm4MNTjTyECBQol829rs0Q9IjgFKZD4gDtKah g15A==
X-Received: by 10.52.32.229 with SMTP id m5mr68428482vdi.5.1357344835139; Fri, 04 Jan 2013 16:13:55 -0800 (PST)
Received: from [192.168.1.211] (190-20-25-66.baf.movistar.cl. [190.20.25.66]) by mx.google.com with ESMTPS id z10sm47697912vds.17.2013.01.04.16.13.52 (version=TLSv1/SSLv3 cipher=OTHER); Fri, 04 Jan 2013 16:13:54 -0800 (PST)
Content-Type: multipart/alternative; boundary="Apple-Mail=_80A50A37-5DCC-498F-B70F-2CDE79FB1C5C"
Mime-Version: 1.0 (Mac OS X Mail 6.2 \(1499\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>
Date: Fri, 04 Jan 2013 21:13:45 -0300
Message-Id: <327DA8FF-D6D3-4823-9EC9-8D9D97CF8788@ve7jtb.com>
References: <4E1F6AAD24975D4BA5B1680429673943669FE5FE@TK5EX14MBXC283.redmond.corp.microsoft.com>
To: Mike Jones <Michael.Jones@microsoft.com>
X-Mailer: Apple Mail (2.1499)
X-Gm-Message-State: ALoCoQmPZkdeaJ0F5e0rAfsIdJYmVO4Tu69MIjBPagVLImS701oQ4chRlm9iELWyOu5MDQbEEync
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [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: Sat, 05 Jan 2013 00:13:56 -0000

We did discuss this issue in the connect WG.

The decision was made to always completely replace.   That prevents unknown states if a update fails.   

I think the always replace everything rule is simpler, though admittedly more bandwidth is required.  However bandwidth is not a significant factor for this as far as I know.

John B.

On 2013-01-04, at 8:55 PM, Mike Jones <Michael.Jones@microsoft.com> wrote:

> 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 fromhttp://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
>  
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth

v2.23.0 | Report a Bug | By Email