Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata

Hannes Tschofenig <hannes.tschofenig@gmx.net> Mon, 06 March 2017 15:38 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 0BE8D12951E for <oauth@ietfa.amsl.com>; Mon, 6 Mar 2017 07:38:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.602
X-Spam-Level:
X-Spam-Status: No, score=-2.602 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
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 AGW5qIeltxUT for <oauth@ietfa.amsl.com>; Mon, 6 Mar 2017 07:38:08 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (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 459C6129525 for <oauth@ietf.org>; Mon, 6 Mar 2017 07:38:06 -0800 (PST)
Received: from [192.168.91.177] ([80.92.114.23]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0LkTSx-1c9f5B0SPD-00cMpv; Mon, 06 Mar 2017 16:37:58 +0100
To: Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>
References: <c0ad73c9-4d4b-d62b-2782-c060037deb7d@gmx.net> <CY4PR21MB0504DD37A2BE778F76D6B14EF55E0@CY4PR21MB0504.namprd21.prod.outlook.com>
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
Openpgp: id=071A97A9ECBADCA8E31E678554D9CEEF4D776BC9
Message-ID: <96b7e141-26a0-f48a-4cc4-5964ae78db42@gmx.net>
Date: Mon, 06 Mar 2017 16:37:56 +0100
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0
MIME-Version: 1.0
In-Reply-To: <CY4PR21MB0504DD37A2BE778F76D6B14EF55E0@CY4PR21MB0504.namprd21.prod.outlook.com>
Content-Type: multipart/signed; micalg="pgp-sha512"; protocol="application/pgp-signature"; boundary="emxrtKaTU2Ra6R26ub7goxpNP4X1s0aHF"
X-Provags-ID: V03:K0:279nEFsDdZ+zpxeFYmsW1SISEnz4aCBXP3dcRnxZm1vhR7nDurj IoCBMRjFdbSPAUVRtN4Dgkpb0/u9pgwkrunUid576paBJqsX06+P7oQKepXnKK8RvJLDa/D +ivi8g0EzaNAo7wIJaF7KjRNor1u3dnjSkWxIm9hl4lBwtADzbL4eU1Kr0OnX7l/WMUhpdg m15Iw36fbwAH+aTJ5rKcQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:yo7uJQa5tFg=:2G/A1MCFEhZGGSKyV8oHnq y+eBRnDACAYbqg+KZQe1nlSnE0wIYzRRyh0CxaQmmp/IsSkMEr1ZV4mIiAxB33U/dFSPGCLUf KuU1lanGLAU76Ribpcv/IOJmXK34ddr+uY1+UhR8Tnji5ILHedsHwMz/LG0T4w34CQ9isNYUF 5itqKPnoxEQSasEUsM/50JmNzVyLjPkkFlZl0UJc/nhCM3Tje8+cLaYyeApwteB+6+AhUOmtN EvMFUplsnEI7nSedWjqpJSP1b+bxFZYw0VKOhrycQazXPEVb8ZT9h+a4KGjco9isGcqYPf1C6 a4WLgxZft79jqrCpAFIw+pwTflzH2RVPrnGMu1BDZh8oI/KGdC7TxfWN1PCdnPtGL/zeyi4bN mXBwl6jHrnxaSuIYWSlL1oFnbSEQUxijuyfIGM74kz2/kZCMkVg6NffzL5GrTpjKYHdSI9qvb AgVsDV6JeNxR70PPCNXY+a6c0g9nv2Ic98txzLSiXrk/Y51GLUxD58TpScuTWahF7nAt/j3NW TUJxm2fEZsiQ1ihHUMBvGIOcVlY77haDntxDpYPrGcc6rhwJYdeu8WBmSpKyvqw95UWLDtqgZ CtwxGurRSJO9KlQEjG811AhuW6llfMdPnOvQ16TN1AgVQ5fph1FqBaPZ0IeqOsy3ScdseqWp/ HW/QELYkvUAQl5py4HNfbf8yfsVHWl0D9eevuLNz8yuS/jLkjdtTR4gNsUHvBJrVm6oezV0+h JYfIIFUwDt+C+6gMTlg73xYGdeaCekNiibexpV2BeGyWMMKA5sPHjtxGXEoSt0jz9/wDid3nS HY3945xlzso8cJc5YwgkhLcpuIJqNd9ppd8m6YlMCSk8n4Yb1E7DuZERxofs/3ecYPskW6XxE cwKzQrwj4Bl9VmKsIcn4lEHyH2yHnk6iyn4pLOA72MLW75i5IaUhI1OIcR9QFTmp3BSfEzV5c aqJ899NIy25x/bCrhuv0IHWtgKzYtllG08jBjbBSv2XZ/oblmcbFdZbMQoZTfck8XQrjXWPSG JA==
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/250ZXw0nlF9my-f2M9rxdD_c00Q>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.17
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: <https://mailarchive.ietf.org/arch/browse/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, 06 Mar 2017 15:38:10 -0000

Hi Mike, Hi all,

as a shepherd I have reviewed the draft and I only have a few minor
comments.

RFC 2246 is included in the normative reference section but not
mentioned in the text.

[RFC2246]  Dierks, T. and C. Allen, "The TLS Protocol Version 1.0",
              RFC 2246, DOI 10.17487/RFC2246, January 1999,
              <http://www.rfc-editor.org/info/rfc2246>.
			
The same is true for these references:


   [RFC7565]  Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565,
              DOI 10.17487/RFC7565, May 2015,
              <http://www.rfc-editor.org/info/rfc7565>.

   [RFC3986]  Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
              Resource Identifier (URI): Generic Syntax", STD 66,
              RFC 3986, DOI 10.17487/RFC3986, January 2005,
              <http://www.rfc-editor.org/info/rfc3986>.		

   [JWA]      Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,
              DOI 10.17487/RFC7518, May 2015,
              <http://tools.ietf.org/html/rfc7518>.

The description of this claim sounds a bit strange.

   jwks_uri
      OPTIONAL.  URL of the authorization server's JWK Set [JWK]
      document.  This contains the signing key(s) the client uses to
      validate signatures from the authorization server.  The JWK Set
      MAY also contain the server's encryption key(s), which are used by
      clients to encrypt requests to the server.  When both signing and
      encryption keys are made available, a "use" (public key use)
      parameter value is REQUIRED for all keys in the referenced JWK Set
      to indicate each key's intended usage.
	

Instead of saying "This contains the signing key(s) the client uses to
validate signatures from the authorization server."  I would say
something like:

"The JWK, once retrieved from the indicate URL, contains the public
key(s) the client uses to validate signatures from the authorization
server."

Could you also explain how you anticipate these keys to be used? The
meta data may be digitally signed by the authorization server. You
obviously need the public key corresponding to the private key used for
signing to the meta-data JSON payload. You seem to be suggesting to
include a URL to that key inside the message itself. If you are not
using HTTPS then you are toast. If you use an HTTPS-based then you are
essentially relying on the trust anchors in the browser for security. Is
that what you want?

Is this mechanism supposed to work with symmetric as well as asymmetric
keys?

Ciao
Hannes

On 02/20/2017 05:33 PM, Mike Jones wrote:
> Per working group feedback, the document now reflects the singular mission of documenting OAuth Authorization Server Metadata as it is actually used in practice.  I believe that the document today accomplishes this mission and is ready for publication.
> 
> 				-- Mike
> 
> -----Original Message-----
> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of Hannes Tschofenig
> Sent: Monday, February 20, 2017 1:46 AM
> To: oauth@ietf.org
> Subject: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
> 
> Hi all,
> 
> it was roughly a year ago when we issued a working group last call on draft-ietf-oauth-discovery, see https://www.ietf.org/mail-archive/web/oauth/current/msg15796.html. Lots of feedback resulted in a significant restructuring of the document.
> 
> The authors of the draft now believe it is ready for a second WGLC and hence we would like to start a 2-week review period.
> 
> Please provide your review comments no later than March 6th.
> 
> Here is the link to the document again:
> https://tools.ietf.org/html/draft-ietf-oauth-discovery-05
> 
> Ciao
> Hannes & Derek
>