Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence

Phil Hunt <> Thu, 18 February 2016 13:35 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 7EF2C1A8A12 for <>; Thu, 18 Feb 2016 05:35:34 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -4.206
X-Spam-Status: No, score=-4.206 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.006, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 5oCZAQGm9PVQ for <>; Thu, 18 Feb 2016 05:35:32 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 0BD2A1A8998 for <>; Thu, 18 Feb 2016 05:35:31 -0800 (PST)
Received: from ( []) by (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id u1IDZV4A002549 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 18 Feb 2016 13:35:31 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id u1IDZUs8002510 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Thu, 18 Feb 2016 13:35:30 GMT
Received: from ( []) by (8.13.8/8.13.8) with ESMTP id u1IDZUAt012511; Thu, 18 Feb 2016 13:35:30 GMT
Received: from [] (/ by default (Oracle Beehive Gateway v4.0) with ESMTP ; Thu, 18 Feb 2016 05:35:29 -0800
Content-Type: multipart/alternative; boundary="Apple-Mail=_BBC28EB5-C417-4DA4-8727-370974085868"
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
From: Phil Hunt <>
In-Reply-To: <>
Date: Thu, 18 Feb 2016 06:35:28 -0700
Message-Id: <>
References: <>
To: Mike Jones <>
X-Mailer: Apple Mail (2.3112)
X-Source-IP: []
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 18 Feb 2016 13:35:34 -0000

I still find the following text objectionable and confusing…
   By default, for historical reasons, unless an application-specific
   well-known URI path suffix is registered and used for an application,
   the client for that application SHOULD use the well-known URI path
   suffix "openid-configuration" and publish the metadata document at
   the path formed by concatenating "/.well-known/openid-configuration"
   to the authorization server's issuer identifier.  As described in
   Section 5 <>, despite the identifier
   "/.well-known/openid-configuration", appearing to be OpenID-specific,
   its usage in this specification is actually referring to a general
   OAuth 2.0 feature that is not specific to OpenID Connect.

Further, as a default “openid-configuration” as the default further gives people the impression that a plain OAuth server *is* an authentication server and that the normal access token received is evidence of a successful authentication.

It would be better to point out that application may include oauth discovery in their discovery URI and that OAuth is an example of this. It might be good to include two examples.  E.g. OIDC and SCIM (as another referenceable example).

 GET /.well-known/openid-configuration
 GET /.well-known/scim
Retrieve the OAuth configuration for the application openid and scim respectively.

The use of:
 GET /.well-known/oauth2/
Should be the default used when there is no known application based well-known application based URI discovery.

Of course, the concern I raised earlier is that this approach of application specific URIs ends up requiring every application to make an IANA registration if they don’t want to use the default of “oauth2” (or “openid-configuration”).  Is that what the authors expect?

It seemed better to me to use the webfinger syntax to allow the client to say “I want the designated OAuth configuration for the resource service X” would be a better design that avoids extensive IANA registration.


@independentid <> <>

> On Feb 17, 2016, at 11:48 PM, Mike Jones <> wrote:
> In response to working group input, this version of the OAuth Discovery specification has been pared down to its essence – leaving only the features that are already widely deployed.  Specifically, all that remains is the definition of the authorization server discovery metadata document and the metadata values used in it.  The WebFinger discovery logic has been removed.  The relationship between the issuer identifier URL and the well-known URI path relative to it at which the discovery metadata document is located has also been clarified.
> Given that this now describes only features that are in widespread deployment, the editors believe that this version is ready for working group last call.
> The specification is available at:
> · <>
> An HTML-formatted version is also available at:
> · <>
>                                                           -- Mike & Nat & John
> P.S.  This notice was also posted at <> and as @selfissued <>.
> _______________________________________________
> OAuth mailing list
> <>
> <>