Agreed... 2015-11-27 0:59 GMT+09:00 John Bradley <ve7...@ve7jtb.com>:
> 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 > > 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> <https://twitter.com/selfissued>. > > > > > _______________________________________________ > OAuth mailing listOAuth@ietf.orghttps://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 > > -- Nat Sakimura (=nat) Chairman, OpenID Foundation http://nat.sakimura.org/ @_nat_en
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
