While it is good to start with the connect spec, i would caution on the assumption of compatibility. More than likely there will be changes based on broader cases.
I would like to understand these broader requirements, use cases, and security considerations first. Phil > On Nov 27, 2015, at 20:05, Mike Jones <michael.jo...@microsoft.com> wrote: > > 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:wmills_92...@yahoo.com] > Sent: Friday, November 27, 2015 7:58 PM > To: Mike Jones <michael.jo...@microsoft.com>; oauth@ietf.org > 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 > <michael.jo...@microsoft.com> 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 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 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. > > _______________________________________________ > 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
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
