The methods could be the same but they should probably specified separately 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 <vladi...@connect2id.com> > 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_endpoint_auth_methods_supported apply to the introspection and > revocation endpoints 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] > <http://tools.ietf.org/html/rfc7591#section-2>. If omitted, the > default is "client_secret_basic" -- the HTTP Basic Authentication > Scheme specified in Section 2.3.1 > <http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-2.3.1> of > OAuth 2.0 [RFC6749 <http://tools.ietf.org/html/rfc6749>]. > > > Vladimir > > On 26.11.2015 01:37, Mike Jones 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> >> <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> >> <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 >> 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.html >> <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> <https://twitter.com/selfissued>. >> >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org <mailto:OAuth@ietf.org> >> https://www.ietf.org/mailman/listinfo/oauth >> <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
