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

[John Bradley <[e-mail]>]

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" <[e-mail]> wrote:

> 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-d5
>> 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:
> <https://bitbucket.org/openid/connect/issues/638/discovery-u
> 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.
>
> ----------------------------------------------------------------------
>> 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/rf
>> 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
>> 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
>