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

Mike Jones <> Sat, 11 March 2017 02:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 648B5129538 for <>; Fri, 10 Mar 2017 18:09:07 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.991
X-Spam-Status: No, score=-1.991 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id u5szstpY57W4 for <>; Fri, 10 Mar 2017 18:09:05 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 5CBA112953A for <>; Fri, 10 Mar 2017 18:08:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=IZEbLwhhMD6KU+vh1VJONyqATK3/V4AajVDJe4QbydU=; b=Oj08yCVp6B8rk8GAyXqy2pqTlRpi5e7738Wl9/+bmm7iJnHtZKx01wel7D3THShnNN65p9LHSqmrO8005P7ZHkqmS24JQZvbfOjLVVTWY3FNmCsVJVjoGoht4sVGzGXH/15x7/q+JRQ+MnOlYqbXZ7JOVEe0jKSLU5xSc/GPsG0=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384_P384) id 15.1.947.0; Sat, 11 Mar 2017 02:08:57 +0000
Received: from ([]) by ([]) with mapi id 15.01.0947.022; Sat, 11 Mar 2017 02:08:57 +0000
From: Mike Jones <>
To: Hannes Tschofenig <>, "" <>
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
Thread-Index: AQHSlo+ld6BPSzrHt0yZ00/LNl1b0KGOmKOw
Date: Sat, 11 Mar 2017 02:08:56 +0000
Message-ID: <>
References: <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
authentication-results:; dkim=none (message not signed) header.d=none;; dmarc=none action=none;
x-originating-ip: [2001:4898:80e8:e::36]
x-ms-office365-filtering-correlation-id: 6b03921e-b2a1-498c-6924-08d46823935a
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(22001)(48565401081); SRVR:CY4PR21MB0503;
x-microsoft-exchange-diagnostics: 1; CY4PR21MB0503; 7:pz4R2b3YC0wdSBYxEcGU1myccx6Qwaw33CW6NMVj7PEK8tgALYxNaGDphZnx2PGqbETDXNYBxdNW26RdZDXF8DqIbKXj64sFANtrsL2eb2DSfMaWrLpTVCUqFtnLbP38rQ+ZJggbVgoBmPDJS3sf+sb0DC4kETztBHle1JDUNq22jIxkgBUWi7+hvSbzrxr0O4cqUKIyNzmqLGKkOUCbqo3wKEPXNBnzEEIxpC4ud8wQvPe8UoctToT6MyUuLYenQ1IH6MuKaBUEp+rbIP7agDduRM/cd2HPCZPB7IUzEhfwG1pUVMl1wOqRR7hbb+Djmuyda2syhAzvEWi5DajOkRoXA0/uqn3abZMS9mGo0M4=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(248736688235697)(21748063052155)(17755550239193);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040375)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6055026)(61426038)(61427038)(6041248)(20161123562025)(20161123555025)(20161123560025)(20161123564025)(20161123558025)(6072148); SRVR:CY4PR21MB0503; BCL:0; PCL:0; RULEID:; SRVR:CY4PR21MB0503;
x-forefront-prvs: 0243E5FD68
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(39450400003)(39860400002)(39850400002)(39410400002)(39840400002)(53754006)(24454002)(13464003)(377454003)(2950100002)(189998001)(2501003)(2900100001)(6116002)(102836003)(790700001)(99286003)(5005710100001)(25786008)(5660300001)(7696004)(122556002)(77096006)(8990500004)(55016002)(10290500002)(106116001)(74316002)(7736002)(10090500001)(6436002)(6506006)(33656002)(236005)(54356999)(9686003)(7906003)(53546006)(50986999)(6306002)(76176999)(54896002)(606005)(38730400002)(86612001)(53936002)(86362001)(3280700002)(8936002)(8676002)(2906002)(81166006)(3660700001)(6246003); DIR:OUT; SFP:1102; SCL:1; SRVR:CY4PR21MB0503;; FPR:; SPF:None; MLV:sfv; LANG:en;
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_CY4PR21MB050432D2BE1C533EE9139A29F5230CY4PR21MB0504namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2017 02:08:56.8520 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY4PR21MB0503
Archived-At: <>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sat, 11 Mar 2017 02:09:07 -0000

Thanks a lot for your review, Hannes.  Draft -06 incorporates your feedback.  Replies are inline below.


                                                                -- Mike

-----Original Message-----
From: Hannes Tschofenig []
Sent: Monday, March 6, 2017 7:38 AM
To: Mike Jones <>;
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata

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,


The same is true for these references:

   [RFC7565]  Saint-Andre, P., "The 'acct' URI Scheme", RFC 7565,

              DOI 10.17487/RFC7565, May 2015,


   [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,


   [JWA]      Jones, M., "JSON Web Algorithms (JWA)", RFC 7518,

              DOI 10.17487/RFC7518, May 2015,


These references have all been removed.

The description of this claim sounds a bit strange.


      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."

Good catch.  Rather than saying “This contains”, it now says “The referenced document contains”.

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?

The URL is now explicitly required to use the https scheme.  This requirement has now been made explicit in the jwks_uri definition.

Yes, you’re relying on the trust anchors in the browser for security.  That’s why the issuer requires use of the https scheme (meaning that that the AS metadata will be retrieved from an https URL).  The use of TLS for the jwks_uri is another case of this reliance.

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

No.  Given that the JWKS Set is public, it must contain only public keys.



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 [] On Behalf Of Hannes

> Tschofenig

> Sent: Monday, February 20, 2017 1:46 AM

> To:<>

> 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 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:



> Ciao

> Hannes & Derek