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

Nat Sakimura <sakimura@gmail.com> Thu, 18 February 2016 14:26 UTC

Return-Path: <sakimura@gmail.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E70D51AC3B1 for <oauth@ietfa.amsl.com>; Thu, 18 Feb 2016 06:26:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, SPF_PASS=-0.001] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xgkccYZGo-3n for <oauth@ietfa.amsl.com>; Thu, 18 Feb 2016 06:26:36 -0800 (PST)
Received: from mail-qg0-x236.google.com (mail-qg0-x236.google.com [IPv6:2607:f8b0:400d:c04::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 3A4B21A00BC for <oauth@ietf.org>; Thu, 18 Feb 2016 06:26:36 -0800 (PST)
Received: by mail-qg0-x236.google.com with SMTP id y89so37526100qge.2 for <oauth@ietf.org>; Thu, 18 Feb 2016 06:26:36 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=JXiJBAXpqmkXygVASY0UyjUyvWsy06GhNw5z3dBtxeM=; b=VhRcilXVf6NA1JipKHyfkgIhapPFq4C3aAyan/i3PZJ4B29x5VaUPrFDU8xw+k39rb 0J3oBoRVfpIdKCRTclUXjSRYNMCGUJ5PoYNlyali3S+W70zlDtTO79pmTdTw4BmeaAGG 7Uds8Nuz0SuxdN0hudm85xFfWUilOTMG4QWIsc0FVZeNOVXZBHI7AgyvIxjFSPuJnSsv k1HR1qPgff6CMwclsnT2ms4UN+EnGSGPhWLtClLFwOWC0gTnYXbbeVKg+Wl0hntlswiJ X59upc2QujjQS9VnFaBuRyBlCVk+3FWpH8DM5CiPQXefbceBrYtZI30TpnhtED1VRR53 rO2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-type; bh=JXiJBAXpqmkXygVASY0UyjUyvWsy06GhNw5z3dBtxeM=; b=Rj/R6djj5RAHTtOGYyumpJIrhdOBtz76ekgN1rTa2Yr/VI6U0IX1p4vGPHSPeO7Xmh LtWD164TDBBYBAUdQ4JLPIMptqzqyDdqV02ZIotvUazLSrRWrCcc/Scy3nyJC9+iy5Mv jyL8YmeZZ7oO6+gWOCIXSQ5VJXB264uZ73mhAoY81caMAB1bmqKgnoSHFltj2fUUEJHA 8wNgf+aw305oJytl0V+fCSGBGxVt8vCQVDTsE7wxktn30b5F5kQVmww1mV6hrs/R77U4 cT3znYD3AJ9xzT44l1Y2tTBX13UhplJaL79S9Wn9U92EKgIKZZ+xyzK/VI8yxaj1HSFK 9QIw==
X-Gm-Message-State: AG10YOR9o/C5uv6og9hbUWZ+w/mF4SV8o5zIHqCJ1SPDXmaIK+LZkEyJiQUXiKgbCEyXUVNhh09fwSnxOyB9SA==
X-Received: by 10.140.165.205 with SMTP id l196mr9869927qhl.58.1455805595279; Thu, 18 Feb 2016 06:26:35 -0800 (PST)
MIME-Version: 1.0
References: <BY2PR03MB44236EF33376F8C2BB135E8F5AF0@BY2PR03MB442.namprd03.prod.outlook.com> <533A97B6-F83D-4DBD-A015-81CD438EAE5F@oracle.com> <6E34B5BC-3E23-4E0F-8008-93797B15EB84@ve7jtb.com> <A52BE40A-DEF2-48D6-9612-5BD035104DDB@oracle.com>
In-Reply-To: <A52BE40A-DEF2-48D6-9612-5BD035104DDB@oracle.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Thu, 18 Feb 2016 14:26:24 +0000
Message-ID: <CABzCy2AMUvxnXzvBqCWU9cvUBg5tG0+GcZKDBQcyV0nt=dF8cQ@mail.gmail.com>
To: Phil Hunt <phil.hunt@oracle.com>, John Bradley <ve7jtb@ve7jtb.com>
Content-Type: multipart/alternative; boundary="001a1134f04c5e8e22052c0c2710"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/NEG3viH5ignjFkltPxsr1alwdC0>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Discovery spec pared down to its essence
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 18 Feb 2016 14:26:40 -0000

Hi Phil,

>From the RESTful perspective, it is the resource that should specify where
the client should find the configuration etc. through RFC5988.
As RFC5785 states, /.well-known/ uri is a last resort when this approach
does not work, e.g., when you cannot access the resource before knowing the
metadta.
If I read your message correctly, your use case seems to be able to be
accessed first. Then RFC5988 approach seems to work perfectly.
I am advocating oauth-meta [1] for such cases.

[1] https://tools.ietf.org/html/draft-sakimura-oauth-meta-07#section-2

Nat



2016年2月18日(木) 23:06 Phil Hunt <phil.hunt@oracle.com>:

> Maybe SCIM was a bad example.  It functions as a RESTful resource in the
> context of OAuth.
>
> I find the use of OIDC to be confusing as an example (and the default)
> because it is both an OAuth resource and a security service.  It is a
> modification of OAuth.
>
> Start thinking about every application ever written that uses OAuth. Are
> we expecting 100s of thousands of these to each register?
>
> To me, this specification is a fine specification for OIDC and it should
> be published there because the specification defines how to discovery OAuth
> and OpenID information.
>
> Likewise you suggest it is ok for SCIM to do the same.
>
> How do we expect normal applications to set up and do discovery?
>
> It seems to me that an “OAUTH” discovery spec should have a parameter to
> ask, I want to discover OAuth configuration for resource service X.
>
> That still allows me to have a separate discovery service that says, tell
> me about resource service X itself.
>
> BTW. I think we are FAR from Last Call on this topic.
>
> Phil
>
> @independentid
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Feb 18, 2016, at 6:55 AM, John Bradley <ve7jtb@ve7jtb.com> wrote:
>
> 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 <phil.hunt@oracle.com> 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 <http://tools.ietf.org/html/draft-ietf-oauth-discovery-01#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
> www.independentid.com
> phil.hunt@oracle.com
>
>
>
>
>
> On Feb 17, 2016, at 11:48 PM, Mike Jones <Michael.Jones@microsoft.com>
> 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:
> ·       http://tools.ietf.org/html/draft-ietf-oauth-discovery-01
>
> An HTML-formatted version is also available at:
> ·       http://self-issued.info/docs/draft-ietf-oauth-discovery-01.html
>
>                                                           -- Mike & Nat &
> John
>
> P.S.  This notice was also posted at http://self-issued.info/?p=1544 and
> as @selfissued <https://twitter.com/selfissued>.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>