It allows non-Connect implementation of OAuth 2.0 to also have a standard
discovery capability – and one that can later be updated to also support OpenID
Connect with no breaking changes, should that be desired in the future.
-- Mike
From: Bill Mills [mailto:[email protected]]
Sent: Friday, November 27, 2015 7:58 PM
To: Mike Jones <[email protected]>; [email protected]
Subject: Re: [OAUTH-WG] OAuth Discovery
Can you elaborate on the advantage of having a separate parallel spec to OpenID
Discovery?
On Wednesday, November 25, 2015 3:37 PM, Mike Jones
<[email protected]<mailto:[email protected]>> 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]<mailto:[email protected]>
https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________
OAuth mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/oauth
