Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.

Phil Hunt <phil.hunt@oracle.com> Mon, 21 October 2013 18: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 A8C2111E8218 for <oauth@ietfa.amsl.com>; Mon, 21 Oct 2013 11:02:44 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.572
X-Spam-Level:
X-Spam-Status: No, score=-5.572 tagged_above=-999 required=5 tests=[AWL=-0.370, BAYES_00=-2.599, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=1.396, 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 12ZWOEeii7kp for <oauth@ietfa.amsl.com>; Mon, 21 Oct 2013 11:02:39 -0700 (PDT)
Received: from aserp1040.oracle.com (aserp1040.oracle.com [141.146.126.69]) by ietfa.amsl.com (Postfix) with ESMTP id 0343411E8137 for <oauth@ietf.org>; Mon, 21 Oct 2013 11:02:38 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by aserp1040.oracle.com (Sentrion-MTA-4.3.1/Sentrion-MTA-4.3.1) with ESMTP id r9LI2be8012560 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Mon, 21 Oct 2013 18:02:38 GMT
Received: from aserz7022.oracle.com (aserz7022.oracle.com [141.146.126.231]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LI2big005052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 21 Oct 2013 18:02:37 GMT
Received: from abhmt110.oracle.com (abhmt110.oracle.com [141.146.116.62]) by aserz7022.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id r9LI2bEb005044; Mon, 21 Oct 2013 18:02:37 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Mon, 21 Oct 2013 11:02:36 -0700
References: <E2658D78-4EF8-433F-B007-15457EE353C4@ve7jtb.com> <BBFA9BB8-5FE1-45CD-9BF7-422D80A5412A@oracle.com> <4E1F6AAD24975D4BA5B168042967394377E08E0B@TK5EX14MBXC286.redmond.corp.microsoft.com>
Mime-Version: 1.0 (1.0)
In-Reply-To: <4E1F6AAD24975D4BA5B168042967394377E08E0B@TK5EX14MBXC286.redmond.corp.microsoft.com>
Content-Type: multipart/alternative; boundary="Apple-Mail-26D70770-2B51-4238-8609-FCC5A43354A2"
Content-Transfer-Encoding: 7bit
Message-Id: <519B95AD-7286-4923-A09A-606AA5E676C6@oracle.com>
X-Mailer: iPhone Mail (11A501)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Mon, 21 Oct 2013 11:02:27 -0700
To: Mike Jones <Michael.Jones@microsoft.com>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Cc: oauth list <oauth@ietf.org>
Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.
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: Mon, 21 Oct 2013 18:02:44 -0000

Yes. But that does not use the signed jwt assertion which "locks" the registration profile.  

Phil

> On Oct 21, 2013, at 10:56, Mike Jones <Michael.Jones@microsoft.com> wrote:
> 
> For what it’s worth, the latest public dynamic registration working group draft has software_id and software_version fields to allow statements to be made about the fixed client software releases that are deployed many times, of which you speak.
>  
>                                                             -- Mike
>  
> From: oauth-bounces@ietf.org [mailto:oauth-bounces@ietf.org] On Behalf Of Phil Hunt
> Sent: Monday, October 21, 2013 10:21 AM
> To: John Bradley
> Cc: oauth list
> Subject: Re: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.
>  
> I am assuming that this draft fits with the dyn reg draft.  It makes the assumption that every single client is somehow potentially different in terms of registration.  This draft encodes the registration values in the JWT so that stateless registration can be achieved.
>  
> Dynamic registration takes a different view from client association, in that dynamic registration has no notion of fixed client software releases that are deployed many times. As such there is no fixed registration profile. Every client is potentially different. In contrast Client Association + Software statements, clients are identified as a particular software and are fixed. 
>  
> Have I read this correctly?
>  
> From a policy perspective, how would a service provider handle registration of clients that are all potentially different? Why would individual clients need to differ in registration (other than in the tokens negotiated with a particular deployment SP)?
>  
> Phil
>  
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>  
> On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com> wrote:
> 
> 
> A new version of I-D, draft-bradley-stateless-oauth-client-00.txt
> has been successfully submitted by John Bradley and posted to the
> IETF repository.
> 
> Filename:         draft-bradley-stateless-oauth-client
> Revision:         00
> Title:                Stateless Client Identifier for OAuth 2
> Creation date:  2013-10-15
> Group:              Individual Submission
> Number of pages: 4
> URL:             http://www.ietf.org/internet-drafts/draft-bradley-stateless-oauth-client-00.txt
> Status:          http://datatracker.ietf.org/doc/draft-bradley-stateless-oauth-client
> Htmlized:        http://tools.ietf.org/html/draft-bradley-stateless-oauth-client-00
> 
> 
> Abstract:
>   This draft provides a method for communicating information about an
>   OAuth client through its client identifier allowing for fully
>   stateless operation.
> 
> 
> 
> 
> 
> Please note that it may take a couple of minutes from the time of submission
> until the htmlized version and diff are available at tools.ietf.org.
> 
> The IETF Secretariat
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>