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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id CCDDF129510 for <>; Fri, 10 Mar 2017 18:08:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.001
X-Spam-Status: No, score=-2.001 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, 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 Nz5Ix-xd6GK9 for <>; Fri, 10 Mar 2017 18:08:46 -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 1E5AD129514 for <>; Fri, 10 Mar 2017 18:08:46 -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=UmorfcIIiuVb6VbZsoZl7YrCJFdEFG6bYoWjy428afs=; b=eUbOTwTMr+6IKUBHVNlFcIdWviUV1GhkBwIqdAh6a7+RDcn/nwOjCjwc38pP3/rDyytu1pH1tS9pUalyWQwBf4bjxdbh236WgZh/zPJc2Kw4NNBl/PkNEOfrX1vXvuoqLKbVqTALl+Qpt+UCZYRerv+Ce8uglhaCWkHLYWmtsOs=
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:44 +0000
Received: from ([]) by ([]) with mapi id 15.01.0947.022; Sat, 11 Mar 2017 02:08:44 +0000
From: Mike Jones <>
To: William Denniss <>, Hannes Tschofenig <>
Thread-Topic: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
Thread-Index: AQHSi93G2DiLgd6STkWd6z/5eE5XY6GOq5ag
Date: Sat, 11 Mar 2017 02:08:43 +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: 665e84f2-7237-45f1-966f-08d468238bab
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:dog5vNVeLqwclEcvkzU5JH6Ffg2WoJ4OaydtyoO8oshYVSVfzb6PeTmCKEb1QLD6+4+2o59QqsvyJn5OyBG3d/YadbUP87Us+8ffQfnPbb42/SEjO0KmQBsBmIbTCIN89MX5rni+2Nqh85hJ/ntDlNeXT8bMLs27SAdSG4RLbtS7lldUVXIJ4nqUy4HIeDfNYI0My3C72wG6DfTJWLVVAPgXAt4CxO7MRiNmBi1UlOdco3y7U57fGRhwfvjBKfGZqHw7Ust4eqySnkutEz/pwVIv8CEDFcjwTDNjpFfkYkro9BH0vPME2PbCkaShvyS6kd8XfJu2+fPgu7skK8riF1nGjO14grTIlct/FsNAfaU=
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(158342451672863)(131327999870524)(248736688235697)(21748063052155);
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)(377454003)(2950100002)(189998001)(2900100001)(6116002)(102836003)(790700001)(99286003)(5005710100001)(25786008)(5660300001)(7696004)(122556002)(77096006)(8990500004)(55016002)(10290500002)(19609705001)(106116001)(74316002)(7736002)(10090500001)(6436002)(4326008)(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_CY4PR21MB0504B4508A7C459994025A7FF5230CY4PR21MB0504namp_"
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-originalarrivaltime: 11 Mar 2017 02:08:44.0262 (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: <>
Cc: "" <>
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:08:48 -0000

Thanks a bunch for your review, William.  Draft -06 incorporates the results of your feedback.  Replies are inline.

                                                                -- Mike

From: OAuth [] On Behalf Of William Denniss
Sent: Monday, February 20, 2017 4:59 PM
To: Hannes Tschofenig <>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata

I have reviewed version 05. Two minor comments regarding Section 2.1:

1. Should we clarify that alg:none isn't supported for the signed_metadata JWT (since it would be contradictory)?

It already says “The signed metadata MUST be digitally signed or MACed using JSON Web Signature (JWS) [JWS]”.  Given that “alg”: “none” doesn’t satisfy this MUST, I don’t think we need to say anything additional about it.

2. Re: "metadata values conveyed in the signed metadata MUST take precedence over those conveyed using plain JSON elements."  Does this imply that *all* values in the plain JSON elements should be ignored when the signed_metadata is being used (not just ones present in the JWT)? If not, should it?

This is a good request for clarification.  It’s been updated to say “If the consumer of the metadata supports signed metadata, metadata values conveyed in the signed metadata MUST take precedence over the corresponding values conveyed using plain JSON elements.”

Overall, I strongly support the publishing of this document as an RFC for the following reasons:

Having "machine readable" configuration metadata published by authorization servers is a useful concept. The Google authorization server (like many others) publishes metadata compliant with this specification, and the AppAuth series of client libraries are capable of consuming it.

Without this standardized machine-readable metadata, developers must read documentation to extract the relevant information, and configure clients manually. This is cumbersome, error prone, and may get out of date.

This specification can also help prevent one category of "mix up" attack in systems which allow self-registration of OAuth endpoints for connected services. Rather than the developer supplying both the authorization and token endpoints themselves (which may enable them to specify a malicious token endpoint), such a system can use the token endpoint specified in the authorization server's metadata, thus preventing this category of attack (and simplifying the registration process to boot).

On Mon, Feb 20, 2017 at 1:45 AM, Hannes Tschofenig <<>> wrote:
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:

Hannes & Derek

OAuth mailing list<>