[OAUTH-WG] Thoughts from this mornings dyn reg discussion

Phil Hunt <phil.hunt@oracle.com> Tue, 04 March 2014 17:18 UTC

Return-Path: <phil.hunt@oracle.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 923351A026B for <oauth@ietfa.amsl.com>; Tue, 4 Mar 2014 09:18:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.746
X-Spam-Level:
X-Spam-Status: No, score=-4.746 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.547, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 6XCcHYjxNQdB for <oauth@ietfa.amsl.com>; Tue, 4 Mar 2014 09:18:30 -0800 (PST)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) by ietfa.amsl.com (Postfix) with ESMTP id 52E3E1A0264 for <oauth@ietf.org>; Tue, 4 Mar 2014 09:18:30 -0800 (PST)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s24HIQ63030862 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Tue, 4 Mar 2014 17:18:27 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s24HIPY9007674 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Tue, 4 Mar 2014 17:18:26 GMT
Received: from abhmp0005.oracle.com (abhmp0005.oracle.com [141.146.116.11]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s24HIPib001623 for <oauth@ietf.org>; Tue, 4 Mar 2014 17:18:25 GMT
Received: from dhcp-hotel-wifi-156-0b.meeting.ietf.org (/130.129.156.11) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 04 Mar 2014 09:18:25 -0800
From: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_E9A2FFC7-3A38-415C-9892-F26BB5B27447"
Message-Id: <629DE80D-5682-4DF3-9626-8150E74BBB76@oracle.com>
Date: Tue, 04 Mar 2014 17:18:19 +0000
To: "oauth@ietf.org list" <oauth@ietf.org>
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
X-Mailer: Apple Mail (2.1510)
X-Source-IP: ucsinet21.oracle.com [156.151.31.93]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/NxiC-sIDuCT1RRRwsUvsGHFgwIE
Subject: [OAUTH-WG] Thoughts from this mornings dyn reg discussion
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Tue, 04 Mar 2014 17:18:39 -0000

Keeping the conversation from this morning going…

This morning I raised the issue that it is not clear to my as to why a client would need to "manage" its registration (note: I think this analysis applies equally to both the the management draft and the earlier SCIM profile I published). What would drive need for a management API would have to come from some lifecycle event in the client software:

1.  A new client registers for the very first time (no pre-existing client_id)
2.  A client, having registered before is updated in some way (e.g. has a new software statement) where some of its registration information has changed. How can the client notify the server  of the change without loosing current authorizations (to maintain user-experience)
3.  A client, wants (e.g. because of administrative re-configuration?) to change its registration information
4.  A client needs to "rotate" its client credential (client_secret, nego new key etc)
5.  A client wishes to de-register
6.  A resource server changes its policies. Eg. requiring the client to get a new credential type
7.  Others?  e.g. meta data change because of a change in language by the user?

My view is that most cases can be handled by what is already in the core dyn reg draft (maybe with some explanation). Even when a client updates frequently (as Justin mentions), it does not seem like they would change their metadata between software updates.  The only case I can think of is web clients which may be re-configured. But wouldn't they be handled through OOB administration rather than use dyn reg?

Phil

@independentid
www.independentid.com
phil.hunt@oracle.com