IETF Logo Mail Archive

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

Mike Jones <Michael.Jones@microsoft.com> Mon, 21 October 2013 17:58 UTC

Return-Path: <Michael.Jones@microsoft.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 2CE9811E83AF for <oauth@ietfa.amsl.com>; Mon, 21 Oct 2013 10:58:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.49
X-Spam-Level:
X-Spam-Status: No, score=-3.49 tagged_above=-999 required=5 tests=[AWL=0.108, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1]
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 yib2nuEMbQod for <oauth@ietfa.amsl.com>; Mon, 21 Oct 2013 10:57:58 -0700 (PDT)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2lp0210.outbound.protection.outlook.com [207.46.163.210]) by ietfa.amsl.com (Postfix) with ESMTP id 03BAD11E832C for <oauth@ietf.org>; Mon, 21 Oct 2013 10:57:38 -0700 (PDT)
Received: from BL2PR03CA015.namprd03.prod.outlook.com (10.141.66.23) by BL2PR03MB099.namprd03.prod.outlook.com (10.255.230.22) with Microsoft SMTP Server (TLS) id 15.0.785.10; Mon, 21 Oct 2013 17:57:36 +0000
Received: from BN1BFFO11FD041.protection.gbl (2a01:111:f400:7c10::143) by BL2PR03CA015.outlook.office365.com (2a01:111:e400:c1b::23) with Microsoft SMTP Server (TLS) id 15.0.800.7 via Frontend Transport; Mon, 21 Oct 2013 17:57:36 +0000
Received: from mail.microsoft.com (131.107.125.37) by BN1BFFO11FD041.mail.protection.outlook.com (10.58.53.199) with Microsoft SMTP Server (TLS) id 15.0.805.12 via Frontend Transport; Mon, 21 Oct 2013 17:57:36 +0000
Received: from TK5EX14MBXC286.redmond.corp.microsoft.com ([169.254.1.212]) by TK5EX14HUBC102.redmond.corp.microsoft.com ([157.54.7.154]) with mapi id 14.03.0158.002; Mon, 21 Oct 2013 17:56:50 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Phil Hunt <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>
Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.
Thread-Index: AQHOyTnWK6Aumw1QBUOu6SY4hC1n9Jn/cYGAgAAJSzA=
Date: Mon, 21 Oct 2013 17:56:49 +0000
Message-ID: <4E1F6AAD24975D4BA5B168042967394377E08E0B@TK5EX14MBXC286.redmond.corp.microsoft.com>
References: <E2658D78-4EF8-433F-B007-15457EE353C4@ve7jtb.com> <BBFA9BB8-5FE1-45CD-9BF7-422D80A5412A@oracle.com>
In-Reply-To: <BBFA9BB8-5FE1-45CD-9BF7-422D80A5412A@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [157.54.51.35]
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B168042967394377E08E0BTK5EX14MBXC286r_"
MIME-Version: 1.0
X-Forefront-Antispam-Report: CIP:131.107.125.37; CTRY:US; IPV:CAL; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(30513003)(377424004)(69234005)(377454003)(24454002)(199002)(189002)(52084003)(55846006)(74502001)(16236675002)(31966008)(56776001)(15975445006)(76796001)(54316002)(76482001)(56816003)(20776003)(77096001)(81816001)(47446002)(79102001)(66066001)(65816001)(77982001)(81686001)(16601075003)(15974865002)(80022001)(54356001)(59766001)(19300405004)(76786001)(14971765001)(74876001)(74706001)(63696002)(80976001)(74662001)(4396001)(44976005)(46102001)(51856001)(6806004)(83072001)(47976001)(50986001)(85306002)(19580405001)(19580395003)(83322001)(53806001)(512954002)(69226001)(15202345003)(84326002)(49866001)(33656001)(47736001)(81342001)(85806002)(81542001)(71186001)(74366001); DIR:OUT; SFP:; SCL:1; SRVR:BL2PR03MB099; H:mail.microsoft.com; CLIP:131.107.125.37; FPR:; RD:InfoDomainNonexistent; A:1; MX:1; LANG:en;
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 00064751B6
X-OriginatorOrg: DuplicateDomain-a84fc36a-4ed7-4e57-ab1c-3e967bcbad48.microsoft.com
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 17:58:09 -0000

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<http://www.independentid.com>
phil.hunt@oracle.com<mailto:phil.hunt@oracle.com>

On 2013-10-14, at 5:01 PM, John Bradley <ve7jtb@ve7jtb.com<mailto: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<http://tools.ietf.org/>g/>.

The IETF Secretariat
_______________________________________________
OAuth mailing list
OAuth@ietf.org<mailto:OAuth@ietf.org>
https://www.ietf.org/mailman/listinfo/oauth

v2.8.10 | Report a Bug | By Email