[OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client

Phil Hunt <phil.hunt@oracle.com> Fri, 01 November 2013 19:02 UTC

Return-Path: <phil.hunt@oracle.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 33EA021E8251 for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 12:02:23 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.257
X-Spam-Level:
X-Spam-Status: No, score=-6.257 tagged_above=-999 required=5 tests=[AWL=0.341, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
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 Spmtss1bmHXJ for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 12:02:18 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 5969E21E80E1 for <oauth@ietf.org>; Fri, 1 Nov 2013 12:02:01 -0700 (PDT)
Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA1J1uxr000656 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for <oauth@ietf.org>; Fri, 1 Nov 2013 19:01:57 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1J1tPT003309 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for <oauth@ietf.org>; Fri, 1 Nov 2013 19:01:56 GMT
Received: from abhmt109.oracle.com (abhmt109.oracle.com [141.146.116.61]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id rA1J1tYO004859 for <oauth@ietf.org>; Fri, 1 Nov 2013 19:01:55 GMT
Received: from [192.168.1.12] (/174.7.250.104) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Fri, 01 Nov 2013 12:01:55 -0700
From: Phil Hunt <phil.hunt@oracle.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4CF5D818-DDA2-40C0-BB2E-921B3BBA4B0F"
Message-Id: <F4DD5BCF-D5C3-4C67-9B05-0F235A7B9431@oracle.com>
Date: Fri, 1 Nov 2013 12:01:47 -0700
To: oauth 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]
Subject: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client
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, 01 Nov 2013 19:02:23 -0000

I would like to encourage people to read the client association draft before monday. http://tools.ietf.org/html/draft-hunt-oauth-client-association-00.txt and the related http://tools.ietf.org/html/draft-hunt-oauth-software-statement-00.txt

Most of the draft just focuses on background and taxonomy. If you are not interested, focus in on the dynamic association section. I believe you will find this alternate stateless approach to be very simple to implement and uses a well established pattern.

My position is that while the new approach represents a major change to OIDC implementors, the benefits outweigh the costs as it will make Connect much easier to support for service providers.

The key difference in approaches is that the software statement serves as a way to lock-down registration profiles that allow servers (and their policy systems) to recognize different types of client software.   Note that nothing about using software statements prevents developers from self-asserting registration.  Those scenarios can continue to work.   The key benefit to service providers and client developers is that the number of variations for registration options is dramatically reduced. The registration becomes a simple assertion swap with any allowable per-client overrides as an exception rather than the norm.

IOW -- client association places different emphasis on what happens when.  Client association assumes software characteristics are known at packaging time and does not vary widely (from the client side) other than having to handle different authentication policies of the various service providers.

I've already spent more text here explaining the difference than the core of the draft takes to explain the registration. So please read the draft before our discussion on monday.

Phil

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