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 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: >>> Vladimir Dzhuvinov :: vladi...@connect2id.com >>> >>> 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
