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

John Bradley <> Thu, 18 February 2016 13:55 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 775A21A904F for <>; Thu, 18 Feb 2016 05:55:47 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.9
X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id icYdcjYwP713 for <>; Thu, 18 Feb 2016 05:55:44 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400c:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id B3EAD1A903D for <>; Thu, 18 Feb 2016 05:55:43 -0800 (PST)
Received: by with SMTP id c3so44585985vkb.3 for <>; Thu, 18 Feb 2016 05:55:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20150623; h=subject:mime-version:content-type:from:in-reply-to:date:cc :message-id:references:to; bh=EiMv8iRKf07K3jgqOugfOBTb9SeOML0GSYTk0EGjevM=; b=I37ytp2JsNhMXhIopWr5fZvL9qucsaBm6Y8nIwEsykELqVeOf8WLKiPDuDijNY2/Ek owwOXP4fI6ChQBSQ05YG6VAFG6Nn+Kv2bdGI3GGVTIAxIRmSIqy0svlRCRRp+6feQEZo LM3EuyTtgDQsPPAyqZ7mFYn28zSeN+C/dfvkg5l485bsTOalMiCP0ra3h+4iA+KKg4a6 JvA3BUmGCC5+2NDoVhP8AQn0+Tg5t5baN5719TM/pP4DEsExVabG0EfkITf93JG06q9v gRh7bolS8JES+xdjHFdbSKI04q6V0CV/SjLapqq1dmOLWjv2LxESqnNwJ/nWFRoubCNN U0Cg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20130820; h=x-gm-message-state:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=EiMv8iRKf07K3jgqOugfOBTb9SeOML0GSYTk0EGjevM=; b=bYkxqbSA7XtCXmsIol8G1HFTvGmSQcTcH/NCUnf64aEHWrdHExSsa+l/rTmjgailbW ZrBcyF/ZdHnSHDvoREMx0hDR3NV39G+rL+UmKGtkMA8fj5N+lUXOW3GpdTyWZbaORQZN CLY16WjVV9ZDv/jHFmr2Oe4FA/ZOUWqpnkwBG/kK4BqulPE68hGHVUWts1p2MKNr2hIM CcuoA+wgyxAEt9ZSLJRyAB1evFx9QCcfrEwmRUVqnGFwXMzxXkwt3aX8JOd1iZgy/ydD pr6hSMugCXrvZdXscNjwzT4q6P+rCVfKTRSZnfkRvItln5MDu3F7HXVG2i5sh6m6XnZa xoyw==
X-Gm-Message-State: AG10YOTWF5BIrW2rJ7IIYIhyNdXjt0o4hmlSkLOTKqidNlhj6oyZ8iLuGAqgHiWHZ5RnIw==
X-Received: by with SMTP id b127mr6120984vka.77.1455803742739; Thu, 18 Feb 2016 05:55:42 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id h22sm755071vka.26.2016. (version=TLS1 cipher=ECDHE-RSA-AES128-SHA bits=128/128); Thu, 18 Feb 2016 05:55:41 -0800 (PST)
Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\))
Content-Type: multipart/signed; boundary="Apple-Mail=_840611E4-EA19-45B4-85D6-818A2BA963CF"; protocol="application/pkcs7-signature"; micalg="sha1"
From: John Bradley <>
In-Reply-To: <>
Date: Thu, 18 Feb 2016 08:55:39 -0500
Message-Id: <>
References: <> <>
To: Phil Hunt <>
X-Mailer: Apple Mail (2.3112)
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:55:47 -0000

Diffrent protocols like Connect and SCIM may have different configurations, endpoints , keys , authentication methods, scopes etc.

It should be posable to have them as one document, but forcing them to use one document is going to cause a explosion of claim registration for discovery.

I think it is better for SCIM to register one well known than to have to register 20 claims with scim prefixes or something silly like that.

Name-spacing the claims by allowing them to be in different well known files is not unreasonable.

Remember some of these protocols may be hosted on SaaS so there is no guarantee that all protocols will have the same OAuth Config.

Nothing stops a protocol from doing what it likes with webfinger if it wants to use that for discovery.

In principal I like the idea of having another protocol as an example.

My only concern is that I haven’t seen any discussion of your SCIM discovery document in the SCIM WG.  
I personally think sorting out discovery for SCIM is a good idea,  but OAUTh is but one of several authentication methods for SCIM, and there are probably other non OAuth things that want to be described.

I would feel better about using it as an example if it were adopted by the WG and some general interest shown.

I encourage you to do that so we can use it as a example.

John B.

> On Feb 18, 2016, at 8:35 AM, Phil Hunt <> wrote:
> 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
> and
>  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.
> Phil
> @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
>> <>
>> <>
> _______________________________________________
> OAuth mailing list