Re: [OAUTH-WG] Dynamic Client Registration & Key Naming of JWKS

Justin Richer <jricher@mit.edu> Thu, 05 March 2015 11:51 UTC

Return-Path: <jricher@mit.edu>
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 382971B2C35 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 03:51:55 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, 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 yYiG2RtC57hz for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 03:51:52 -0800 (PST)
Received: from dmz-mailsec-scanner-8.mit.edu (dmz-mailsec-scanner-8.mit.edu [18.7.68.37]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 049691B29B9 for <oauth@ietf.org>; Thu, 5 Mar 2015 03:51:45 -0800 (PST)
X-AuditID: 12074425-f79846d0000054e1-e9-54f84350c308
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-8.mit.edu (Symantec Messaging Gateway) with SMTP id C3.53.21729.05348F45; Thu, 5 Mar 2015 06:51:44 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id t25BphWf001877; Thu, 5 Mar 2015 06:51:44 -0500
Received: from [192.168.128.57] (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t25Bpgoq015879 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Thu, 5 Mar 2015 06:51:43 -0500
Message-ID: <54F84347.5040705@mit.edu>
Date: Thu, 05 Mar 2015 06:51:35 -0500
From: Justin Richer <jricher@mit.edu>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0
MIME-Version: 1.0
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>, "oauth@ietf.org" <oauth@ietf.org>
References: <54F84013.9090004@gmx.net>
In-Reply-To: <54F84013.9090004@gmx.net>
Content-Type: multipart/alternative; boundary="------------080400060206090400070409"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphleLIzCtJLcpLzFFi42IR4hTV1g1w/hFi8P+gpsXSnfdYLU6+fcXm wOSxeNN+No8lS34yBTBFcdmkpOZklqUW6dslcGX8/HeEvWCtRcXW9vWsDYwNOl2MnBwSAiYS V5q/skLYYhIX7q1n62Lk4hASWMwkcfvUBShnA6PEu8Or2CGcW0wShx+3MnUxcnDwCqhJTOzJ B+lmEVCVODb/NAuIzQZkT1/TwgRiiwpESfT86WYDsXkFBCVOznwCViMiECtx6e8JsM3CAh4S 93fdYQSxhYBGft46jR3E5hRQl3j5Zw5YnFkgTOL0u91MExj5ZyEZNQtJCsK2lbgzdzczhC0v sf3tHChbV2LRthXsMPHmrbOZFzCyrWKUTcmt0s1NzMwpTk3WLU5OzMtLLdK10MvNLNFLTSnd xAgKbHYX1R2MEw4pHWIU4GBU4uGdsfF7iBBrYllxZe4hRkkOJiVR3mDjHyFCfEn5KZUZicUZ 8UWlOanFhxglOJiVRHjztYByvCmJlVWpRfkwKWkOFiVx3k0/+EKEBNITS1KzU1MLUotgsjIc HEoSvDpOQI2CRanpqRVpmTklCGkmDk6Q4TxAw986ggwvLkjMLc5Mh8ifYlSUEufdCZIQAElk lObB9cISzytGcaBXhHl1QVbwAJMWXPcroMFMQIO1xMAGlyQipKQaGNOvqMYsjX/amuRUY5um 9Sz9yZE0+0Wu2y5ndy7c9isy5tOWAt1nmQmPmxSOBRT1KKhu8WqKvp7d0L7Ot875vNLK9S1B 5/72TbXlXHjz+P6u5HurtiQWCDueuHBtXeK3nMXT2O8s2RPBcWplY1lBeNyNF/nRclbL26oU jugVdX04pagT+vHQFCWW4oxEQy3mouJEAJTQzy8XAwAA
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/xeqvjPoLkD_9sz1icIE3N5oc2uA>
Subject: Re: [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:51:55 -0000

If you're using them for the token endpoint, you set your 
token_endpoint_authorization_method to a method that supports it (which 
we don't define in OAuth but other protocols and profiles do). Then 
you'll usually reference them using the 'kid' field defined in JWK, or 
you might just use the only key that's been registered (it's very common 
for a client  to have only one key), or you might pass the JWK URI 
directly (in the "jku" header), or several other methods. If you're 
using them for some other piece of interaction (of which there are 
several defined and in the wild already), then the same rubric applies. 
This is all discussed in the JOSE documents, such as this section in JWS:

https://tools.ietf.org/html/draft-ietf-jose-json-web-signature-41#appendix-D

What we're providing is a hook for higher level protocols, not a 
determination of how exactly to use it. All of these uses will reference 
back to the client performing the action, which can be correlated to the 
JWK set referenced in the registration below.

  -- Justin

On 3/5/2015 6:37 AM, Hannes Tschofenig wrote:
> 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 mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth