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 05:26 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6E42D11E8159 for <>; Sun, 20 Oct 2013 22:26:38 -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 gnanMSziGoNW for <>; Sun, 20 Oct 2013 22:26:30 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id AB2FC11E8153 for <>; Sun, 20 Oct 2013 22:26:27 -0700 (PDT)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 1A9D21F0526; Mon, 21 Oct 2013 01:26:27 -0400 (EDT)
Received: from IMCCAS03.MITRE.ORG ( []) by (Postfix) with ESMTP id E86D51F051D; Mon, 21 Oct 2013 01:26:26 -0400 (EDT)
Received: from IMCMBX01.MITRE.ORG ([]) by IMCCAS03.MITRE.ORG ([]) with mapi id 14.03.0158.001; Mon, 21 Oct 2013 01:26:26 -0400
From: "Richer, Justin P." <>
To: Pedro Felix <>
Thread-Topic: [OAUTH-WG] FYI per a request on the last conference call, this is a method for making client registration stateless.
Thread-Index: AQHOzh4WOjkR+xv0VkG8Vuns2tz0jQ==
Date: Mon, 21 Oct 2013 05:26:25 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_866CAAB13BA847769F539E2A461F1D44mitreorg_"
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 05:26:47 -0000

If you have a confidential client using a traditional symmetric secret, from the client's perspective you wouldn't pack the secret into the client_id with this method any more than you would pack it into the client_id using a normal method -- at least as far as the client is concerned, they're two separate and unrelated values, generally treated as opaque. Ideally with a stateless client you'd be using some kind of asymmetric key with the assertion profile or something like that for client auth, and I think that's going to be the most common case for people who are doing a truly stateless server environment, but there are a few other ways you could handle it.

As John points out in another thread, you could encrypt the claims set to the AS's key. This would let you put the secret itself directly inside the client_id without the client being able to muck about with it, and without exposing it to the browser or other agents that get the client_id (which, you must remember, is essentially public information).

Alternatively, you could tie the client ID to the secret by issuing a signed JWT as the client_secret as well, with the client_secret's JWT containing the same subject as the client_id's JWT.

There are probably some other tricks you could do, but these are the cleanest two that come to mind for me. Maybe others can fill in on what those might be.

 -- Justin

On Oct 15, 2013, at 5:06 AM, Pedro Felix <<>> wrote:


Is this applicable to public (non-confidential) clients only? For confidential clients, the verification of the client_secret doesn't seem to be addressed by this proposal (token endpoint interactions).
We could however extend it to address this scenario, namely by using encrypted JWTs with client_secret verification information.


On Tue, Oct 15, 2013 at 1:01 AM, 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<>