[OAUTH-WG] draft-bradley-stateless-oauth-client-00
Hannes Tschofenig <hannes.tschofenig@gmx.net> Fri, 01 November 2013 17:32 UTC
Return-Path: <hannes.tschofenig@gmx.net>
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 B7AD821E809A for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 10:32:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, USER_IN_WHITELIST=-100]
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 Md4iDbPHEk84 for <oauth@ietfa.amsl.com>; Fri, 1 Nov 2013 10:32:32 -0700 (PDT)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by ietfa.amsl.com (Postfix) with ESMTP id C32D411E8174 for <oauth@ietf.org>; Fri, 1 Nov 2013 10:32:31 -0700 (PDT)
Received: from masham-mac.home ([81.164.176.169]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0LlDb4-1WBuFU3H1S-00b6aX for <oauth@ietf.org>; Fri, 01 Nov 2013 18:32:30 +0100
Message-ID: <5273E5AD.7010408@gmx.net>
Date: Fri, 01 Nov 2013 18:32:29 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:17.0) Gecko/20130216 Thunderbird/17.0.3
MIME-Version: 1.0
To: oauth@ietf.org
Content-Type: text/plain; charset="ISO-8859-15"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:jPp8VQr88WGdBZ2zLnU06TreJY3tnQVSS6heu+tPyZWNTq1zzPS TZ1kh3ai+jYofn+CQI+owv/Qeq7/usbO8ExxZaeyRNcLl/BPV3i2PSrOxqTwIIJrG0BGlgS y6vwhQr+qK0Qm3lObJj8pE/bw06CnKeD6u0h9Z7qc3W0hrFI/X/iRIfUwJXbGUbDF4yyOHE X4g4vIHSW7Y+QZ+ldkpqg==
Subject: [OAUTH-WG] draft-bradley-stateless-oauth-client-00
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: Fri, 01 Nov 2013 17:32:36 -0000
Hi John, Hi all, I read your document and here a few remarks. In the dynamic client registration conference calls the topic of the stateless client was raised since there was the argument in the air that the current OAuth 2.0 RFC requires clients to be stateless due to the nature of the client identifier. It seems that you have found a way to make the client stateless with regard to the client identifier (i.e., that the authorization server does not need to store information about the client) by dumping state information in the client identifier itself. In your case you use a JWT, which is clever. Since RFC 6749 explicitly says that the client identifier string size is left undefined and that the client should avoid making assumptions about the identifier size I don't see a problem with the proposed approach. Now, there is one issue that I am wondering about. The client identifier itself is not sufficient for authorizing the client (for confidential clients). Instead, there is typically the need to have a secret. Now, the secret is not conveyed in the JWT, at least not in the way you have define it. You could of course do that and there is a document that provides prior art, see http://www.ietf.org/rfc/rfc5077 The story essentially is that the structure (JWT in your case) includes the key but of course then you have to encrypt the entire blob. In the case of public clients wouldn't you want to mandate at least a digital signature or a keyed message digest for the JWT since otherwise there is the risk that the client changes some of the parameters to impersonate someone? A few other questions: * You write: "The issuer SHOULD sign the JWT with JWS in such a way that the signature can be verified by the authorization server. " I believe what you want to say is the following: The authorization creates the client identifier (using the JWT) and the client does not parse the received content since it treats it as opaque. However, the authorization server MUST be able to process and verify received client identifiers it previously created, which requires to apply cryptographic processing when a JWT is signed (using a JWS) and when a JWT is encrypted (using a JWE). (I ignore the issue that I believe the JWT needs to be signed [for public clients] and encrypted [for confidential clients].) * You should submit the document as draft-bradley-oauth; this makes it easier to find the document. * You write: " The issuer MAY encrypt the JWT with JWE. " I think you want to be stronger by saying that JWE MUST be used when the authorization server wants to apply confidentiality protection of the JWT. While the authorization server could use other techniques as well the purpose of the document is to describe one way to accomplish the goal and therefore it makes sense to be specific. I would even go as far as suggesting specific algorithms to use, as an example. * Although not stated directly I believe you allow the client identifier to be created by a party other than the authorization server. While this would theoretically make sense wouldn't it be useful to just assume that the issuer is the authorization server? Ciao Hannes
- [OAUTH-WG] draft-bradley-stateless-oauth-client-00 Hannes Tschofenig
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… John Bradley
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Hannes Tschofenig
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Nat Sakimura
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Richer, Justin P.
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Anthony Nadalin
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Nat Sakimura
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… John Bradley
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Nat Sakimura
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Nat Sakimura
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Anthony Nadalin
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… John Bradley
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Phil Hunt
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Anthony Nadalin
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Richer, Justin P.
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… John Bradley
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… John Bradley
- Re: [OAUTH-WG] draft-bradley-stateless-oauth-clie… Phil Hunt