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

Adam Roach <adam@nostrum.com> Wed, 24 January 2018 02:14 UTC

Return-Path: <adam@nostrum.com>
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 8242412D880; Tue, 23 Jan 2018 18:14:28 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.89
X-Spam-Level:
X-Spam-Status: No, score=-1.89 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01, T_SPF_HELO_PERMERROR=0.01, T_SPF_PERMERROR=0.01] 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 LirFkLuas_cX; Tue, 23 Jan 2018 18:14:25 -0800 (PST)
Received: from nostrum.com (raven-v6.nostrum.com [IPv6:2001:470:d:1130::1]) (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 37E4212D7EC; Tue, 23 Jan 2018 18:14:24 -0800 (PST)
Received: from Svantevit.local (99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228]) (authenticated bits=0) by nostrum.com (8.15.2/8.15.2) with ESMTPSA id w0O2EG7G094921 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Tue, 23 Jan 2018 20:14:16 -0600 (CST) (envelope-from adam@nostrum.com)
X-Authentication-Warning: raven.nostrum.com: Host 99-152-146-228.lightspeed.dllstx.sbcglobal.net [99.152.146.228] claimed to be Svantevit.local
To: Mike Jones <Michael.Jones@microsoft.com>, The IESG <iesg@ietf.org>
Cc: "Hannes.Tschofenig@gmx.net" <Hannes.Tschofenig@gmx.net>, "draft-ietf-oauth-discovery@ietf.org" <draft-ietf-oauth-discovery@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, "oauth@ietf.org" <oauth@ietf.org>
References: <151667531481.29516.15285531314696206411.idtracker@ietfa.amsl.com> <SN6PR2101MB0943BC380296B9DBD12E4EF1F5E20@SN6PR2101MB0943.namprd21.prod.outlook.com>
From: Adam Roach <adam@nostrum.com>
Message-ID: <c0295c9d-2606-1fca-d22c-52eed94fba1e@nostrum.com>
Date: Tue, 23 Jan 2018 20:14:10 -0600
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.10; rv:52.0) Gecko/20100101 Thunderbird/52.5.2
MIME-Version: 1.0
In-Reply-To: <SN6PR2101MB0943BC380296B9DBD12E4EF1F5E20@SN6PR2101MB0943.namprd21.prod.outlook.com>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ScSo-LROu57fqQEjmXCMN1BklIM>
Subject: Re: [OAUTH-WG] Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
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: Wed, 24 Jan 2018 02:14:28 -0000

On 1/23/18 6:21 PM, Mike Jones wrote:
> ----------------------------------------------------------------------
> DISCUSS:
> ----------------------------------------------------------------------
>
> 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 <https://www.w3.org/TR/webarch/#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
>       Host: example.com
>
> Would instead become:
>
>       GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
>       Host: example.com
>
> 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" https://openid.net/specs/openid-connect-discovery-1_0.html, where these semantics are defined in the second paragraph of https://openid.net/specs/openid-connect-discovery-1_0.html#ProviderConfig.  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 http://openid.net/certification/#RPs.  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 https://login.microsoftonline.com/5608b4e0-e26d-4bd1-8a1a-d57d7ae2af8c/v2.0/.well-known/openid-configuration.  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.

I understand the difficulty here, as breaking changes -- especially at 
this late state -- are a pretty big deal, and I feel bad that this 
situation has arisen. I'll note that I was not the first to identify 
this specific "better path that could have been taken"; John Bradley 
described the same approach over five years ago in a thread that you 
participated in: 
<https://bitbucket.org/openid/connect/issues/638/discovery-using-issuer-identifer-w-path>;.

One of the key reasons existing external specifications are brought to 
the IETF is to file off architectural warts such as this. As is standard 
practice for BOFs involving externally-incubated solutions, there was 
discussion at the OAUTH BOF regarding change control and breaking 
changes. Looking at the minutes, a key proponent asserted "we want oauth 
reviewed, and if problems are found, fixed", while the sponsoring AD 
clarified: "No one expects bit-for-bit compatibility.... Code can change 
over time."  I understand the "code can change over time" argument is 
quite blithe when applied out of the blue, but it seems much more 
relevant when it was one of the arguments that was made for the very 
creation of the working group.

Minimally, if we come to some kind of IETF consensus (after looping in 
the relevant parties) that allows publication of a document that squats 
on the entire path namespace of HTTP URLs -- and I want to be clear that 
I don't believe this is possible -- then this document needs to update 
BCP 190, to amend the following normative requirement on how IETF 
specifications handle URLs:

    Scheme definitions define the presence, format, and semantics of a
    path component in URIs; all other specifications MUST NOT constrain,
    or define the structure or the semantics for any path component.

    The only exception to this requirement is registered "well-known"
    URIs, as specified by [RFC5785].  See that document for a description
    of the applicability of that mechanism.

To be clear: amending BCP 190 is way, WAY outside the purview and 
charter of OAUTH. Overriding this normative language would require input 
from the appropriate community (maybe httpbis, but they're almost 
closed), and you'd need to build consensus that what we did in BCP 190 
-- which was a formal codification of web principles promulgated by the 
W3C, with roots tracing back to Roy Fielding's thesis that coined the 
REST concept itself -- was incorrect.

The fundamental problem here is that the cows have been walking through 
private gardens for years, despite clear rules that say they should not. 
Breaking out the paving equipment to formally seize that land for 
OAUTH's exclusive use would only make that transgression so much worse.

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

Thanks.

> 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.  https://tools.ietf.org/html/rfc7638#section-6 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 https://www.iana.org/assignments/jose/jose.xhtml#web-key-types 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.


If there's precedent, I'm okay going along with that.

/a