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

John Bradley <> Wed, 24 January 2018 20:07 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A204012895E for <>; Wed, 24 Jan 2018 12:07:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.34
X-Spam-Status: No, score=-2.34 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, HTML_OBFUSCATE_05_10=0.26, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id UO6OIz5pS01b for <>; Wed, 24 Jan 2018 12:07:29 -0800 (PST)
Received: from ( [IPv6:2a00:1450:400c:c09::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id A8DE2128896 for <>; Wed, 24 Jan 2018 12:07:28 -0800 (PST)
Received: by with SMTP id r71so10735531wmd.1 for <>; Wed, 24 Jan 2018 12:07:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=UmREG2iW0y+PQihWJZQ9t5itcEB4egXavnvKbbC0EpU=; b=n6aqimZbmWoehuIWoNcup9WMJlekAWzBQ7WNIcxpKAJ+F4H5qOjvYzUoXak3v7gdRg y5XQ+CtyhbKAmtIH7efMgA9AAtSt4bN5VXxKYqxCUkbi6CdcPV9uxEswXu+mftKQL1h8 2YrQsrCn8eMgy+sQSPK5qEhKSY2rrPtylDygVwRuozkh8OPR6clnbanaNAgrONy0O6+b BFAruswVPSYKT1E1SSYgUoYNBT62UE2xJxK9u7iBmcSECpHoSi1j7Y1BYS62X0C1hIXw TfEuSri4NkoOFTDcxpHrT9asJ8kvDTriu4e+7AVcE0ZGq3Jajriy7LG2xgWBX48xhNN/ RbYw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=UmREG2iW0y+PQihWJZQ9t5itcEB4egXavnvKbbC0EpU=; b=p5Y5CiwIxSEW+9TSBHnaPauklKIbM/wQe7b5fEdgUA35xZIpRLokj0wIqiBzL4GI7E uYiSo8QSZOxYSu0LAJojHynFU3RmEd5OghbTOZRAjcSo5WxChHuJ+kWNwSQq2KFeMLa+ d2X2sOMWBLFyNDiJP20D7NwLcrbPQ7ZsIhm3KqE/85lYTu741WOuhF79iHGjEutTSjFo OZcpvGz0D++ngevUdhJjIIEH6T5yvL34OMgEOIncS4QfDysUnjBi5Y6vobDnpzJbKK1Y uHB0WC6w4GcvKURDBH0OcAHskC75uxXXD9+CrV8a9EqyWeXF9guQslNz/asuUW0LBKsD pmJg==
X-Gm-Message-State: AKwxyteQ2ZkICqA1krComnBcuC328Dw2FE3Obha0pfodOwKCnSSjf3dS 8XOxpndeAWijN8NeF37UMauhcPhSN9Q++LENjHdOlQ==
X-Google-Smtp-Source: AH8x226QRu4ioRy3b++Z9nfyEqxqtEKsyEbqem74Yhl0JXEi2b4SfWYLZ09wCfqlzktfDjKu3nlQe6UvYjTDRvyC7ZA=
X-Received: by with SMTP id v11mr6248366wmh.27.1516824446488; Wed, 24 Jan 2018 12:07:26 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Wed, 24 Jan 2018 12:07:25 -0800 (PST)
Received: by with HTTP; Wed, 24 Jan 2018 12:07:25 -0800 (PST)
In-Reply-To: <>
References: <> <> <>
From: John Bradley <>
Date: Wed, 24 Jan 2018 17:07:25 -0300
Message-ID: <>
To: Adam Roach <>
Cc: Michael Jones <>, IESG <>, "" <>, "" <>, "" <>, "" <>
Content-Type: multipart/alternative; boundary="089e0827e9fc51e87005638b36ba"
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 20:07:33 -0000

It seems that I was smarter 5 years ago:)

We went with the easier construction for developers in the end.   That may
not have been the best choice in retrospect.

Mike and I are discussing with the other authors how we can address this
while minimising developer confusion, given that a large number of
implementations use the existing construction.

John B.

On Jan 23, 2018 6:14 PM, "Adam Roach" <> wrote:

> On 1/23/18 6:21 PM, Mike Jones wrote:
>> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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 <
>> /#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:
>> Would instead become:
>>       GET /.well-known/oauth-authorization-server/issuer1 HTTP/1.1
>>       Host:
>> 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
>> 7d7ae2af8c/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:
> <
> sing-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.
> ----------------------------------------------------------------------
>> ----------------------------------------------------------------------
>> 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.
>> c7638#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
>> 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