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> 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
> [email protected]
> https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
