Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)

Mike Jones <> Wed, 24 January 2018 00:21 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 18E5112D7F6; Tue, 23 Jan 2018 16:21:16 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.02
X-Spam-Status: No, score=-2.02 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H3=-0.01, RCVD_IN_MSPIKE_WL=-0.01, 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 5t_R55Z5Y3Yv; Tue, 23 Jan 2018 16:21:13 -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 47BDD12D574; Tue, 23 Jan 2018 16:21:13 -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=RXu4EwL/9sKsaKskT20PA4EymYJg+d1E8wC3Lm+qa2Q=; b=Fan34ZMK85h51g1r0TdvWvNiolby2YOT0O6tGmOOU712MD3+gARnar9RMaGNNa9yraeUyKPUriUzoO5oksz/+Vnn9VD5wQyAI5o4CTYcwGHCV9LFOI5zYx6MPy8sXyOEcvNU+olpQddmqGdmYPR5IY6VxXEaSJpg4HPKGGseVc8=
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.464.0; Wed, 24 Jan 2018 00:21:11 +0000
Received: from ([fe80::7068:47f5:3e1c:ce6a]) by ([fe80::7068:47f5:3e1c:ce6a%4]) with mapi id 15.20.0444.004; Wed, 24 Jan 2018 00:21:11 +0000
From: Mike Jones <>
To: Adam Roach <>, The IESG <>
CC: "" <>, Hannes Tschofenig <>, "" <>, "" <>, "" <>
Thread-Topic: Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
Thread-Index: AQHTk/O+JTwpW4jvA0i4m25Atmuny6OCHqXw
Date: Wed, 24 Jan 2018 00:21:10 +0000
Message-ID: <>
References: <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-ms-publictraffictype: Email
x-microsoft-exchange-diagnostics: 1; SN6PR2101MB0896; 7:UnGVQz1p408vLem1+knF4c7WSexGJ3WSd7xzmNaHJkN2C7N9bq1ccWIy24b6R3ZiEdH6oEb1gwiHVhPow0UkfpYA2r19aPIPK5+oBRhj44CH6XymXJitWgYCZWfyNPQL4I3eM/BhnYM/u4mv9TAjYKtxOkxbMm5fBA7t6cuHUHAwyQhZvCVL0yDFjDPGbTeX2HHsEoZGAnzjDGAKxuuM2MtBuLfSht+XQUwfg21e9aDSjGL0lFqI4yOpO2n8uB2T
x-ms-exchange-antispam-srfa-diagnostics: SSOS;
x-ms-office365-filtering-correlation-id: ea06678a-4685-4b6a-72e1-08d562c05f16
x-ms-office365-filtering-ht: Tenant
x-microsoft-antispam: UriScan:; BCL:0; PCL:0; RULEID:(7020095)(4652020)(5600026)(4604075)(3008032)(4534165)(4627221)(201703031133081)(201702281549075)(48565401081)(2017052603307)(7193020); SRVR:SN6PR2101MB0896;
x-ms-traffictypediagnostic: SN6PR2101MB0896:
x-microsoft-antispam-prvs: <>
x-exchange-antispam-report-test: UriScan:(120809045254105)(169139582196971)(109010052170817)(248736688235697)(21532816269658)(1591387915157)(199174018222543);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425038)(6040501)(2401047)(8121501046)(5005006)(3002001)(93006095)(93001095)(10201501046)(3231046)(2400081)(944501161)(6055026)(61426038)(61427038)(6041288)(20161123558120)(20161123562045)(20161123560045)(20161123564045)(201703131423095)(201702281528075)(20161123555045)(201703061421075)(201703061406153)(6072148)(201708071742011); SRVR:SN6PR2101MB0896; BCL:0; PCL:0; RULEID:; SRVR:SN6PR2101MB0896;
x-forefront-prvs: 056297E276
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(346002)(376002)(39380400002)(396003)(39860400002)(366004)(13464003)(199004)(189003)(54164003)(66066001)(14454004)(106356001)(25786009)(68736007)(54906003)(2950100002)(8936002)(110136005)(230783001)(22452003)(105586002)(6306002)(55016002)(7736002)(8676002)(81166006)(81156014)(33656002)(53936002)(97736004)(9686003)(316002)(74316002)(4326008)(6346003)(2906002)(10290500003)(72206003)(10090500001)(478600001)(5660300001)(3660700001)(7696005)(53376002)(6246003)(3846002)(6116002)(102836004)(86612001)(6506007)(59450400001)(6436002)(53546011)(99286004)(8990500004)(305945005)(86362001)(26005)(229853002)(3280700002)(76176011)(2900100001)(966005)(5250100002); DIR:OUT; SFP:1102; SCL:1; SRVR:SN6PR2101MB0896;; FPR:; SPF:None; PTR:InfoNoRecords; A:1; MX:1; LANG:en;
received-spf: None ( does not designate permitted sender hosts)
authentication-results: spf=none (sender IP is );
x-microsoft-antispam-message-info: L6J6dm0e96A6SaSxDQiKZIA5H0bsPSYGWsJwTlpdCkfD+VZmVuLqTUedPsegJuPcUX1TrnVuF7MLe34Urxb8PQ==
spamdiagnosticoutput: 1:99
spamdiagnosticmetadata: NSPM
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: base64
MIME-Version: 1.0
X-MS-Exchange-CrossTenant-Network-Message-Id: ea06678a-4685-4b6a-72e1-08d562c05f16
X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Jan 2018 00:21:11.0092 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN6PR2101MB0896
Archived-At: <>
Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jan 2018 00:21:16 -0000

