Re: [OAUTH-WG] OAuth Discovery
Mike Jones <Michael.Jones@microsoft.com> Sat, 28 November 2015 23:41 UTC
Return-Path: <Michael.Jones@microsoft.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 01ADB1A6F7D for <oauth@ietfa.amsl.com>; Sat, 28 Nov 2015 15:41:08 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Level:
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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 IzHm2v0qh6Fl for <oauth@ietfa.amsl.com>; Sat, 28 Nov 2015 15:41:01 -0800 (PST)
Received: from na01-bl2-obe.outbound.protection.outlook.com (mail-bl2on0109.outbound.protection.outlook.com [65.55.169.109]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61FE11A6F7B for <oauth@ietf.org>; Sat, 28 Nov 2015 15:41:00 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector1; h=From:To:Date:Subject:Message-ID:Content-Type:MIME-Version; bh=bvYivseNHsZNbhNMjL5Zwn75JSDak6FK36DKG4A2Hg8=; b=X5lqYO6MPDbf/Rg/7zhc2INo2D0lKRm1fdqZAjCRhE8IwCwOl+hMYjLkUwFjkskC2UCJWYB5uN7rJx03xh5sYlk6KQwDMMHxceRXl5bXG3ZV0HX6HPx2wpy83t0ygePYpiyIAuhwLOuv+28tcuDHuC01DW11NTgiGj4Wq9+ncFs=
Received: from BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) by BY2PR03MB442.namprd03.prod.outlook.com (10.141.141.145) with Microsoft SMTP Server (TLS) id 15.1.331.20; Sat, 28 Nov 2015 23:40:57 +0000
Received: from BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) by BY2PR03MB442.namprd03.prod.outlook.com ([10.141.141.145]) with mapi id 15.01.0331.023; Sat, 28 Nov 2015 23:40:57 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: Prateek Mishra <Prateek.Mishra@oracle.com>, Phil Hunt <phil.hunt@oracle.com>
Thread-Topic: [OAUTH-WG] OAuth Discovery
Thread-Index: AdEnv6MqmLA/Ph7MT4qJwfYSFGITHwB0WHAAAAA37DAAAVwyAAAlC9mAAAIKO5A=
Date: Sat, 28 Nov 2015 23:40:55 +0000
Message-ID: <BY2PR03MB442F731A3C923118AAEC740F5020@BY2PR03MB442.namprd03.prod.outlook.com>
References: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com> <128376572.11963058.1448683100369.JavaMail.yahoo@mail.yahoo.com> <BY2PR03MB442BDB413693994CA405044F5020@BY2PR03MB442.namprd03.prod.outlook.com> <5F43839D-06E7-4E56-BAAC-0F0DE3A553D7@oracle.com> <E278B927-7A52-4526-B9FF-09B6724FBFBC@oracle.com>
In-Reply-To: <E278B927-7A52-4526-B9FF-09B6724FBFBC@oracle.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [50.47.85.157]
x-microsoft-exchange-diagnostics: 1; BY2PR03MB442; 5:m89EGLDMFZiP0g6T0B0TPZQkG7dYFv4nLJSfVTF/dHlpJW259JbP+CLGDp4wJeN/GdC7PVs9Whp2v5grJHHDedK3ZjbZOjMjJWrw8RrwNorrZS5NGRth+QAvZzbtDO4gGIRLNg2VQrx4gNQuQ2F0Lw==; 24:oZ68V60sryNdtH2kxqhNVq/a2YDy2R6FjWTN0CFVi23eecat3C0G6Qx8uSIFNY3ipIRSVENjfL05/jqgHY6Y2TVM/tHfR9dbOVeDlJ/6yAY=
x-microsoft-antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:BY2PR03MB442;
x-microsoft-antispam-prvs: <BY2PR03MB44269B26B59F5D8A4B285B8F5020@BY2PR03MB442.namprd03.prod.outlook.com>
x-exchange-antispam-report-test: UriScan:(201166117486090)(108003899814671)(146099531331640);
x-exchange-antispam-report-cfa-test: BCL:0; PCL:0; RULEID:(61425024)(601004)(2401047)(8121501046)(5005006)(520078)(10201501046)(3002001)(61426024)(61427024); SRVR:BY2PR03MB442; BCL:0; PCL:0; RULEID:; SRVR:BY2PR03MB442;
x-forefront-prvs: 07749F8C42
x-forefront-antispam-report: SFV:NSPM; SFS:(10019020)(209900001)(189002)(24454002)(199003)(377454003)(93886004)(5001770100001)(54356999)(2950100001)(66066001)(33656002)(74316001)(10090500001)(5008740100001)(790700001)(92566002)(19617315012)(97736004)(40100003)(11100500001)(15975445007)(15395725005)(86612001)(16236675004)(1220700001)(5004730100002)(87936001)(86362001)(77096005)(19580395003)(19580405001)(101416001)(19300405004)(122556002)(19609705001)(5002640100001)(5005710100001)(586003)(189998001)(50986999)(10400500002)(5001960100002)(81156007)(106356001)(105586002)(5003600100002)(2900100001)(99286002)(10290500002)(102836003)(3846002)(8990500004)(76176999)(1096002)(76576001)(19625215002)(6116002)(6606295002); DIR:OUT; SFP:1102; SCL:1; SRVR:BY2PR03MB442; H:BY2PR03MB442.namprd03.prod.outlook.com; FPR:; SPF:None; PTR:InfoNoRecords; MX:1; A:1; LANG:en;
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
spamdiagnosticoutput: 1:23
spamdiagnosticmetadata: NSPM
Content-Type: multipart/alternative; boundary="_000_BY2PR03MB442F731A3C923118AAEC740F5020BY2PR03MB442namprd_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-originalarrivaltime: 28 Nov 2015 23:40:55.8803 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-Transport-CrossTenantHeadersStamped: BY2PR03MB442
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/fb7BPW6buH6y3YiLv2V4Qh8Q40c>
Cc: "oauth@ietf.org" <oauth@ietf.org>
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: Sat, 28 Nov 2015 23:41:09 -0000
No disagreement. I’m sure that the working group will add features to address functionality needed for some common use cases that are not needed by OpenID Connect. Indeed, the three authors have already done so – adding endpoints for token revocation and token introspection. Other additions are likely to occur as well along the way. That being said, given that OpenID Connect Discovery<http://openid.net/specs/openid-connect-discovery-1_0.html> established existing practice for representing common discovery functionality like the authorization endpoint URL, the token endpoint URL, etc., it would seem counterproductive not to follow that existing practice, where applicable. Indeed, the OAuth working group has already had a similar success with a completed RFC, keeping OAuth 2.0 Dynamic Client Registration<http://tools.ietf.org/html/rfc7591> 100% compatible with OpenID Connect Dynamic Client Registration<http://openid.net/specs/openid-connect-registration-1_0.html>. Getting down to specifics, what features are needed for common use cases that aren’t already in the current draft? For starters, Vladimir Dzhuvinov has already called out defining authentication methods to the revocation and introspection endpoints. What else are people commonly doing that isn’t covered in the current draft? Remember of course, that one of the primary purposes of the specification is to establish the OAuth Discovery Metadata Registry. That way we don’t have to think of everything that anyone might need in advance. New values can and will be added as they are needed by new and existing applications in additional specifications utilizing the registry. Best wishes, -- Mike From: Prateek Mishra [mailto:Prateek.Mishra@oracle.com] Sent: Saturday, November 28, 2015 2:24 PM To: Phil Hunt <phil.hunt@oracle.com> Cc: Mike Jones <Michael.Jones@microsoft.com>; oauth@ietf.org Subject: Re: [OAUTH-WG] OAuth Discovery +1 [quote] I would like to understand these broader requirements, use cases, and security considerations first. Phil [\quote] OAuth is being used in a *much* broader set of use-cases and contexts than OpenID connect. I think its very important to have a solution that addresses these flows. - prateek On Nov 27, 2015, at 20:05, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote: It allows non-Connect implementation of OAuth 2.0 to also have a standard discovery capability – and one that can later be updated to also support OpenID Connect with no breaking changes, should that be desired in the future. -- Mike From: Bill Mills [mailto:wmills_92105@yahoo.com] Sent: Friday, November 27, 2015 7:58 PM To: Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>>; oauth@ietf.org<mailto:oauth@ietf.org> Subject: Re: [OAUTH-WG] OAuth Discovery Can you elaborate on the advantage of having a separate parallel spec to OpenID Discovery? On Wednesday, November 25, 2015 3:37 PM, Mike Jones <Michael.Jones@microsoft.com<mailto:Michael.Jones@microsoft.com>> wrote: 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 and as @selfissued<https://twitter.com/selfissued>. _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto:OAuth@ietf.org> https://www.ietf.org/mailman/listinfo/oauth _______________________________________________ OAuth mailing list OAuth@ietf.org<mailto: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