Re: [OAUTH-WG] OAuth Discovery
Torsten Lodderstedt <torsten@lodderstedt.net> Sun, 13 December 2015 20:43 UTC
Return-Path: <torsten@lodderstedt.net>
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 C64901A0169 for <oauth@ietfa.amsl.com>; Sun, 13 Dec 2015 12:43:14 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.449
X-Spam-Level:
X-Spam-Status: No, score=0.449 tagged_above=-999 required=5 tests=[BAYES_50=0.8, HELO_EQ_DE=0.35, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-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 bRuWqmps7p77 for <oauth@ietfa.amsl.com>; Sun, 13 Dec 2015 12:43:11 -0800 (PST)
Received: from smtprelay04.ispgateway.de (smtprelay04.ispgateway.de [80.67.31.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2378D1A0108 for <oauth@ietf.org>; Sun, 13 Dec 2015 12:43:10 -0800 (PST)
Received: from [79.253.5.21] (helo=[192.168.71.102]) by smtprelay04.ispgateway.de with esmtpsa (TLSv1.2:DHE-RSA-AES128-SHA:128) (Exim 4.84) (envelope-from <torsten@lodderstedt.net>) id 1a8DU3-0006po-6W; Sun, 13 Dec 2015 21:43:07 +0100
To: Mike Jones <Michael.Jones@microsoft.com>, "oauth@ietf.org" <oauth@ietf.org>, Nat Sakimura <sakimura@gmail.com>, John Bradley <ve7jtb@ve7jtb.com>
References: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com>
From: Torsten Lodderstedt <torsten@lodderstedt.net>
Message-ID: <566DD856.1010603@lodderstedt.net>
Date: Sun, 13 Dec 2015 21:43:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.4.0
MIME-Version: 1.0
In-Reply-To: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com>
Content-Type: multipart/alternative; boundary="------------090109030705090804030300"
X-Df-Sender: dG9yc3RlbkBsb2RkZXJzdGVkdC5uZXQ=
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/Fudy8gjr_m-_fXXj52lxgkr513g>
Subject: Re: [OAUTH-WG] OAuth Discovery
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: Sun, 13 Dec 2015 20:43:14 -0000
Hi Mike, Nat, John, thanks for starting this work. It seems you assume the AS can always be discoverd using the user id of the resource owner. I think the underlying assumption is resource servers accept access token of different (any?) user specific AS (and OP)? From my perspective, RSs nowadays typically trust _the_ AS of their security domain/ecosystem and all resource owners need to have an user account with this particular AS. So I would assume the process to start at the RS. We potentially need to cover for both cases. What do you think? best regards, Torsten. Am 26.11.2015 um 00:37 schrieb Mike Jones: > > I’m pleased to announce that Nat Sakimura, John Bradley, and I have > created an OAuth 2.0 Discovery specification. This fills a hole in > the current OAuth specification set that is necessary to achieve > interoperability. Indeed, the Interoperability section of OAuth 2.0 > <https://tools.ietf.org/html/rfc6749#section-1.8>states: > > In addition, this specification leaves a few required components > partially or fully undefined (e.g., client registration, authorization > server capabilities, endpoint discovery). Without these components, > clients must be manually and specifically configured against a > specific authorization server and resource server in order to > interoperate. > This framework was designed with the clear expectation that future > work will define prescriptive profiles and extensions necessary to > achieve full web-scale interoperability. > > This specification enables discovery of both endpoint locations and > authorization server capabilities. > > This specification is based upon the already widely deployed OpenID > Connect Discovery 1.0 > <http://openid.net/specs/openid-connect-discovery-1_0.html> > specification and is compatible with it, by design. The OAuth > Discovery spec removes the portions of OpenID Connect Discovery that > are OpenID specific and adds metadata values for Revocation and > Introspection endpoints. It also maps OpenID concepts, such as OpenID > Provider, Relying Party, End-User, and Issuer to their OAuth > underpinnings, respectively Authorization Server, Client, Resource > Owner, and the newly introduced Configuration Information Location. > Some identifiers with names that appear to be OpenID specific were > retained for compatibility purposes; despite the reuse of these > identifiers that appear to be OpenID specific, their usage in this > specification is actually referring to general OAuth 2.0 features that > are not specific to OpenID Connect. > > The specification is available at: > > ·http://tools.ietf.org/html/draft-jones-oauth-discovery-00 > > An HTML-formatted version is also available at: > > ·http://self-issued.info/docs/draft-jones-oauth-discovery-00.html > > -- Mike > > P.S. This note was also posted at http://self-issued.info/?p=1496 > <http://self-issued.info/?p=1496> and as @selfissued > <https://twitter.com/selfissued>. > > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
- Re: [OAUTH-WG] OAuth Discovery Vladimir Dzhuvinov
- [OAUTH-WG] OAuth Discovery Mike Jones
- Re: [OAUTH-WG] OAuth Discovery William Denniss
- Re: [OAUTH-WG] OAuth Discovery John Bradley
- Re: [OAUTH-WG] OAuth Discovery Mike Jones
- Re: [OAUTH-WG] OAuth Discovery Justin Richer
- Re: [OAUTH-WG] OAuth Discovery John Bradley
- Re: [OAUTH-WG] OAuth Discovery Nat Sakimura
- Re: [OAUTH-WG] OAuth Discovery Vladimir Dzhuvinov
- Re: [OAUTH-WG] OAuth Discovery Bill Mills
- Re: [OAUTH-WG] OAuth Discovery Mike Jones
- Re: [OAUTH-WG] OAuth Discovery Phil Hunt
- Re: [OAUTH-WG] OAuth Discovery John Bradley
- Re: [OAUTH-WG] OAuth Discovery Prateek Mishra
- Re: [OAUTH-WG] OAuth Discovery Mike Jones
- Re: [OAUTH-WG] OAuth Discovery Torsten Lodderstedt
- Re: [OAUTH-WG] OAuth Discovery Phil Hunt
- Re: [OAUTH-WG] OAuth Discovery John Bradley
- Re: [OAUTH-WG] OAuth Discovery Brian Campbell
- Re: [OAUTH-WG] OAuth Discovery Bill Mills