Hi Adam,

Thanks for taking the time to do a thorough read of the specification.  Replies are inline prefixed by "Mike>".
-----Original Message-----
From: Adam Roach [] 
Sent: Monday, January 22, 2018 6:42 PM
To: The IESG <>
Cc:; Hannes Tschofenig <>et>;;;
Subject: Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)

Adam Roach has entered the following ballot position for
draft-ietf-oauth-discovery-08: Discuss

When responding, please keep the subject line intact and reply to all email addresses included in the To and CC lines. (Feel free to cut this introductory paragraph, however.)

Please refer to
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:


Thanks to everyone who worked on this specification. I think it's well-written, clear, and useful. I fully endorse publication, and intend to ballot "yes" once we come to an agreement on the issue I describe below.

The problem I'm running into is the URL synthesis rules described in section
3.1 for multi-tenancy engage in exactly the kind of behavior that RFC 5785 was designed to head off: it creates URLs all over the path space of the authority, rather than coralling all synthesized URLs to live under only one top-level directory. One of the key aspects of the principles of the web architecture is URI opacity <>, which generally precludes clients from synthesizing URLs. RFC 5785 was intended as a very limited carve-out to the principle of URI opacity, and was carefully limited to a single top-level path element. This specification oversteps that carve-out by exploding the location that "Well-Known" synthesized URLs can appear: it literally increases it from one location (the root) to infinite locations (at the end of any arbitrary path).

Fortunately, this defect is trivial to fix. Rather than placing .well-known path components *after* the path identified by an issuer identifier, you place them *before* it, which amends this document's usage to be within the spirit intended by RFC 5785. For example, the example in section 3.1:

     GET /issuer1/.well-known/oauth-authorization-server HTTP/1.1

Would instead become:

     GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1

Mike> Interesting suggestion.  I would agree with your suggestion if we were designing this from scratch.

The problem is that this specification is based the much older and widely deployed specification "OpenID Connect Discovery 1.0", where these semantics are defined in the second paragraph of  This OAuth spec removes the OpenID-specific parts of this discovery spec and keeps the rest, while remaining compatible with it by design.  As discussed with Mark Nottingham during the IANA registration process for the .well-known URI (which he approved), this specification writes down what is already industry practice for publishing OAuth metadata - which subsets the OpenID Connect metadata to use only the OAuth-specific parts.

The behavior of concatenating the .well-known suffix to the issuer path is hard-coded into at an absolute minimum, the eleven client libraries listed in the "RP Config" column of  In truth, it's hard-coded into essentially every OAuth client library that uses metadata to configure the OAuth client software and all the OAuth servers that support multiple tenants.  These could number in the hundreds.

An example showing a production deployment of the current method is  There are many more.

This spec is explicitly paving cowpaths.  Yes, you suggest a better path that could have been taken.  But (torturing the metaphor) it's not where the cows are.  We owe it to the industry to codify the widespread and sufficiently-well-working existing practice.  Thanks for your understanding of this.


Section 1.1: [this is an editorial suggestion that I leave to the editors'
discretion] This document makes use of uncapitalized "must", "should", and "may" in places. Please consider using the RFC 8174 boilerplate instead of the RFC 2119 boilerplate.

Mike>   I'd be glad to update to the RFC 8174 boilerplate.

Section 7.2: [this is an important procedural comment that really should be resolved prior to publication] The addition of restrictions to registries established by RFC 6749 would seem to require that this document formally include "Updates: RFC6749" in its metadata, as well as a mention of such an update in its Abstract and Introduction sections.

Mike> I've actually worked with the IESG and IANA in the past to update the instructions for existing registries. adds to the instructions to the Designated Experts for three existing registries.  The way IANA did this was to add [RFC7638] to the References lists in the registries themselves.  For instance, see that the instructions for the "JSON Web Key Types" registry at has a References value of "[RFC7518][RFC7638]".  RFC 7618 did not update RFC 7518 - only the registry established by it.  I propose that we follow this precedent and do the same thing here.

				Thanks again,
				-- Mike