OAuth 2.0 Authorization Server Metadata
draft-ietf-oauth-discovery-08

Summary: Has 2 DISCUSSes. Has enough positions to pass once DISCUSS positions are resolved.

Alexey Melnikov Discuss

Discuss (2018-01-24)
Thank you for the well written IANA Considerations section. I have one comment on it which should be easy to resolve:

The document doesn't seem to say anything about allowed characters in Metadata names. When the document talks about "case-insensitive matching", it is not clear how to implement the matching, because it is not clear whether or not Metadata names are ASCII only. If they are not, then you need to better define what "case insensitive" means.
Comment (2018-01-24)
I am agreeing with Adam's DISCUSS.

Adam Roach Discuss

Discuss (2018-01-23)
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

_______
UPDATE

Author's response: https://www.ietf.org/mail-archive/web/oauth/current/msg17747.html
My response: https://www.ietf.org/mail-archive/web/oauth/current/msg17748.html
Comment (2018-01-22)
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.

Ben Campbell Yes

Comment (2018-01-23)
-1.1: There are lower case versions of 2119 keywords. Please consider using the boilerplate from 8174.

Kathleen Moriarty Yes

Eric Rescorla Yes

Alia Atlas No Objection

Deborah Brungard No Objection

Benoit Claise No Objection

Alissa Cooper No Objection

Comment (2018-01-24)
I support Adam's DISCUSS.

And as the Gen-ART reviewer pointed out, I find it a bit troubling that the shepherd write-up answers to the questions about IANA registrations are completely wrong.

Spencer Dawkins No Objection

Suresh Krishnan No Objection

Warren Kumari No Objection

Comment (2018-01-24)
I support Alexey's DISCUSS (and sure hope it is ASCII, otherwise "It's a trap!")

Mirja K├╝hlewind No Objection

Terry Manderson No Objection

Alvaro Retana No Objection