No one is saying we shouldn’t. What I said was that Connect will consider refactoring it’s discovery to be based on the IETF version once there is one if it is posable.
If it is not posable for Connect to use the OAuth discovery from this WG then that would be a fail. I think we are in agreement. What Mike and I submitted is a starting point. John B. > On Nov 28, 2015, at 7:24 PM, Prateek Mishra <prateek.mis...@oracle.com> wrote: > > +1 > [quote] >> >> I would like to understand these broader requirements, use cases, and >> security considerations first. >> >> >> >> Phil >> > > [\quote] > > > OAuth is being used in a *much* broader set of use-cases and contexts than > OpenID connect. > > I think its very important to have a solution that addresses these flows. > > - prateek > > >> On Nov 27, 2015, at 20:05, Mike Jones <michael.jo...@microsoft.com >> <mailto: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 >>> <mailto:wmills_92...@yahoo.com>] >>> Sent: Friday, November 27, 2015 7:58 PM >>> To: Mike Jones <michael.jo...@microsoft.com >>> <mailto:michael.jo...@microsoft.com>>; oauth@ietf.org >>> <mailto: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 <mailto: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 >>> <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 >>> <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>. >>> >>> _______________________________________________ >>> 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 <mailto:OAuth@ietf.org> >>> https://www.ietf.org/mailman/listinfo/oauth >>> <https://www.ietf.org/mailman/listinfo/oauth> >> _______________________________________________ >> 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 <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
