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

Phil Hunt <> Sun, 03 November 2013 18:13 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DF97C11E82CA for <>; Sun, 3 Nov 2013 10:13:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.603
X-Spam-Status: No, score=-5.603 tagged_above=-999 required=5 tests=[AWL=-0.401, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id SJxthTNy2WSD for <>; Sun, 3 Nov 2013 10:13:15 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id C9E8411E80F8 for <>; Sun, 3 Nov 2013 10:13:15 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id rA3IDD2c008927 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 3 Nov 2013 18:13:14 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id rA3IDC57004951 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sun, 3 Nov 2013 18:13:13 GMT
Received: from ( []) by (8.14.4+Sun/8.14.4) with ESMTP id rA3IDC5L004948; Sun, 3 Nov 2013 18:13:12 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sun, 03 Nov 2013 10:13:12 -0800
References: <> <>
Mime-Version: 1.0 (1.0)
In-Reply-To: <>
Content-Type: multipart/alternative; boundary=Apple-Mail-C0B8F3D3-5817-459D-9A1C-7EA351DC0654
Content-Transfer-Encoding: 7bit
Message-Id: <>
X-Mailer: iPhone Mail (11B511)
From: Phil Hunt <>
Date: Sun, 3 Nov 2013 10:13:09 -0800
To: Nat Sakimura <>
X-Source-IP: []
Cc: oauth list <>
Subject: Re: [OAUTH-WG] Client Association alternative to Dyn Reg and stateless oauth client
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 03 Nov 2013 18:13:21 -0000


I think software_id was equiv to class_id. The statement is intended to "lock" the reg profile between instances. 

The url returned could have another meta attr indicating what type of endpoint it is. Eg. Dyn reg, scim etc. 


> On Nov 3, 2013, at 5:05, Nat Sakimura <> wrote:
> Thanks Phil. 
> This is largely in-line with what I have been looking for since 2011 or so. 
> Instead of "software id", I was using the term "client class id" but that would be more or less equivalent, though I like "client class id" better than "software id" as a piece of software may imply client instance as well. 
> I further was thinking that "client class id" should be a URI from which the authorization server can pull the "software statement"/"class properties" so that signing it would be optional and it could simply be a plain JSON. That would make it easier to fix the "software statement" bugs and adding more values (e.g. more language support) at a later date. 
> As to the "association" is concerned, it would be really nice if the response includes the link relationship in the response JSON like in . By doing so, the client instance can learn which authorization endpoint and so on that it should use [1]. This would allow the server to assign different endpoints to different client instances for scalability, security, billing and all sorts of other reasons. It would also achieve HATEOAS. 
> As to the relationship with the dynreg draft is concerned, I kind of see dynreg as an API to talk to the software publisher. 
> [1] I think it would be better return the discovery endpoint and have the client figure out where is its authorization endpoint than returning authorization endpoint directly but it can be either way. 
> Cheers, 
> Nat
> 2013/11/2 Phil Hunt <>
>> I would like to encourage people to read the client association draft before monday. and the related
>> 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
>> _______________________________________________
>> OAuth mailing list
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> @_nat_en