Return-Path: 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 AFA5B1A21A8 for ; Thu, 26 Nov 2015 10:31:59 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.9 X-Spam-Level: X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_NONE=-0.0001] 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 luZ0J4QpAXRS for ; Thu, 26 Nov 2015 10:31:58 -0800 (PST) Received: from p3plsmtpa07-08.prod.phx3.secureserver.net (p3plsmtpa07-08.prod.phx3.secureserver.net [173.201.192.237]) (using TLSv1.2 with cipher DHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id EA82C1A21A4 for ; Thu, 26 Nov 2015 10:31:57 -0800 (PST) Received: from [192.168.0.106] ([77.77.164.50]) by p3plsmtpa07-08.prod.phx3.secureserver.net with id mJXv1r00A15ZTut01JXw6V; Thu, 26 Nov 2015 11:31:57 -0700 To: John Bradley References: <565717A0.7080805@connect2id.com> <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> From: Vladimir Dzhuvinov X-Enigmail-Draft-Status: N1110 Organization: Connect2id Ltd. Message-ID: <5657501A.7080507@connect2id.com> Date: Thu, 26 Nov 2015 20:31:54 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <282CA912-3F1A-4E04-85A4-0834D78E9725@ve7jtb.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Archived-At: Cc: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Nov 2015 18:31:59 -0000 Introspection (RFC 7662) allows bearer token authorisation for the request, which I guess will require a new keyword for this auth method? https://tools.ietf.org/html/rfc7662#section-2.1 On 26.11.2015 17:59, John Bradley wrote: > The methods could be the same but they should probably specified separa= tely eg > > introspection_endpoint_auth_methods_supported > If we overload them we will probably regret it later. > > John B. >> On Nov 26, 2015, at 11:30 AM, Vladimir Dzhuvinov wrote: >> >> Good work, Mike, John, Nat! >> >> I see that the introspection and revocation endpoints are included now= (they've been missing in OpenID discovery). >> >> Regarding client authentication, would it make sense to let token_endp= oint_auth_methods_supported apply to the introspection and revocation end= points as well? >> >> token_endpoint_auth_methods_supported >> OPTIONAL. JSON array containing a list of client authentication= >> methods supported by this token endpoint. Client authentication= >> method values are used in the "token_endpoint_auth_method" >> parameter defined in Section 2 of [RFC7591] . If omitted, the >> default is "client_secret_basic" -- the HTTP Basic Authenticatio= n >> Scheme specified in Section 2.3.1 of OAuth 2.0 [RFC6749 ]. >> >> >> Vladimir >> >> On 26.11.2015 01:37, Mike Jones wrote: >>> I'm pleased to announce that Nat Sakimura, John Bradley, and I have c= reated an OAuth 2.0 Discovery specification. This fills a hole in the cu= rrent OAuth specification set that is necessary to achieve interoperabili= ty. Indeed, the Interoperability section of OAuth 2.0 states: >>> Vladimir Dzhuvinov :: vladimir@connect2id.com >>> >>> In addition, this specification leaves a few required components part= ially or fully undefined (e.g., client registration, authorization server= capabilities, endpoint discovery). Without these components, clients mu= st be manually and specifically configured against a specific authorizati= on server and resource server in order to interoperate. >>> >>> >>> >>> This framework was designed with the clear expectation that future wo= rk will define prescriptive profiles and extensions necessary to achieve = full web-scale interoperability. >>> >>> This specification enables discovery of both endpoint locations and a= uthorization server capabilities. >>> >>> This specification is based upon the already widely deployed OpenID C= onnect Discovery 1.0 spec= ification and is compatible with it, by design. The OAuth Discovery spec= removes the portions of OpenID Connect Discovery that are OpenID specifi= c and adds metadata values for Revocation and Introspection endpoints. I= t 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 I= nformation Location. Some identifiers with names that appear to be OpenI= D 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 a= re not=20 >>> s >>> pecific to OpenID Connect. >>> >>> The specification is available at: >>> >>> * http://tools.ietf.org/html/draft-jones-oauth-discovery-00 <= 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= =2Ehtml >>> >>> -- Mi= ke >>> >>> P.S. This note was also posted at http://self-issued.info/?p=3D1496 = and as @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 >