[OAUTH-WG] Dynamic Client Registration & Key Naming of JWKS
Hannes Tschofenig <hannes.tschofenig@gmx.net> Thu, 05 March 2015 11:38 UTC
Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36D301A1B17 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 03:38:01 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZfAcE4KSmfuP for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 03:38:00 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5E8D41A872F for <oauth@ietf.org>; Thu, 5 Mar 2015 03:37:58 -0800 (PST)
Received: from [192.168.131.142] ([80.92.121.102]) by mail.gmx.com (mrgmx003) with ESMTPSA (Nemesis) id 0MhRUQ-1Y7zEc2lAw-00MdIw for <oauth@ietf.org>; Thu, 05 Mar 2015 12:37:56 +0100
Message-ID: <54F84013.9090004@gmx.net>
Date: Thu, 05 Mar 2015 12:37:55 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="S4M1cbldI6pT1QjK9dMX05jroK4q8RRgC"
X-Provags-ID: V03:K0:N4Rb8GrvvZNkNmVYvfMEuGtAa1yzHtBYuF/pcCgXCqIx+vvYvwp zNzADNUa8SBauUrfnSwtl81AQQHvfCGQdJwUlop+VA8cQJv9xNgkDj481GZyEN+MTXxwu6n HAXRCNI8xd+PD8p2Q93okVVLYQtPc4oa6qsVw4+j81StiVZiovWD6SZPsnacbQwh2xcjcTg I9H9kmiI0h30mWdonySAg==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/VLEFz_4ehoqPdAMSMqwLjXWMDos>
Subject: [OAUTH-WG] Dynamic Client Registration & Key Naming of JWKS
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 05 Mar 2015 11:38:01 -0000
Hi Justin, Hi all, In context of the draft-ietf-oauth-pop-key-distribution-01 update we just ran into a question regarding key naming. The Dynamic Client Registration Protocol defines these two parameters that allow a client to upload a public key to the authorization server: jwks_uri URL referencing the client's JSON Web Key Set [JWK] document, which contains the client's public keys. The value of this field MUST point to a valid JWK Set document. These keys can be used by higher level protocols that use signing or encryption. For instance, these keys might be used by some applications for validating signed requests made to the token endpoint when using JWTs for client authentication [OAuth.JWT]. Use of this parameter is preferred over the "jwks" parameter, as it allows for easier key rotation. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response. jwks Client's JSON Web Key Set [JWK] document value, which contains the client's public keys. The value of this field MUST be a JSON object containing a valid JWK Set. These keys can be used by higher level protocols that use signing or encryption. This parameter is intended to be used by clients that cannot use the "jwks_uri" parameter, such as native clients that cannot host public URLs. The "jwks_uri" and "jwks" parameters MUST NOT both be present in the same request or response. Now, the question is how these keys are actually referenced? What do I need to indicate to select a specific key when I want to use these keys. Ciao Hannes
- [OAUTH-WG] Dynamic Client Registration & Key Nami… Hannes Tschofenig
- Re: [OAUTH-WG] Dynamic Client Registration & Key … Justin Richer
- Re: [OAUTH-WG] Dynamic Client Registration & Key … John Bradley