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

"Richer, Justin P." <> Mon, 21 October 2013 18:57 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id B853211E865A for <>; Mon, 21 Oct 2013 11:57:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -6.598
X-Spam-Status: No, score=-6.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id YegYg3pBJ5Cv for <>; Mon, 21 Oct 2013 11:57:27 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 0F35011E865C for <>; Mon, 21 Oct 2013 11:56:34 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 8ABD41F09AB; Mon, 21 Oct 2013 14:56:33 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG ( []) by (Postfix) with ESMTP id 6C3C11F099A; Mon, 21 Oct 2013 14:56:33 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS03.MITRE.ORG ([]) with mapi id 14.03.0158.001; Mon, 21 Oct 2013 14:56:33 -0400
From: "Richer, Justin P." <>
To: Phil Hunt <>
Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.
Thread-Index: AQHOzoIDOfxvQ4OI/0qr3oy130L/sJn/xI0A
Date: Mon, 21 Oct 2013 18:56:32 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_5120DE9DB3024754ADE13BE3679A5844mitreorg_"
MIME-Version: 1.0
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.
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: Mon, 21 Oct 2013 18:58:17 -0000

As it says in the draft, this could be used with dynamic registration, manual registration, or any other method of registration. How you get the client_id and the nature of the client_id are orthogonal to each other.

As such, you could easily issue this structured/signed stateless client_id in response to a signed software statement presented during either dynamic registration (which really should be a proper extension of dynamic registration). Alternatively, you can issue this client_id from a manual registration step and then you don't need to do a dynamic registration at the AS at all, since the AS can recognize and validate the contents of the client_id (because it's completely stateless).

 -- Justin

On Oct 21, 2013, at 10:21 AM, Phil Hunt <<>>

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)?



On 2013-10-14, at 5:01 PM, John Bradley <<>> 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

  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<>g/>.

The IETF Secretariat
OAuth mailing list<>

OAuth mailing list<>