Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 14 July 2014 17:45 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 900221A8BAF for <oauth@ietfa.amsl.com>; Mon, 14 Jul 2014 10:45:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.551
X-Spam-Level:
X-Spam-Status: No, score=-2.551 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.651, 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 39LuN0Lnrndn for <oauth@ietfa.amsl.com>; Mon, 14 Jul 2014 10:45:17 -0700 (PDT)
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 84CC31A0AF9 for <oauth@ietf.org>; Mon, 14 Jul 2014 10:45:17 -0700 (PDT)
Received: from [172.16.254.119] ([80.92.116.212]) by mail.gmx.com (mrgmx002) with ESMTPSA (Nemesis) id 0LsCdj-1WQur506Jz-013yzl; Mon, 14 Jul 2014 19:45:08 +0200
Message-ID: <53C41721.7020607@gmx.net>
Date: Mon, 14 Jul 2014 19:45:05 +0200
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Mike Jones <Michael.Jones@microsoft.com>, Brian Campbell <bcampbell@pingidentity.com>, John Bradley <ve7jtb@ve7jtb.com>
References: <53BBDF5B.3020904@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA0841@TK5EX14MBXC294.redmond.corp.microsoft.com> <2CAA155D-E87E-4465-9110-C142D7085A56@ve7jtb.com> <CA+k3eCSmhKor+N-H8gt_GtQ7-4b1tVjS2n+hUpOmOawJWThBMQ@mail.gmail.com> <53C3A5F2.908@gmx.net> <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com>
In-Reply-To: <4E1F6AAD24975D4BA5B16804296739439ADA8D92@TK5EX14MBXC294.redmond.corp.microsoft.com>
X-Enigmail-Version: 1.5.2
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="KxlREa47Ntv2OhNsAEPdfn39DLkKFP3bV"
X-Provags-ID: V03:K0:22ep6RfQpUDUwu12F/Dqlp/La4H3z6M4QDgv+kJLaznzLAsKY94 zDAb87m8tbBRkaPDcvpWGJ6gBVYJHU3wG0Z6tELQqgCq/FZisbtvHV4BK9xjPKMjOa7Frk6 0zyOr7NDiQNf9Y89JGeGBVLyZMJxf3MbWTo6jpLa5anCk65gfJZQ3hSAPTD1q/km636pej+ qOa2Ou+Ih5c+J4zOG8edg==
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/5vvbfB7ZGqX0Pi79WNHOdHcI1t4
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Dynamic Client Registration: jwks / jwks_uri
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: Mon, 14 Jul 2014 17:45:19 -0000

Hi Mike,

sticking with working group document is fine.

However, the first example does not make sense to me.
[maybe my brain is a bit empty at the moment]

When is a JWT signed by the client and then sent to the Authorization
Server other than in the Assertion draft that I mention in the second
example?

Ciao
Hannes

On 07/14/2014 06:16 PM, Mike Jones wrote:
> I'd rather that we stayed with working group drafts in the examples.
> So I would counter-propose the following text:
> 
> "The public key(s) referenced by "jwks_uri" (or contained in the
> "jwks") can be used in a variety of use cases. For example, the
> signature of a JWT [I-D.ietf-json-web-token] signed by the client can
> be verified by the authorization server using these keys.  Another
> example is that the authorization server can use the indicated public
> keys to verify a request to the token endpoint that utilizes the JWT
> assertion profile as described in Section 4.2 of
> [I-D.ietf-oauth-assertions]."
> 
> -- Mike
> 
> -----Original Message----- From: OAuth
> [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig Sent:
> Monday, July 14, 2014 2:42 AM To: Brian Campbell; John Bradley Cc:
> oauth@ietf.org Subject: Re: [OAUTH-WG] Dynamic Client Registration:
> jwks / jwks_uri
> 
> What about the following text:
> 
> jwks_uri
> 
> .... <previous text in Section 2 of 
> http://tools.ietf.org/html/draft-ietf-oauth-dyn-reg-18> .....
> 
> "The public key(s) referenced by jwks_uri (or contained in the jwks)
> can be used in a variety of use cases. For example, the AS can use
> the indicated public key to verify a request to the token endpoint
> that utilizes the JWT assertion profile as described in Section 4.2
> of [I-D.ietf-oauth-assertions]. Another use case is for the AS to use
> the public key of a client to encrypt a symmetric proof-of-possession
> key sent to the client, as described in Section 4.2 of
> [I-D.bradley-oauth-pop-key-distribution]."
> 
> 
> Ciao Hannes
> 
> 
> 
> 
> 
> 
> 
> On 07/08/2014 09:43 PM, Brian Campbell wrote:
>> +1 to John's #3. The others could maybe be described in somewhat 
>> abstract terms as examples of those "higher level protocols that
>> use signing or encryption."
>> 
>> On Tue, Jul 8, 2014 at 12:33 PM, John Bradley <ve7jtb@ve7jtb.com>
>> wrote:
>>> In Connect these public keys are used to: 1 verify the signature
>>> of request objects (Signed Requests), something not in OAuth yet,
>>> and part of what the description calls higher level protocols. 2
>>> encrypt the responses from the user_info endpoint or id_token
>>> (also not part of OAuth directly at this point)
>>> 
>>> 3 validate requests to the token endpoint authenticated by the
>>> JWT assertion profile I think this is legitimate OAuth use.
>>> 
>>> Whew for the PoP specs: 4 used to encrypt the symmetric proof key
>>> in a JWK sent  to the client 
>>> http://tools.ietf.org/html/draft-bradley-oauth-pop-key-distribution-0
>>>
>>> 
1#page-7
>>> 5 used to provide a PoP key for the client to the AS as part of
>>> registration rather than passing the JWK on each request to the
>>> token endpoint.
>>> 
>>> So the keys in the JWK can be used a number of ways by the AS.
>>> 
>>> I think we could reference 3 and 4 as examples to be safe.
>>> 
>>> John B.
>>> 
>>> 
>>> On Jul 8, 2014, at 3:04 PM, Mike Jones
>>> <Michael.Jones@microsoft.com> wrote:
>>> 
>>>> Was there specific language that had been discussed to be added
>>>> for this?  If not, could someone please create some?
>>>> 
>>>> Thanks, -- Mike
>>>> 
>>>> -----Original Message----- From: OAuth
>>>> [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig 
>>>> Sent: Tuesday, July 08, 2014 5:09 AM To: oauth@ietf.org 
>>>> Subject: [OAUTH-WG] Dynamic Client Registration: jwks /
>>>> jwks_uri
>>>> 
>>>> Hi all,
>>>> 
>>>> in my earlier review I had noted that the semantic of the
>>>> fields is underspecified, i.e., it is not clear what these
>>>> fields are used for.
>>>> 
>>>> In private conversations I was told that an informal reference
>>>> to a potential use case will be added. I don't see such
>>>> reference with version -18.
>>>> 
>>>> Ciao Hannes
>>>> 
>>>> _______________________________________________ OAuth mailing
>>>> list OAuth@ietf.org 
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>> 
>>> _______________________________________________ OAuth mailing
>>> list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>> 
>> _______________________________________________ OAuth mailing list 
>> OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
>> 
>