Re: [OAUTH-WG] OAuth Digest, Vol 111, Issue 28

Help

On Jan 23, 2018 1:01 PM, <oauth-request@ietf.org> wrote:

Send OAuth mailing list submissions to
        oauth@ietf.org

To subscribe or unsubscribe via the World Wide Web, visit
        https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
        oauth-request@ietf.org

You can reach the person managing the list at
        oauth-owner@ietf.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."

Today's Topics:

   1. Adam Roach's Discuss on draft-ietf-oauth-discovery-08: (with
      DISCUSS and COMMENT) (Adam Roach)

----------------------------------------------------------------------

Message: 1
Date: Mon, 22 Jan 2018 18:41:54 -0800
From: Adam Roach <adam@nostrum.com>
To: "The IESG" <iesg@ietf.org>
Cc: draft-ietf-oauth-discovery@ietf.org, Hannes Tschofenig
        <Hannes.Tschofenig@gmx.net>, oauth-chairs@ietf.org,
        Hannes.Tschofenig@gmx.net, oauth@ietf.org
Subject: [OAUTH-WG] Adam Roach's Discuss on
        draft-ietf-oauth-discovery-08: (with DISCUSS and COMMENT)
Message-ID:
        <151667531481.29516.15285531314696206411.idtracker@ietfa.amsl.com>
Content-Type: text/plain; charset="utf-8"

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 https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-oauth-discovery/

----------------------------------------------------------------------
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

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

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.

------------------------------

Subject: Digest Footer

_______________________________________________
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

------------------------------

End of OAuth Digest, Vol 111, Issue 28
**************************************