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

John Bradley <ve7jtb@ve7jtb.com> Thu, 05 March 2015 12:02 UTC

Return-Path: <ve7jtb@ve7jtb.com>
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 E9B5A1B29B8 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 04:02:59 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] 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 P9Kyz82FPMz3 for <oauth@ietfa.amsl.com>; Thu, 5 Mar 2015 04:02:57 -0800 (PST)
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id D166C1A1AA2 for <oauth@ietf.org>; Thu, 5 Mar 2015 04:02:56 -0800 (PST)
Received: by wghb13 with SMTP id b13so52914782wgh.0 for <oauth@ietf.org>; Thu, 05 Mar 2015 04:02:55 -0800 (PST)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:content-type:mime-version:subject:from :in-reply-to:date:cc:message-id:references:to; bh=ggSE2PlJytO33oAURSdGusfhnirH7Du+cI0JK82vT/M=; b=ea8w9CEqUm7fLFXBJ/xA5TCQn5AzPVUuL1A5g6OTrrLkcuMJfT2aWkP5OvWdCYAKaS T5UlzhgI2KO7sC8TiKDuDfvmNprRfOf1f15p4rWMM63Sxh/InHImC5X99TSxPAPDgNWy j1P/UmQVGx6MbYEk/Z11kutEdgXNt1bkMMlLzulsVv2PMCLz0TDNzeWsDvK5cm3GF5zd dMRu5fO6jfFlro59MxWlkJivaHRjrDTwtzVnJxugPYz9eC030iEw1XZzyVq1+B52nd+Z EFnI2OLqBQ16ebNiisCnzS1Uw3TPl9RsTEx+RI5dtte+BHUgGnusH+1aQjfnUBMgKYLl 123w==
X-Gm-Message-State: ALoCoQmS7K/FAQZjK2c1EOVuUNWIHWPKBP1kK/XSsqEfyijuk6jHVLGVqUsy3214cjfP57qxw7vl
X-Received: by 10.194.62.52 with SMTP id v20mr17597856wjr.137.1425556975592; Thu, 05 Mar 2015 04:02:55 -0800 (PST)
Received: from [10.6.0.209] ([95.211.146.166]) by mx.google.com with ESMTPSA id j7sm11357909wix.4.2015.03.05.04.02.43 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Thu, 05 Mar 2015 04:02:54 -0800 (PST)
Content-Type: multipart/signed; boundary="Apple-Mail=_33C3D253-32E9-4384-8B18-8312BC709652"; protocol="application/pkcs7-signature"; micalg=sha1
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
From: John Bradley <ve7jtb@ve7jtb.com>
In-Reply-To: <54F84347.5040705@mit.edu>
Date: Thu, 5 Mar 2015 13:02:32 +0100
Message-Id: <431F49E0-2356-4EF3-A22C-33B81EAB5301@ve7jtb.com>
References: <54F84013.9090004@gmx.net> <54F84347.5040705@mit.edu>
To: Justin Richer <jricher@mit.edu>
X-Mailer: Apple Mail (2.2070.6)
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/4u22L_1q-yf5mcrzPxSnRD0JIjg>
Cc: "oauth@ietf.org" <oauth@ietf.org>
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 12:03:00 -0000

The kid in the JWT is the most appropriate thing if the iss has reregistered a jwks_uri.   If you send a jwks_uri the AS needs to have some trust model to match the "iss" to that jwks_uri that we haven't described for Connect or Oauth at this point.

Mostly we have been sticking to jwks that are pushed durring registration or a jwks_uri that is pushed in registration or discovered based on the iss in Connect discovery.

Yes we need discovery for Oauth at some point.

The PoP key distribution needs a parameter to pass a kid if you are not passing the key.

John B.
> On Mar 5, 2015, at 12:51 PM, Justin Richer <jricher@mit.edu> wrote:
> 
> 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 <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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth <https://www.ietf.org/mailman/listinfo/oauth>
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth